Open Karlson2k opened 8 years ago
From my point of view it's expected behaviour:
When you starting cmd from cmd it has process "tree" like cmd -> cmd
When you starting cmd from conemu it has process tree like:
conemu -> cmd
\-> cmd
@pyhedgehog I'm starting cmd not from ConEmu (by any ConEmu command). I'm starting cmd from cmd by start cmd.exe
and started cmd must inherit environment (unless start /i cmd.exe
is used).
Same happens for any console applications, while GUI applications works just fine.
This breaks some .bat-files, like Msys/MinGW msys.bat and Msys2/MinGW-w64 *_shell.bat, which configure environment and then use start
to launch the shell.
I accept this as a bug. Even with -new_console
environment may be inherited. This is a limitation of the current implementation.
@Maximus5 Is it possible to workaround this bug somehow?
Fortunately, ConEmu now can be used with MSys2 /MinGW64 with -conemu
flag: https://github.com/Alexpux/MSYS2-packages/pull/538.
Why do you even need to "start" new console from another with modified environment?
The only workaround ATM is to run ConEmu.exe -cmd <your command>
to start new window.
This is usually done from .bat after some initialization, like Msys-shell launchers.
Currently all those .bat-files are broken if ConEmu is used.
Someone may use start /min
to do some background task.
Isn't it possible to intercept call from "start" command and add prefix ConEmu.exe -cmd
to the string?
These launchers launch mintty usually, which start is not hooked in ConEmu and there is no problems therefore. In other case, I consider these launchers are badly written.
There is no way to determine when "start" is used. Also why do you think that new window have to be started instead of new tab which is the default behavior with -new_console
?
@Maximus5 If mintty is not present, launcher fall back to start sh...
.
I don't know for which reason start ...
was used for console application, but it's perfectly legal and expected to work correctly. From my point of view - this isn't a bad design, but this is not optimal design.
Could I ask to rise priority of this bug as this silently breaks .bat-files and results in unexpected behavior and hard-detectable failures?
Is it possible to call GetEnvironmentStringsW() and pass result as parameter to CreateProcess() or modify environment of started process by some other way?
Run
cmd.exe
Type:set ZZTEST=TestVal
Check assignment:set | find "ZZTEST"
Start from same console new cmd instance by
start cmd.exe
. If ConEmu default terminal is used, environment is lost. Check by:set | find "ZZTEST"
If ConEmu defterm is not used or new instance started by
start cmd.exe -new_console:z
then environment is inherited.