-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Newlines and Carriage Returns Following $()
Command Substitution Cause Bash Parse Error
#3303
Comments
Does this also happen in a regular MSYS2 Bash? |
BTW you can easily work around that issue: PS1='$(echo test)
' (Note the literal line break before the closing quote, and also note that you need not |
Just tested it, and it looks like it does (though I haven't tested every single case, the simple case of Does this mean the issue needs to be raised somewhere else? |
The problem that led me to actually create this issue was that of the carriage return - enough workarounds exist for the newline character, but very few also work with the carriage return which led to a bit of a headache. As I said before I was able to work around this, but it was a bit annoying to say the least. |
The next step to test would be Cygwin. MSYS2 is a close derivative of Cygwin, and to pinpoint where exactly the bug exists, it would be good to know whether Cygwin shares the behavior of MSYS2's. |
Looks like Cygwin doesn't have an issue with any of the tests, and behaves as expected. ndDIiugC6p.mp4I also went back and tested MSYS2 again, and found that newer installations of it still failed, but with different error messages. An older installation (Bash 4.4.023-1): S9p5YwSFiZ.mp4A newer installation (Bash 5.1.004-1): OIzpiejwYU.mp4(I just wrote the Bash versions above as markers of their approximate age, since afaik MSYS2 doesn't have a canonical version. That's also why I included the output of |
Closing as stale. |
The problem still exists. It's reported in the upstream MSYS2: msys2/MSYS2-packages#1839 |
Setup
I'm Using
Git-2.32.0-64-bit
, the latest release as of writing:I'm running Windows 10 64-bit:
My installation options:
Any other interesting things about your environment that might be related to the issue you're seeing?
I decided to make a custom
.bashrc
for my Windows installation, including setting up a custom$PS1
. This is where I encountered the issue.Details
Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
I'm running MSYS2, Git Bash.
What commands did you run to trigger this issue?
Run the following:
After running either of these, every time
$PS1
is evaluated, bash outputs an error:APitaD9vi0.mp4
T9UOAS7l1R.mp4
The cause is the newline or carriage return character. If it's removed, the
$PS1
works as expected:xqiRFZP3Rm.mp4
This seems to be a long-known issue exclusive to Git for Windows (https://stackoverflow.com/a/41925324/6003488) however there's more that I found.
Replacing the
$()
with backticks avoids the issue for both the newline and carriage return:w7tjdwuHHR.mp4
bTLHlczZp0.mp4
And replacing the newline character with it's ASCII character code also avoids the issue, but this only works for the newline:
ByzCwZjmRU.mp4
h4EQlxdHcQ.mp4
Outputting the newline as a direct character sequence works, but doing the same with a carriage return doesn't work:
wq85YFEenu.mp4
IIUOqH5pew.mp4
Outputting the characters from a separate function seems to work so long as the function call is done every time
$PS1
is evaluated, rather than upon definition:gEb2sMTd4L.mp4
7rsPVSRQ3j.mp4
What did you expect to occur after running these commands?
I expected the new
$PS1
variable to be evaluated without error, the same way the bash string would be if used outside of$PS1
.What actually happened instead?
I got an obscure, unhelpful error that indicated the bash installation was having trouble parsing the new
$PS1
variable, even though it should be valid bash.Additional Notes
Apologies if there exists an issue that mentions this already. I looked and didn't find one, and figured I'd gather all the information I know about the issue and post it so it can hopefully finally be resolved.
I don't know much more about the issue, other than this. I was able to work around the problem by using the separate function method for my use of a carriage return, but obviously that's not a proper solution.
The text was updated successfully, but these errors were encountered: