* Fix Cmder not changing to CMDER_START
Fix to allow Cmder to change to different startup directory if already on the same drive as CMDER_START
possibly relevant: HOME != USERPROFILE
* make "Cmder Here" work in more cases
integrated suggestion from comments (test for trailing backslash to prevent doubling of trailing backslash)
integrated suggestions from #1456: switching ```cd /d``` over to ```pushd``` to get support for UNC-paths
* replaced 'cd /d' with 'pushd'
replaced two more instances of 'cd /d' with 'pushd' to support network paths.
Also added double quotes to the use of '%USERPROFILE%' to prevent issues with spaces.
I also noticed that 'pushd', in contrast to 'cd /d' does not require the trailing backslash for drive roots (on Win7). Therefore I removed the trailing backslash check.
* Don't assume / is needed at end
* Update init.bat
(and some comments on the user-profile.cmd file)
Inspired by the comments from https://github.com/cmderdev/cmder/issues/193 and my personal need to use pageant instead of OpenSSH authentication agents (which is more Window user-friendly), I have used this approach which works as expected.
Keeping the spirit of the current scripts, I left it disabled, and with some comments explaining what they all do.
1. Changed " --login -i"" to "" --login -i" in ConEmu
2. Closed quotation in "alias.bat :p_del doskey" command of "%ALIASES%"
Suppose %CMDER_ROOT% is "C:\Program Files\cmder",
this BUG will be raised while we exec command of
"unalias xxx"
or creat terminal "{bash::bash}"
and "{bash::mintty}",
it will throws an error like:
'C:\Program' is not recognized as an internal or external command,
operable program or batch file.
If the Install-Module command is available, do not include the bundled
module path containing a deprecated version of PSGet. Recent powershell
versions include PowerShellGet as standard module installer.
Resolve#1318.
This defines the default prompt variables ($PrePrompt, $PostPrompt,
$CmderPrompt, and $Prompt) before running the custom scripts (user-profile.ps1
and profile.d/*.ps1), and then saves those prompt values after running the
custom scripts. This gives the custom scripts and opportunity to override the
prompt code blocks.
This now opens the possibility for profile.d/*.ps1 scripts to affect the
prompt, and also allows both user-profile.ps1 and profile.d/*.ps1 scripts to
overwrite the $Prompt script block and overwrite the prompt behavior entirely.
