E.g., if ${CMDER_ROOT} is /c/Users/Foo Bar/cmder,
the following errors will occur:
bash: pushd: /c/Users/Foo: No such file or directory
bash: [: /c/Users/Foo: binary operator expected
bash: /c/Users/Foo: No such file or directory
clink.get_cwd() is returning a string which is differently encoded than what
clink.prompt.value expects. This results in garbled path names if the path
condains non-ASCII chars. The (arguable hacky) solution is to parse the old
prompt for the current directory (which breaks if the user sets a PROMPT env var
which is incompatible to the regex used here...).
Also parse out a environment name set by systems like virtualenv or conda: this
could be done more specifically by targeting each such system and using the
usually set environment variable but this would mean that we would have to do
that for each and every such system out there and that is probably not a sane
idea...
This keeps the PROMPT variable as is and changes the prompt to the cmder style
in the clink code.
This has two advantages:
* opening a cmd in a cmder session will now show the old prompt code instead of
a ugly raw prompt without the replacements. This led to ugly output when a
batch file echoed their content (e.g `conda build recipe/`).
* when a command rewrites the prompt (e.g. an activate in a virtualenv), these
command sometimes simply overwrites the PROMPT so that the cmder enhancements
were not anymore in place. Now we simply don't care and overwrite it with our
stuff in the clink part. This might mean that a user has to install a lua
script so that e.g. conda environments are visible on the prompt.
Add a pre and post function hook around the Cmder prompt.
Specify the cmder prompt as a function that could be replaced by a user.
Write a friendly message when the user profile template is created.
Create the user profile with cmder prompt hooks ready to use.
It was concerning to run any function with a specific name every prompt
with no guarantee it remains what it was initally created as.
Core functions have been explicitly called from their
namespace like Microsoft.PowerShell.Utility\Write-Host to try and prevent
clobbering.
User supplied functions are passed in as script blocks, created as the
session runs the profile script. By creating them as constants these
function names cannot be declared again for the duration of the process.
Since the prompt function already exists by this time, set the readOnly
flag so to re-declare the prompt requires the use of -force.
It is hoped these changes limit what could be the risk of any script
redefining functions that are called automatically without user intent or
input.
There were problems when a path contained a parenthesis like `C:\temp\test (test)\`
As a precaution, quote all variables when they are used in echo or set.
The idea is:
* if the users points as to a specific git, use that
* test if a git is in path and if yes, use that
* last, use our vendored git
We don't make any attempt to guess a different location, if a user wants their
own git install, they have to choose "add git to path".
Also check that we have a recent enough version of git (e.g. test for
<GIT>\cmd\git.exe)
4bfdf04d59 moved all clink config files
to vendor/ and therefore the files in config/ were not used and .history
was also moved to vendor/.
The new arrangement uses `--script` to load our own clink.lua file which in
turn as the first thing loads the original clink.lua file. The user defined
files are again in config/. As clink regenerates these files, if they are not
present, this also means that we don't need to include the settings file
in the git repo and therefore don't overwrite it on updates.
The new system works by setting "CMDER_START" if a cmder.exe gets a
startup path. The rest is then implemented in the profile.ps1 and init.bat.
The new system works as follows:
1.If a startup path is given, cmder.exe sets this as `CMDER_START` and the
startup scripts change to that directory.
2.If the usere sets a `CMDER_START` environment variable and this is not
overwritten by cmder.exe, this variable is taken as the startup
directory by the startup scripts.
3.If not such path is give, the conemu startup dirs is the winner, as the
startup scripts don't change anything.
If having a long line of input in histroy, which went on into the
second row and using <up> to get back to it, you got the effect
that the input was split over three lines: "text, empty, text",
but using the arrows do move to the front of the first line was
moving the cursor in the second (empty) row. You could change
the text, but you needed to do it "in the dark". No idea why
s/os.execute/is.popen/ fixes this, but it does.
Partly adresses https://github.com/cmderdev/cmder/issues/749
