[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