CentOS - Apr 2015 - Real sh? Or other efficient shell for non-interactive scripts

On 04/24/2015 03:57 AM, Pete Geenhuizen wrote:
> if you leave it out the script will run in whatever environment it
> currently is in.
I'm reasonably certain that a script with no shebang will run with 
/bin/sh.  I interpret your statement to mean that if a user is using ksh 
and enters the path to such a script, it would also run in ksh.  That 
would only be true if you "sourced" the script from your shell.

On 4/24/2015 10:47 AM, Gordon Messmer wrote:
> On 04/24/2015 03:57 AM, Pete Geenhuizen wrote:
>> if you leave it out the script will run in whatever environment it
>> currently is in.
>
> I'm reasonably certain that a script with no shebang will run with
> /bin/sh.  I interpret your statement to mean that if a user is using ksh
> and enters the path to such a script, it would also run in ksh.  That
> would only be true if you "sourced" the script from your shell.
A script with no shebang will run in the environment of the account 
running the script.  If that account is root and root uses the bash 
shell then the script will run in the bash shell.  If that account uses 
the korn shell then the script will run in a korn shell... etc.  So it 
depends and Pete was more correct.

All the Sun systems I worked on (way in the past) had the bourne shell 
on the root account and I usually set my account up with a korn shell. 
On linux boxes both the root and personal account use the bash shell. 
Some systems will use a C shell, and, of course, other choices.

If you want a script to run under a specific shell you NEED the shebang 
line at the beginning.  Assuming the bourne shell as a default is not 
reliable.

If you use good coding practices you will have that shebang line at the 
beginning of all scripts.

On 4/24/2015 9:47 AM, Gordon Messmer wrote:
> On 04/24/2015 03:57 AM, Pete Geenhuizen wrote:
>> if you leave it out the script will run in whatever environment it
>> currently is in.
>
> I'm reasonably certain that a script with no shebang will run with 
> /bin/sh.  I interpret your statement to mean that if a user is using 
> ksh and enters the path to such a script, it would also run in ksh.  
> That would only be true if you "sourced" the script from your
shell.
oh fun, just did some tests (using c6.latest).   if you're in bash, 
./script (sans shebang) runs it in bash.  if you're in dash or csh, 
./script runs it in sh.    if you're in ksh, it runs it in ksh.





-- 
john r pierce, recycling bits in santa cruz

On Fri, April 24, 2015 12:04 pm, John R Pierce wrote:
> On 4/24/2015 9:47 AM, Gordon Messmer wrote:
>> On 04/24/2015 03:57 AM, Pete Geenhuizen wrote:
>>> if you leave it out the script will run in whatever environment it
>>> currently is in.
>>
>> I'm reasonably certain that a script with no shebang will run with
>> /bin/sh.  I interpret your statement to mean that if a user is using
>> ksh and enters the path to such a script, it would also run in ksh.
>> That would only be true if you "sourced" the script from your
shell.
>
> oh fun, just did some tests (using c6.latest).   if you're in bash,
> ./script (sans shebang) runs it in bash.  if you're in dash or csh,
> ./script runs it in sh.    if you're in ksh, it runs it in ksh.
>
Wow! Surprise ;-)

I just tested it on my FreeBSD workstation, and all works as expected
(i.e. the script obeys shebang). Just in case, here is the contents of my
test script:


########
#!/bin/sh

readlink /proc/$$/file
########

( note that that "file" is because I'm using FreeBSD /proc, for
Linux you
may need to replace the line with something like:

readlink /proc/$$/exe

Now the fun part

in bash:

$ echo $0
bash

$ ./test
/bin/sh

in tcsh

% echo $0
tcsh

% ./test
/bin/sh

in zsh

% echo $0
zsh

% ./test
/bin/sh

But yet funnier thing:

$ bash ./test
/usr/local/bin/bash

$ tcsh ./test
/bin/tcsh

$ zsh ./test
/usr/local/bin/zsh


Well, no creepy surprises for me ! ;-)

(you can do the same on Linux of your choice and see if it behaves ;-)

Thanks.
Valeri

++++++++++++++++++++++++++++++++++++++++
Valeri Galtsev
Sr System Administrator
Department of Astronomy and Astrophysics
Kavli Institute for Cosmological Physics
University of Chicago
Phone: 773-702-4247
++++++++++++++++++++++++++++++++++++++++

On Fri, Apr 24, 2015 at 12:04 PM, John R Pierce <pierce at hogranch.com>
wrote:
> On 4/24/2015 9:47 AM, Gordon Messmer wrote:
>>
>> On 04/24/2015 03:57 AM, Pete Geenhuizen wrote:
>>>
>>> if you leave it out the script will run in whatever environment it
>>> currently is in.
>>
>>
>> I'm reasonably certain that a script with no shebang will run with
>> /bin/sh.  I interpret your statement to mean that if a user is using
ksh and
>> enters the path to such a script, it would also run in ksh.  That would
only
>> be true if you "sourced" the script from your shell.
>
>
> oh fun, just did some tests (using c6.latest).   if you're in bash,
./script
> (sans shebang) runs it in bash.  if you're in dash or csh, ./script
runs it
> in sh.    if you're in ksh, it runs it in ksh.
>
If I'm doing cron jobs or a top-level control script I usually just
specify the interpreter explicitly like
 cd somewhere && sh some_script.sh
 cd somewhere_else && perl some_script.pl
so it works even if I forget to chmod it executable...

-- 
   Les Mikesell
     lesmikesell at gmail.com

On 04/24/2015 09:59 AM, Steve Lindemann wrote:
>
> A script with no shebang will run in the environment of the account
> running the script.
Bad test on my part, apparently.

$ python
 >>> import os
 >>> os.execv('/home/gmessmer/test', ('test',))
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
OSError: [Errno 8] Exec format error

So a script with no shebang will fail when the shell calls exec().  If 
that's so, then starting the executable script with an interpreter is 
probably shell-defined.  In other words, each shell might do something 
different to run a script that has no shebang.  Most probably do default 
to trying itself as the interpreter first.  Interesting.

On Fri, Apr 24, 2015 at 09:47:24AM -0700, Gordon Messmer
wrote:
> On 04/24/2015 03:57 AM, Pete Geenhuizen wrote:
> >if you leave it out the script will run in whatever environment it
> >currently is in.
> 
> I'm reasonably certain that a script with no shebang will run with 
> /bin/sh.  I interpret your statement to mean that if a user is using ksh 
"It depends".

On older Unix-type systems which didn't understand #! then the shell
itself did the work.  At least csh did (sh didn't necessary).  If the
first character was a # then csh assumed it was a csh script, otherwise
it assumed a sh script.  That's why a lot of real old scripts began with :
> and enters the path to such a script, it would also run in ksh.  That 
> would only be true if you "sourced" the script from your shell.
So on CentOS 5 with ksh93 as my shell

  % cat x
  echo ${.sh.version}

Note that it's a simple one liner with no #!

  % ./x
  Version AJM 93t+ 2010-06-21

That's ksh output!

Let's change my shell to "bash" instead
  % bash
  bash-3.2$ ./x
  ./x: line 1: ${.sh.version}: bad substitution

So now it's bash that's trying to interpret it!

So "it depends" is still true :-)

Basically, without #! there (which allows it to be exec'd) the shell
determines how the file is interpreted.

-- 

rgds
Stephen

Gordon Messmer <gordon.messmer at gmail.com> wrote:
> I'm reasonably certain that a script with no shebang will run with 
> /bin/sh.  I interpret your statement to mean that if a user is using ksh 
> and enters the path to such a script, it would also run in ksh.  That 
> would only be true if you "sourced" the script from your shell.
The historical way is: there is only one shell and all scripts are Bourne Shell 
scripts.

Then csh came out and some people really thought is was a good idea to write 
csh scripts. So someone decided to mark csh scripts with an initial
"#".
Note that at that time, the Bourne Shell did not support "#" as a
comment sign
and thus scripts with an inital "#" have been illegal Bourne Shell
scripts.

Later BSD came out with #!name and all but AT&T adopted to this.

In the mid 1980s, AT&T introduced an initial ":" to mark Bourne
Shell scripts.

In 1989, with the beginning of SVr4, even AT&T introduced #!name, but the
AT&T
variant of the OS did not correct their scripts, so if you are on a UnixWare 
installation, you will have fun.

Unfortunately, POSIX cannot standardize #!name. This is because POSIX does not 
standardize PATHs and because the scripts marked that way would need to be 
scripts that call the POSIX shell. The official method to get a POSIX shell is 
to call this:

	sh			# to make sure you have a Bourne Shell alike
	PATH=`getconf PATH`	# to get a POSIX compliant PATH
	sh			# to get a POSIX shell, that muust be the first
				# 'sh' in the POSIX PATH

/bin/sh definitely does not start a POSIX shell.....

J?rg

-- 
 EMail:joerg at schily.net                    (home) J?rg Schilling D-13353
Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/'

John R Pierce <pierce at hogranch.com> wrote:
> oh fun, just did some tests (using c6.latest).   if you're in bash, 
> ./script (sans shebang) runs it in bash.  if you're in dash or csh, 
> ./script runs it in sh.    if you're in ksh, it runs it in ksh.
See my other mail.

The scripts (unless marked) are run by the current interpreter. Csh
runs unmarked scripts by "sh".

J?rg

-- 
 EMail:joerg at schily.net                    (home) J?rg Schilling D-13353
Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/'

Stephen Harris <lists at spuddy.org> wrote:
> On Fri, Apr 24, 2015 at 09:47:24AM -0700, Gordon Messmer wrote:
> > On 04/24/2015 03:57 AM, Pete Geenhuizen wrote:
> > >if you leave it out the script will run in whatever environment it
> > >currently is in.
> > 
> > I'm reasonably certain that a script with no shebang will run with
> > /bin/sh.  I interpret your statement to mean that if a user is using
ksh
>
> "It depends".
>
> On older Unix-type systems which didn't understand #! then the shell
> itself did the work.  At least csh did (sh didn't necessary).  If the
> first character was a # then csh assumed it was a csh script, otherwise
> it assumed a sh script.  That's why a lot of real old scripts began
with :
As mentioned in the other mail, nearly all UNIX versions did support #! in the
mid-1980s. The only exception was AT&T.

Even the first (realtime) UNIX clone UNOS added support for #! in 1985, but 
this support was not in the kernel but in the standard command interpreter.

J?rg

-- 
 EMail:joerg at schily.net                    (home) J?rg Schilling D-13353
Berlin
       joerg.schilling at fokus.fraunhofer.de (work) Blog:
http://schily.blogspot.com/
 URL:  http://cdrecord.org/private/
http://sourceforge.net/projects/schilytools/files/'