FS#20288 - [filesystem] 2010-02-4 /etc/profile detects wrongly sh as bash

Attached to Project: Arch Linux
Opened by solsTiCe (zebul666) - Tuesday, 27 July 2010, 10:35 GMT
Last edited by Pierre Schmitz (Pierre) - Sunday, 12 December 2010, 23:39 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Pierre Schmitz (Pierre)
Thomas Bächler (brain0)
Architecture All
Severity Very Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 23
Private No

Details

By investigating bug #20264, it has been found that /etc/profile detects the shell run in a broken way.

ls _l /proc/$$/exe will always return /bin/bash when run from a shell sh or /bin/sh (which is symlink to bash)

so detection of shell in /etc/profile will fail

some folks on #bash on freenode thinks trying to implement profile.$shell for each specific shell is I quote "stupid".

however a way to fix could be to test for $POSIXLY_CORRECT which is set when bash is run as sh
or compile bash with the correct option to use /etc/bash_profile ?

how do other distro deal with diffrent shells in /etc/profile ?
This task depends upon

Closed by  Pierre Schmitz (Pierre)
Sunday, 12 December 2010, 23:39 GMT
Reason for closing:  Fixed
Additional comments about closing:  /etc/profile.$shell is no longer used
Comment by solsTiCe (zebul666) - Tuesday, 27 July 2010, 10:50 GMT
also $SHELL gives the login shell of the user not the running shell. $SHELL does not lie. please remove those comments in /etc/profile
see man login

"the cake is a lie"
Comment by Isaac Gallart (igallart) - Sunday, 01 August 2010, 21:43 GMT
When I installed git and subversion the same problem appeared. But without thats packets, no appear. Arch 64 and gnome.
Comment by Leonid Isaev (lisaev) - Saturday, 07 August 2010, 19:19 GMT
> $SHELL does not lie
I guess what was meant to say is that $SHELL can not be used to determine the currently running shell, which is true.

> however a way to fix could be to test for $POSIXLY_CORRECT which is set when bash is run as sh
Good to know, but still do we confine ourselves to sh/bash only? Besides, on ubuntu I have
-cur_work~> sh
$ echo $POSIXLY_CORRECT

$ echo $SHELL
/bin/bash
So, $SHELL is correct, but $POSIXLY_CORRECT is not... Should we trust env. vars?

I can't test right now, but would $(ps -p "$$" -o comm=) work?

Comment by solsTiCe (zebul666) - Sunday, 08 August 2010, 13:18 GMT
[~]$ /bin/bash
$ echo $(ps -p "$$" -o comm=)
bash
[~]$ /bin/sh
[~]$ echo $(ps -p "$$" -o comm=)
sh
Comment by Leonid Isaev (lisaev) - Sunday, 08 August 2010, 18:00 GMT
Thanks. You are also right in that /proc/$$/exe will keep pointing to bash:
-svibor-13:46-~~> /bin/sh
-svibor-13:46-~~> ps -p $$ -o comm=
sh
-svibor-13:47-~~> ls -l /proc/$$/exe
lrwxrwxrwx 1 lisaev users 0 Aug 8 13:47 /proc/4027/exe -> /bin/bash
-svibor-13:47-~~> exit
exit

So, yeah it looks like that in /etc/profile one should replace "case $(/bin/ls -l /proc/$$/exe) in" with "case $(/bin/ps -p $$ -o comm=) in"...
Also, it may be irrelevant, but what's wrong with /proc/$$/exe pointing to bash when sh is run, if they are the same?
Comment by Nicola Tuveri (romen) - Tuesday, 10 August 2010, 15:32 GMT
Instead of creating a new process to know which was the command by which the current process was started, you can look at the $0 variable

So you may replace with "case $0 in"

Still it would be better to check only the first token of the commandline ($0), as for example when GDM is launched (as for the bug that lead to the opening of this one) the command is "/bin/sh /usr/sbin/gdm"
Comment by Leonid Isaev (lisaev) - Tuesday, 10 August 2010, 16:28 GMT
It will work only in sh/bash/dash/tcsh, but not in csh:
-cur_work~> /bin/csh
% echo $0
No file for $0.
% exit
% exit
-cur_work~>

The problem with ps though, is that filesystem will now depend on procps...
Comment by Nicola Tuveri (romen) - Tuesday, 10 August 2010, 17:03 GMT
you can use:

case $(/bin/cat /proc/$$/cmdline|/bin/cut -d" " -f1) in
Comment by Leonid Isaev (lisaev) - Tuesday, 10 August 2010, 17:32 GMT
OK, that works. Good idea.
Comment by Thomas Bächler (brain0) - Tuesday, 10 August 2010, 17:50 GMT
I don't think reading the name of the shell from the command line or the name of the executable is a good idea. However, I can't think of a better way right now.
Comment by (Lavandero) - Sunday, 14 November 2010, 19:16 GMT
This is absolutely retarded. Why should /etc/profile or any script for that matter protect against env SHELL=bash /bin/sh or any resulting combination?

Just replace it with case $SHELL in, please.
Comment by Pierre Schmitz (Pierre) - Thursday, 18 November 2010, 13:02 GMT
I wonder if we can simplify all this or just get rid of this. If I am correct the only shell that has /etc/profile.$shell is bash. E.g. that is what Ubuntu is doing: http://pastebin.com/XHqN3aj3 I'll check other distros, too.

Loading...