-
-
Notifications
You must be signed in to change notification settings - Fork 300
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
gdb not working inside elvish #1795
Comments
That behavior is news to me. And apparently all the traditional POSIX-ish shells exhibit this behavior 🤯: ~> bash -c "echo $$; bash -c 'echo $$'"
92128
92128
~> zsh -c "echo $$; bash -c 'echo $$'"
92138
92138
~> dash -c "echo $$; bash -c 'echo $$'"
92140
92140
~> ksh -c "echo $$; bash -c 'echo $$'"
92163
92163
~> elvish -c "echo $pid; bash -c 'echo $$'"
92144
92145 (Note how every other shell outputs the same PID twice, except Elvish). I wonder if this behavior is mandated by POSIX, but regardless, I suppose the more traditional shells can do this because there's no difference in observed behavior whether the last command is fork/exec-ed or simply exec-ed (other than the value of PID). Elvish can't really do this because if the last command exits with non-zero, Elvish will do something extra - it shows a stacktrace. These two scripts behave differently: false exec false I'd recommend that you either don't configure Elvish as the login shell (make it the default shell of the terminal instead) or use the |
Understood. BTW, ending
|
Be careful with double-quoted string interpolation:
And...
I don't know why the use of a non-POSIX shell by
|
Also, note that other complex interactive programs like Whenever I see a problem like this the first question I ask is what are the arguments passed to the program launched by a program like |
Yes, that's why I used single quotes in the argument to
I don't know about your version of bash or if you have any configuration, but this command outputs two identical numbers in the second and third lines on both my macOS machine and Linux machine. |
It's not clear we are talking about the same thing because it isn't obvious from your examples what the initial context is. In particular, which shell is evaluating the statements you ran. For example, what shell did you run the following command block:
That only produces the same two lines if the shell running that statement is a POSIX shell like Bash. And that is because the interpolation done by Bash for the
The difference is due to the fact that Elvish does not replace the Try this from a Bash prompt:
Note that the presence of
|
Those were all from Elvish. Again, I think there's something different about your bash - I consistently get the same PIDs twice running |
I hate mysteries when the observed behavior is contrary to my expectations so I did a quick experiment. I have nine systems that I use for development. Two macOS on bare metal (Apple Silicon/arm64 and x86_64), five Linux distros, FreeBSD 13, and Windows (all as VMs hosted by VMware). Ignoring Windows I see the behavior I reported on six of those systems, and two of them exhibit the behavior observed by @xiaq. The newest Bash version I have available that behaves as I originally reported is Bash 5.0.17. The oldest version I have available that behaves as @xiaq reported is Bash 5.2.15. So sometime after the release of Bash 5.0.17 an optimization was introduced that sometimes elides the
There may, of course, be other things that inhibit the So the question why the PID reported by the last process spawned by Bash is sometimes the same and sometimes different is no longer a mystery. Sadly, I don't think this explains why Elvish is incompatible with Gdb. The most likely explanation is that Gdb is spawning Elvish to run a command block that is valid POSIX syntax but invalid Elvish syntax. |
P.S., I don't have any Bash customization on any of my systems. No ~/.bashrc, ~/.bash_profile, ~/.profile, etc. Only whatever initialization scripts are provided by the OS. |
As a fun aside... If you do an internet search for "bash fork optimization" you'll get results like https://stackoverflow.com/questions/76310409/does-bash-promise-to-optimize-c-into-plain-exec-in-simple-cases. In other words, whether Bash should sometimes elide the final |
What happened, and what did you expect to happen?
compile with gcc:
gcc test.c
.As you can see, breakpoint isn't hit.
By comparison, when I use bash, everything works fine:
BTW, I tried to dig out the reason until I encounter this: https://stackoverflow.com/a/64274727.
Simply put, the rootcause is that the behavior of
elvish -c
andbash -c
is different.Output of "elvish -version"
0.20.0-dev.0.20240201150239-7e0b6ee8e626
Code of Conduct
The text was updated successfully, but these errors were encountered: