cmder here not working with windows bash

[Ehekatl]

my bash task definition:
%SYSTEMROOT%\System32\bash.exe -c zsh -new_console:a:s:p:n:d:"%USERPROFILE%"
when I using cmder here it always goes same directory, but it's working on powershell and cmd.

[darsain]

Have a similar issue when trying to open Cmder in a specific directory, where passing any parameter to Cmder.exe has no effect when {cmd::Cmder as Admin} is set as a default task. It works fine for non-admin {cmd::Cmder} though.

Any possible fix for this?

[Stanzilla]

https://github.com/cmderdev/cmder/issues/901#issuecomment-237562623

[Ehekatl]

@Stanzilla have you tried "open cmd here" ? It's doesn't work on my side

[Ehekatl]

k, now I find out why it's not working, in default settings this magic actually control by CMDER_START env variable, and the init script will take care of it.

e.g. init.bat for cmd

:: This is either a env variable set by the user or the result of
:: cmder.exe setting this variable due to a commandline argument or a "cmder here"
if defined CMDER_START (
    cd /d "%CMDER_START%"
)

@darsain for your question, just add the initial script to your admin task should work
but for windows bash, seems it doesn't pass the env variable, I can't find CMDER_START in env

[darsain]

I'm gonna clarify further. I'm running Cmder 1.3.0.

There are 2 tasks.

{cmd::Cmder}:

cmd /k "%ConEmuDir%\..\init.bat"  -new_console:d:%USERPROFILE%

{cmd::Cmder as Admin}:

*cmd /k "%ConEmuDir%\..\init.bat"  -new_console:d:%USERPROFILE%

The tasks are identical, both including the init.bat script as you can see above.

Starting in specified directory (passed to the Cmder.exe as 1st parameter) works for normal task, but doesn't for Admin.

I want to use Admin task as default, but can't because using Cmder without the configurable starting directory is too painful.

[pingshunhuangalex]

Not working with Git Bash either, and it's still not fixed judging from the closed issue here

[xschen]

Just found a solution. You can simply replace %USERPROFILE% with %CMDER_START%. For example the task for the built-in git bash can be modified as

cmd /c "%ConEmuDir%\..\git-for-windows\bin\bash --login -i" -new_console:d:%CMDER_START%

[pingshunhuangalex]

@xschen
Gosh mate, you saved my day. I've been using the ConEmu Here temporary fix found on Stackoverflow like forever.

I did see people mention the magic %CMDER_START% in a couple of issue threads as well as in the init file, but their solutions didn't work so I just moved on...

However, it does have its downside... Now just firing up the Cmder shortcut will throw you an error. Also, this method doesn't work in the root of the drive like D:/, but thanks so much, I think I may be a step closer to what I want here.

[emily-curry]

@pingshunhuangalex In your windows shortcut, you can set the /start option.
For example, your shortcut's target may look like this: C:\cmder\Cmder.exe /start "C:\Users\ping"

Still no fix for 'cmder here' in the root of a drive, though.

[Messiahhh]

@xschen Saved me

[rodrymbo]

This is old, but the latest Windows Subsystem for Linux (WSL) seems to do things just slightly differently lately, so I thought I'd document it here for completeness.

This works for me:

Icon:
/icon "C:\Program Files\WindowsApps\CanonicalGroupLimited.Ubuntu18.04onWindows_1804.2018.427.0_x64__79rhkp1fndgsc\ubuntu1804.exe"

Commands:
ubuntu1804 run

The "run" parameter for ubuntu1804 is documented (in windows store). It says you can use it with a script name as in ubuntu1804 run myscript.bash, which is supposed to start bash and execute the script found in the current directory. Just run by itself starts the default shell (bash?) in the current directory. With no run, it starts it in the user's ~ home directory.

I suppose one can use something similar with the init.bat method.

Not sure how to pass the current directory on the command line -- %V does not seem to work properly.

Also, for "WSL Bash Here", the following command seems to work:
"D:\%CMDER_PATH%\Cmder.exe" /task "bash::wsl" /start "%1"
when bash::wsl is defined as above.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs. Thank you for your contribution.

[stale[bot]]

This issue has been automatically closed due to it not having any activity since it was marked as stale. Thank you for your contribution.