GNOME Bugzilla – Bug 602141
terminals fail to launch in non-bash shells
Last modified: 2019-08-14 08:36:20 UTC
Created attachment 147938 [details] patch removing the "-l" option which we use on Solaris to work around this issue If you right-click on the desktop and select "Open Terminal", the terminal will briefly show and quickly (and visibly) crash if the user is not using bash as their shell. This is because the current code launches gnome-terminal via the user's shell (via the $SHELL environment variable) and nautilus-open-terminal always adds a "-l" option when calling "$SHELL". This "-l" argument is a bash-only feature and is used to start the shell as a "login shell". This argument does not work with Solaris bourne-shell, ksh, ksh93, or c-shell. I am not sure why it is necessary to launch the gnome-terminal with this option at all. In talking with Behdad, he said that it is a bad idea to launch gnome-terminal with a shell at all. Instead, he thinks it would be better to just run the gnome-terminal program directly. If launching gnome-terminal via the shell is needed, why is the "-l" option needed? If it is needed, then should we perhaps code this a different way that works across all shells instead of just with bash? If it is only needed when calling bash, then perhaps the launch command should be changed so it checks if bash is actually being used and adds "-l" only when appropriate. At any rate, on Solaris, we are now patching the code to simply remove the "-l" option altogether. Since the default shell on Solaris is bourne-shell and the default shell on OpenSolaris is ksh93, most users need this to be removed in order to be able to launch the gnome-terminal at all via nautilus-open-terminal. This seems to work reasonably.
Just another comment, it really doesn't make sense for nautilus-open-terminal to use the $SHELL environment variable if the code is written so it only works if the $SHELL value happens to be bash.
Dear Brian, thanks for your bug report. Most of this has already been discussed in the Ubuntu bug tracker [1]. > This "-l" argument is a bash-only feature and is used to start the shell as a "login shell". This argument does not work with Solaris bourne-shell, ksh, ksh93, or c-shell. I just checked that it works with bash, dash and csh. On the other hand, I just downloaded the IEEE POSIX spec, and it just specifies "sh[ell]" to open an interactive shell, while at some other point briefly mentioning login shell without any invocation hints. It does not specify any parameters for "sh". Therefore, we probably have to drop it. > In talking with Behdad, he said that it is a bad idea to launch gnome-terminal with a shell at all. For opening the shell in a specific directory, I decided to execute "cd <target_directory> && exec $SHELL" instead of setting the working directory of the terminal application. The reason is that if the working directory is set to removable media, removal is not possible unless the terminal is closed. > If launching gnome-terminal via the shell is needed, why is the "-l" option needed? It was originally introduced in nautilus-open-terminal in the context of remote SSH terminals [2] in arbitrary remote directories. Reading the OpenSSH source code, tries to open a remote *login* shell in session.c:do_child(): * If we have no command, execute the shell. In this case, the shell * name to be passed in argv[0] is preceded by '-' to indicate that * this is a login shell. */ However, as mentioned in the comment it does that using "-" and not using "-l". I couldn't find the former in POSIX either at a quick glance, but it seems to be a historical convention that it opens a login shell. After the code was introduced in nautilus-open-terminal for SSH connections, it was also blindly ported to the non-SSH case. I am totally open to the removal of "-l". If you read [1], you will see that I just tried to understand the notion of interactiveness, non-interactiveness, login and non-login shells before changing anything. However, now that I read through all the source codes, I think it's the best to * open "$SHELL -" (i..e login shell) in the SSH case * open "$SHELL" (i.e. no login shell) in the local case. Do you think that this is a good rationale? [1] https://bugs.launchpad.net/ubuntu/+source/nautilus-open-terminal/+bug/448337 [2] http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?tp=&isnumber=29073&arnumber=1309816&punumber=9158 [3] http://git.gnome.org/cgit/nautilus-open-terminal/commit/?id=865ebd6324aab4d54aa6a1da20120e02188b6cdb
One last comment: The GNOME terminal preferences dialog has an option for the user to force login mode. GNOME terminal obeys this when the user did not pass any command, and it opens a $SHELL. Maybe for full integration - when gnome-terminal is opened - we append "-" to $SHELL iff /apps/gnome-terminal/profiles/Default/login_shell is true. I am CCing gnome-terminal-maint, because it would be interesting to find out why this login switch was introduced in gnome-terminal at all.
(In reply to comment #2) > > In talking with Behdad, he said that it is a bad idea to launch gnome-terminal with a shell at all. > > For opening the shell in a specific directory, I decided to execute "cd > <target_directory> && exec $SHELL" instead of setting the working directory of > the terminal application. The reason is that if the working directory is set to > removable media, removal is not possible unless the terminal is closed. I don't think that's true with current g-t. The factory now chdirs to $HOME, so it doesn't hog the mountpoint. So after closing the tab, or just cd'ing to another dir, the media should be removable again. (See bug 565328.)
> However, now that I read through all the source codes, I think it's the best to > * open "$SHELL -" (i..e login shell) in the SSH case > * open "$SHELL" (i.e. no login shell) in the local case. This seems more reasonable, and more portable to me.
Finally: Fixed & released nautilus-open-terminal 0.18.
It's not working with tcsh. When I connect to a machine (where I'm not authorized to change the shell) with this command I get: ssh my.machine.com -t 'cd '/home/piel' && exec $SHELL -' -: No such file or directory. Maybe it could detect that ssh failed after less than 2 seconds and try to rerun it without the "-"?
There is another problem here: Path settings are usually done in ~/.bash_profile rather than ~/.bashrc. This file is read by login shells but not interactive shells. This is partly so that additions to the path, PATH=$PATH:/foo/bar don't accumulate as one shell executes another. See also [1]. The ~/.bashrc file is read by interactive shells but not by login shells. So now in Fedora 21, when I open a terminal using nautilus, the path isn't set properly because it doesn't launch with a login shell. [1] http://unix.stackexchange.com/questions/26047/how-to-correctly-add-a-path-to-path
This fix committed to nautilus-open-terminal as r276, and later migrated to gnome-terminal was faulty. A login shell is denoted by argv[0][0] (the program name's first character) being a dash, not by the first parameter argv[1] being a dash. Continued in https://gitlab.gnome.org/GNOME/gnome-terminal/issues/151.