First of all, a million thanks for this project. <3

Purpose of the issue

• Bug report (encountered problems/errors)
• Feature request (request for new functionality)
• Question

Version Information

Cmder: 1.3.14.982
ConEmu 191012
OsVer: 10.0.19559.x64

Background

My ConEmu task is:

-new_console:d:D:\ cmd /k ""%ConEmuDir%\..\init.bat" /f /nix_tools 0"

and I launch cmder.exe with this shortcut:

%CMDER_ROOT%\Cmder.exe /C "%DOTFILES_ROOT%\cmder"

where DOTFILES_ROOT is my local dotfiles Git repo.

In the wiki, it's recommended to add the following to vscode's settings.json:

  "terminal.integrated.shellArgs.windows": [
    "/k",
    "%CMDER_ROOT%\\vendor\\bin\\vscode_init.cmd"
  ],

At the time of this writing, vscode_init.cmd merely calls init.bat without any arguments.

Problem 1

If I don't launch Visual Studio Code from cmder (e.g. Windows Explorer context menu, Start Menu, Desktop shortcut, etc.), the options to init.bat are not the same as in my ConEmu task. Additionally, this means my %DOTFILES_ROOT%\cmder user config is not picked up.

Workaround 1

I worked around this by adding a wrapper init.bat and duplicating vscode_init.cmd:

:: %DOTFILES_ROOT%\cmder\init.bat
"%CMDER_ROOT%\vendor\init.bat" /c "%DOTFILES_ROOT%\cmder" /f /nix_tools 0

:: %DOTFILES_ROOT%\cmder\vscode_init.cmd
:: Copied from cmder's vscode_init, but adjusted to call our init.bat
@echo off
IF [%1] == [] (
    REM -- manually opened console (Ctrl + Shift + `) --
    CALL "%~dp0init.bat"
) ELSE (
    REM -- task --
    CALL cmd %*
    exit
)

modifying the ConEmu task to:

-new_console:d:D:\ cmd /k ""%DOTFILES_ROOT%\cmder\init.bat""

and the vscode settings.json to:

    "terminal.integrated.shellArgs.windows": [
        "/k",
        "%DOTFILES_ROOT%\\cmder\\vscode_init.cmd"
    ]

This ensures parity between init.bat options in the ConEmu task and in the vscode shellArgs.

This actually leads to a second (probably less important) problem:

Problem 2

If I launch vscode from Cmder (code ., or similar), then PATH is effectively "re-enhanced", resulting in a PATH like:

PATH=[cmder init.bat][cmder init.bat][global]

where [cmder init.bat] are the modifications made to PATH by init.bat and my user configuration, and [global] is the global (system?) value of PATH.

I believe by removing the /f option to init.bat, cmder's PATH enhancements will not be duplicated, but my user configuration still will (unless I were to use lib_path as well?).

In most cases, I agree that duplicated values in PATH is merely unsightly. However, it can be a problem if modifications to PATH (let's call them [session]) are made after launching Cmder but before launching vscode. This results in something like:

PATH=[cmder init.bat][session][cmder init.bat][global]

All of our projects at work require setting up PATH (and other envs) before launching vscode, i.e. the workflow is something like:

• start Cmder
• cd [project_dir]
• scripts\edit.bat (this prepends [session] to PATH and launches vscode)
• scripts\test.bat (this prepends [session] to PATH and runs the tests)

So why is it problematic? Simply because it means the environment I get in a vscode terminal isn't the same as the environment I run the tests in, and in fact isn't even the same as the environment that VSCode tasks (such as running the tests and debugging) run in. I haven't come across any problems with this yet, but it bothers me.

Workaround 2

My workaround for the above was to tweak my init.bat to use CMDER_CONFIGURED (which isn't used anywhere AFAICT?):

if not defined CMDER_CONFIGURED goto :first

:: Copied from cmder's init.bat
"%CMDER_ROOT%\vendor\clink\clink_x%architecture%.exe" inject --quiet --profile "%CMDER_USER_CONFIG%" --scripts "%CMDER_ROOT%\vendor" || exit /b
:: PATH and friends already set. Aliases are the only thing that don't persist, for some reason
alias /reload >nul || exit /b
exit /b 0

:first
"%CMDER_ROOT%\vendor\init.bat" /c "%DOTFILES_ROOT%\cmder" /f /nix_tools 0
exit /b %ERRORLEVEL%

Conclusion

Re: problem 1: Am I missing something?

Problem 2 can probably be avoided by not using /f and using lib_path enhance_path in my user_profile.cmd? Would it be worth mentioning that somewhere (sincere apologies if it already is).