Remove -i flag being passed to bash for shell mode commands
#25006
Conversation
That seems unsurprising, given that programs can't determine if they were run inside a bash with the |
|
I personally don't think bash aliases should work inside of shell mode. Given that @StefanKarpinski thumbs-upped this PR, have you walked back on your earlier point of view? As a point of comparison, |
|
Not being able to use my aliases will be annoying but this seems to fix bigger problems. We should probably introduce a pure Julia shell mode at some point anyway had have a way of introducing aliases in that instead (and maybe have tools to auto-generate them by parsing your bash scripts). |
fredrikekre
deleted the
sf/first_remove_the_shell_from_your_own_i_before_removing_the_bash_from_your_brothers_i
branch
|
This causes a major problem. There should be work around. I need to have full access to bash in the REPL. |
|
I really do not see what is the point of even having shell interface is does not reflect the user's setup. |
|
@montyvesselinov it would be more helpful if you could explain exactly what you need from your bash aliases in Julia shell mode. Please understand that there have been many conflicting points of view on this, and that you are not the only one who has constraints upon what you would like to see in the shell REPL mode. |
|
@staticfloat I need the aliases and functions defined in my bash rc files to be available in the julia shell. if they are not available i cannot perform all the shell operations. for example, if i run in parallel i would need to login to remote nodes or to use bash scripts to check the load on the remote servers. the way to do this fast is to execute bash functions/aliases in the julia shell. now i need to have a second terminal/window to do this. in the worst case, i think there should be a flag in the julia executable or environmental variable to select the shell behavior: with or wihtout aliases/functions. |
|
I'm not sure if this is related to the At first I thought I must be in the wrong directory before I realized what was going on. Here is how it behaves in julia 0.6 when run from the same directory: In short, I don't really care about aliases, but it would be nice to have wildcards. I am definitely not aware of all the trade-offs that have gone into this change though. |
This was originally added as a workaround for the behavior of sh to try to become the terminal process group leader, but no longer relevant since #25006 removed that flag again: ``` julia> run(detach(`bash -i -c "sleep 0"`)) bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell Process(`bash -i -c 'sleep 0'`, ProcessExited(0)) ``` Julia recieves SIGTTOU when a process like "sh -i -c" exits (at least for bash and zsh, but not dash, ksh, or csh), since "sh -i" sometimes takes over the controlling terminal, causing julia to stop once the bash process exits. This can be quite annoying, but julia goes through some pains (in libuv) to ensure it doesn't steal the controlling terminal from the parent, and apparently bash is not so careful about it. However, since PR #25006, julia hasn't needed this workaround for this issue, so we can now follow the intended behavior when the child is in the same session group and steals the controlling terminal from the parent. Even if such behavior seems odd, this seems to be the intended behavior per posix design implementation that it gets SIGTTOU when julia later tries to change mode (from cooked -> raw after printing the prompt): http://curiousthing.org/sigttin-sigttou-deep-dive-linux. ``` $ ./julia -q shell> bash -i -c "sleep 1" [1]+ Stopped ./julia julia> run(`zsh -i -c "sleep 0"`) Process(`zsh -i -c 'sleep 0'`, ProcessExited(0)) julia> [1]+ Stopped ./julia ```
This was originally added as a workaround for the behavior of sh to try to become the terminal process group leader, but no longer relevant since #25006 removed that flag again: ``` julia> run(detach(`bash -i -c "sleep 0"`)) bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell Process(`bash -i -c 'sleep 0'`, ProcessExited(0)) ``` Long explanation: Julia recieves SIGTTOU when a process like "sh -i -c" exits (at least for bash and zsh, but not dash, ksh, or csh), since "sh -i" sometimes takes over the controlling terminal, causing julia to stop once the bash process exits. This can be quite annoying, but julia goes through some pains (in libuv) to ensure it doesn't steal the controlling terminal from the parent, and apparently bash is not so careful about it. However, since PR #25006, julia hasn't needed this workaround for this issue, so we can now follow the intended behavior when the child is in the same session group and steals the controlling terminal from the parent. Even if such behavior seems odd, this seems to be the intended behavior per posix design implementation that it gets SIGTTOU when julia later tries to change mode (from cooked -> raw after printing the prompt): http://curiousthing.org/sigttin-sigttou-deep-dive-linux. For some background on why this is a useful signal and behavior and should not be just blocked, see nodejs/node#35536. According to glibc, there's a half page of code for how to correctly implement a REPL mode change call: https://www.gnu.org/software/libc/manual/html_node/Initializing-the-Shell.html ``` $ ./julia -q shell> bash -i -c "sleep 1" [1]+ Stopped ./julia julia> run(`zsh -i -c "sleep 0"`) Process(`zsh -i -c 'sleep 0'`, ProcessExited(0)) julia> [1]+ Stopped ./julia ```
This was originally added as a workaround for the behavior of sh to try to become the terminal process group leader, but no longer relevant since #25006 removed that flag again: ``` julia> run(detach(`bash -i -c "sleep 0"`)) bash: cannot set terminal process group (-1): Inappropriate ioctl for device bash: no job control in this shell Process(`bash -i -c 'sleep 0'`, ProcessExited(0)) ``` Long explanation: Julia recieves SIGTTOU when a process like "sh -i -c" exits (at least for bash and zsh, but not dash, ksh, or csh), since "sh -i" sometimes takes over the controlling terminal, causing julia to stop once the bash process exits. This can be quite annoying, but julia goes through some pains (in libuv) to ensure it doesn't steal the controlling terminal from the parent, and apparently bash is not so careful about it. However, since PR #25006, julia hasn't needed this workaround for this issue, so we can now follow the intended behavior when the child is in the same session group and steals the controlling terminal from the parent. Even if such behavior seems odd, this seems to be the intended behavior per posix design implementation that it gets SIGTTOU when julia later tries to change mode (from cooked -> raw after printing the prompt): http://curiousthing.org/sigttin-sigttou-deep-dive-linux. For some background on why this is a useful signal and behavior and should not be just blocked, see nodejs/node#35536. According to glibc, there's a half page of code for how to correctly implement a REPL mode change call: https://www.gnu.org/software/libc/manual/html_node/Initializing-the-Shell.html ``` $ ./julia -q shell> bash -i -c "sleep 1" [1]+ Stopped ./julia julia> run(`zsh -i -c "sleep 0"`) Process(`zsh -i -c 'sleep 0'`, ProcessExited(0)) julia> [1]+ Stopped ./julia ``` (cherry picked from commit 0cbe466)
I do not see the benefit of passing
-itobashfor shell mode commands; it reads in things like.bash_profileon some systems, and in general doesn't seem to be the right move for the quick one-off commands that shell mode is intended for. I am unable to find a program that suffers when run without the-iflag (and if it is really needed, running;bashshould give quick and easy access to those kinds of commands).Fixes #24736
Fixes #17332