[Bug] Installation error, batch missing

[mrx23dot]

Version Information

Cmder version: v1.3.25
Operating system: Windows 10

Cmder Edition

Cmder Full (with Git)

Description of the issue

I downloaded
https://github.com/cmderdev/cmder/releases/download/v1.3.25/cmder.zip

started it, in post installation:

'C:\WINDOWS\system32\drivers\etc\hosts' -> '/etc/hosts'
'C:\WINDOWS\system32\drivers\etc\protocol' -> '/etc/protocols'
'C:\WINDOWS\system32\drivers\etc\services' -> '/etc/services'
'C:\WINDOWS\system32\drivers\etc\networks' -> '/etc/networks'
The batch file cannot be found.
Creating user startup file: "C:\apps\cmder2\config\user_profile.cmd"
1 file(s) copied.

How to reproduce

No response

Additional context

No response

Checklist

• I have read the documentation.
• I have searched for similar issues and found none that describe my issue.
• I have reproduced the issue on the latest version of Cmder.
• I am certain my issues are not related to ConEmu, Clink, or other third-party tools that Cmder uses.

[daxgames]

What is the problem? This looks completely normal to me on an initial run. Including the The batch file cannot be found..

It should only happen one time on initial launch after downloading a new version.

[mrx23dot]

The batch file cannot be found.
Can be misleading. could say no optional configuration was loaded.

[DRSDavidSoft]

I agree, we can make the error a bit more informational. Let's add this.

[daxgames]

I don't believe it is even in our control.

It is coming from Git for Windows first run batch file when it deletes itself and when it deletes itself it can't go back to itself therefore it says batch file not found.

All we do is run their file.

[DRSDavidSoft]

Hmm, you're completely right, it'd be interested to fiddle with their code to see if we can modify the behavior to hide the error message. For example, instead of deleting the file from itself, we can execute another batch file to replace the current running one, without using call to return to the one that is going to delete itself. Then, in the other file, it could delete the calle.

That's of course just a mental exercise more than anything else, I don't really believe it would be worth implementing.

With that said, the more important thing in my opinion is to improve the first time run experience by clearly relaying the expected sequence of events that is going to happen to the user, muting the clutter that is produced, and maybe even clearing the screen upon detecting a successful post setup by Git.

These are just some thoughts, but I've been meaning to add some enhancement that would address the first time setup, I guess I have to submit a PR to better explain and clarify what I mean by improvements to the first time setup. Nothing fancy but sure appreciated by newcomers.

Thanks, @daxgames for correcting my oversight, I'll add more information in another issue with my proposed changes in preparation for the next major release, which hopefully would align with your approval.

[daxgames]

I just tested and this can be fixed or at least hidden by us in our code. It will be fixed in a future release.

[DRSDavidSoft]

Great to hear, looking forward to seeing it in action!

[daxgames]

I may have spoken too soon my supposed solution for it created an undeletable file on my windows even after reboot even and while booting into safe mode so probably not.

So I now have a Cmder full directory with a single file called nul inside it that will be there forever or until I create a new VM.

[DRSDavidSoft]

No worries! I suggest keeping this issue open until a working PoC is implemented, also for deleting that NUL file you may try this:

https://stackoverflow.com/a/17883854/1454514

I've had some ideas as to modify the post installation script, maybe even upstreaming it to the GfW project itself.

I'll spend some time when I'm free exploring this idea. If you agree, I'll re-open the issue.

[daxgames]

@DRSDavidSoft See below:

We could use this as part of our 'fix'. I personally think it's unnecessary to fix this as it happens only once and is not REALLY an issue.

[DRSDavidSoft]

I might not be understanding this correctly, but I believe creating an "undeletable" file (by normal means to the end user, anyway) to be a pretty serious issue. It could mess up any other operation as well, imagine creating a .zip archive of your Cmder installation to move it to another PC, uploading it to the cloud, etc.

Anyways, the important thing is that there is a fix to all of these problems, we should balance the amount of code that we are comfortable adding to the project to deal with these. Can you please share your script?

Before all of that, it would be beneficial (in my opinion) to create a new issue or PR to clearly describe what the problem is, the proposed changes to fix it, and the how it works in detail to evaluate the changes needed to close this one.

As always, thanks for the great work you do Dax, I appreciate it man! 👍🏻 🚀

[daxgames]

No one is suggesting we create an 'undeleteable' file and leave it on the system. IF it truly was my fix that created the file we can use the trick above to delete it as soon as we create it. I am verifying if it was my fix that caused the issue.

[daxgames]

Actually, I cannot recreate the issue, so I have no idea how that file got created. The below code in the init.bat though hides the error during first run initialization.

All I added was the 2>nul

See below:

[daxgames]

@DRSDavidSoft I opened a PR and it is building now. I will test the artifact when it is done. If you could as well just as a second verification then we can merge.

[daxgames]

Tested build looks LGTM

[chrisant996]

@daxgames you can delete the file by using a wildcard, e.g. del nu*. But make sure the wildcard you use doesn't also match any other files... 😉

[DRSDavidSoft]

@chrisant996 Great idea, didn't know about it!

[DRSDavidSoft]

@daxgames Saw the fix (#2995), I was thinking about going the other direction, modifying the actual post-install.bat script to better suit welcoming messages. Currently 2>nul will prevent showing all potential error messages to the user, which I argue is not good practice.

I require some time to investigate the post-install.bat script, to see if we can tweak it, instead of quelling all potential errors it could generate (for instance, access being denied due to Cmder being unpacked in Program Files, the user needs to know about this...) -- I have run into it in the past.

No one is suggesting we create an 'undeleteable' file and leave it on the system.

I apologize, my bad for the misunderstanding 😅

[chrisant996]

Something similar to the following might be a potential option which doesn't lose other error output, but does suppress the specific message:

1. Run some command that produces the same message you want to suppress, and redirect the output into a file. (This step is important to handle localization and languages other than English.)
2. Read that file into an environmental variable (e.g. using a for /f command).
3. Redirect the output stream that will contain the text you want to suppress, e.g. 1>tempfile 2>&1 the_git_batch_script.
4. Use something like findstr /c:"%var_with_text_to_suppress%" /v tempfile to print the output minus the lines to suppress.

This assumes that the git script will never try to accept input.

[DRSDavidSoft]

I was looking into modifying the actual post-install.bat script that they wrote, itself.

We can adjust our build scripts to remove the last line @DEL post-install.bat from the script, by utilizing a git apply ourpatch.diff to the script, or even a simple regex replace.

Later, the init.bat script on our side can take care of deleting the file, thus solving the original issue, as mentioned by Dax:

It is coming from Git for Windows first run batch file when it deletes itself and when it deletes itself it can't go back to itself therefore it says batch file not found.

I prefer doing this way over #2995.

There is one more reason, the copy command produces an ugly message that can be even more refined.

Both Cmder and GfW make use of copy commands in various places for the initial setup, and the errorlevel is ignored in all of them, apparently.

Imagine unpacking Cmder to Program Files or some other place where the permissions are not sufficient. The expected behavior by the user is to be notified for the lack of permissions, and optimally be given the chance to elevate. The error handling in both init.bat and post-install.bat are poor in these cases, IMHO.

Part of my proposed changes (in #2788) for an improved first launch experience is to address these, so applying a patch on top of their post-install.bat could give us more chances to improve the experience of the users who just launched Cmder for the first time.