[ale] why bash when ksh is default?

Eric eric at uxeric.compgen.com
Mon Mar 18 10:29:26 EST 1996


On the SVR4 I'm using, /sbin/sh is executed for such a script, according
to the output of truss:  


$ echo $SHELL
/usr/bin/bash

$ cat test.sh
echo THIS is a test script $0

$ truss -o /tmp/test.sh.truss test.sh
THIS is a test script ./test.sh

$ cat /tmp/test.sh.truss
execve("/sbin/sh", 0x08044F00, 0x08046438)  argc = 2
getuid()                                        = 209  [ 209 ]
getgid()                                        = 257  [ 257 ]
getuid()                                        = 209  [ 209 ]
getgid()                                        = 257  [ 257 ]
getpid()                                        = 13765  [ 13764 ]
getpgid(13765)                                  = 13764
getsid(13765)                                   = 5867
brk(0x0806B1DC)                                 = 0
sigaction(SIGHUP, 0x00000000, 0x080463E8)       = 0
sigaction(SIGHUP, 0x0804638C, 0x080463C8)       = 0
sigaction(SIGINT, 0x00000000, 0x080463E8)       = 0
sigaction(SIGINT, 0x0804638C, 0x080463C8)       = 0
sigaction(SIGQUIT, 0x00000000, 0x080463E8)      = 0
sigaction(SIGQUIT, 0x0804638C, 0x080463C8)      = 0
sigaction(SIGILL, 0x00000000, 0x080463E8)       = 0
sigaction(SIGILL, 0x0804638C, 0x080463C8)       = 0
sigaction(SIGTRAP, 0x00000000, 0x080463E8)      = 0
sigaction(SIGTRAP, 0x0804638C, 0x080463C8)      = 0
sigaction(SIGABRT, 0x00000000, 0x080463E8)      = 0
sigaction(SIGABRT, 0x0804638C, 0x080463C8)      = 0
sigaction(SIGEMT, 0x00000000, 0x080463E8)       = 0
sigaction(SIGEMT, 0x0804638C, 0x080463C8)       = 0
sigaction(SIGFPE, 0x00000000, 0x080463E8)       = 0
sigaction(SIGFPE, 0x0804638C, 0x080463C8)       = 0
sigaction(SIGBUS, 0x00000000, 0x080463E8)       = 0
sigaction(SIGBUS, 0x0804638C, 0x080463C8)       = 0
sigaction(SIGSEGV, 0x0804638C, 0x080463C8)      = 0
sigaction(SIGSYS, 0x00000000, 0x080463E8)       = 0
sigaction(SIGSYS, 0x0804638C, 0x080463C8)       = 0
sigaction(SIGPIPE, 0x00000000, 0x080463E8)      = 0
sigaction(SIGPIPE, 0x0804638C, 0x080463C8)      = 0
sigaction(SIGALRM, 0x00000000, 0x080463E8)      = 0
sigaction(SIGALRM, 0x0804638C, 0x080463C8)      = 0
sigaction(SIGTERM, 0x00000000, 0x080463E8)      = 0
sigaction(SIGTERM, 0x0804638C, 0x080463C8)      = 0
sigaction(SIGUSR1, 0x00000000, 0x080463E8)      = 0
sigaction(SIGUSR1, 0x0804638C, 0x080463C8)      = 0

..... and so on ...

Unix Guru Dude writes:
 > }
 > }Unix Guru Dude writes:
 > }
 > }> [Michael Ivey:]
 > }
 > }> }I may be mistaken, but I think that scripts get run by /bin/sh, unless it 
 > }> }has a shbang.  This is unrelated to your login shell (/etc/passwd), and 
 > }> }is tied into the way the kernel handles scripts.
 > }> }
 > }> }Again, I may be wrong.
 > }> 
 > }> I would have expected that the SHELL variable would have been used to
 > }> run shells.  Apparently this is not the case.  Anyone else concur?
 > }
 > }My 1.2.8 kernel fails an exec of a script with no "#!".  That means that
 > }the shell (or perhaps a library routine) doing the exec is providing a
 > }backup.  I've seen different ways of doing this in the past -- some shells
 > }just try to interpret the script themselves.  Others automatically pass
 > }it to /bin/sh.  For example, the traditional csh behavior if an exec failed
 > }was to examine the first character of the file; if it was ':', csh itself
 > }interpreted it, otherwise it was passed to /bin/sh.
 > }
 > }The SHELL variable is typically used by programs that want to exec an
 > }*interactive* shell -- it usually isn't expected to have any relevance
 > }to an arbitrary shell script.  I'd guess that's the assumption here too.
 > }
 > }
 > }-- Jeff
 > 
 > In all other versions of UNIX I've used, SCO, SunOS, SVR4...  when youe
 > execute a shell that does not begin with the #!...  It executes using the
 > shell that the SHELL variable is set to.
 > 
 > 
 > -- 
 > Until later:
 > Geoffrey Myers   geof at denali.is.net   eiger at ichange.com   gamyers at attmail.com
 > 	http://www.ticllc.net/~geof
 > 
 > 	Opinions expressed by me are mine, all mine, only mine.....






More information about the Ale mailing list