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

On 04/24/15 06:57, Pete Geenhuizen wrote:
>
> On 04/24/15 06:07, E.B. wrote:
>> I'm sure most people here know about Dash in Debian. Have there
>> been discussions about providing a more efficient shell in Centos
>> for use with heavily invoked non-interactive scripts?
>>
>> With sh being a link to bash in Centos I don't know if it would
>> explode if the link was changed to something else, but at least
>> the scripts we made on our own that run certain services could
>> be changed and tested manually to another shell.
>>
>> Are there other people who have experience in this and can
>> provide interesting guidance?
>>
> Why go to that extreme if you tell a script on line 1 which shell to run it
> will do so.
> #!/bin/dash
> or what ever shell you want it to run in.  I always do that to make sure
that
> the script runs as expected, if you leave it out the script will run in
> whatever environment it currently is in.
>
I'm confused here, too, and this has been bugging me for some time: why sh, 
when almost 20 years ago, at places I've worked, production shell scripts
went
from sh to ksh. It was only after I got into the CentOS world in '09 that I 
saw all the sh scripts again.

	mark

On Fri, Apr 24, 2015 at 08:02:56AM -0400, mark wrote:
> On 04/24/15 06:57, Pete Geenhuizen wrote:
> >
> >On 04/24/15 06:07, E.B. wrote:
> >>I'm sure most people here know about Dash in Debian. Have there
> >>been discussions about providing a more efficient shell in Centos
> >>for use with heavily invoked non-interactive scripts?
> >>
> >>Are there other people who have experience in this and can
> >>provide interesting guidance?
> >>
> >Why go to that extreme if you tell a script on line 1 which shell to
run it
> >will do so.
> >#!/bin/dash
> >or what ever shell you want it to run in.  I always do that to make
sure that
> >the script runs as expected, if you leave it out the script will run in
> >whatever environment it currently is in.
> >
> 
> I'm confused here, too, and this has been bugging me for some time:
> why sh, when almost 20 years ago, at places I've worked, production
> shell scripts went from sh to ksh. It was only after I got into the
> CentOS world in '09 that I saw all the sh scripts again.
Wasn't Solaris, which for awhile at least, was probably the most popular
Unix, using ksh by default?


-- 
Scott Robbins
PGP keyID EB3467D6
( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
gpg --keyserver pgp.mit.edu --recv-keys EB3467D6

It was the mid/late-90s, but I seem to recall Bourne being the default
shell, although sh/ksh/csh were all available with a typical install.

On Fri, Apr 24, 2015 at 8:32 AM, Scott Robbins <scottro at nyc.rr.com>
wrote:
> On Fri, Apr 24, 2015 at 08:02:56AM -0400, mark wrote:
> > On 04/24/15 06:57, Pete Geenhuizen wrote:
> > >
> > >On 04/24/15 06:07, E.B. wrote:
> > >>I'm sure most people here know about Dash in Debian. Have
there
> > >>been discussions about providing a more efficient shell in
Centos
> > >>for use with heavily invoked non-interactive scripts?
> > >>
> > >>Are there other people who have experience in this and can
> > >>provide interesting guidance?
> > >>
> > >Why go to that extreme if you tell a script on line 1 which shell
to
> run it
> > >will do so.
> > >#!/bin/dash
> > >or what ever shell you want it to run in.  I always do that to
make
> sure that
> > >the script runs as expected, if you leave it out the script will
run in
> > >whatever environment it currently is in.
> > >
> >
> > I'm confused here, too, and this has been bugging me for some
time:
> > why sh, when almost 20 years ago, at places I've worked,
production
> > shell scripts went from sh to ksh. It was only after I got into the
> > CentOS world in '09 that I saw all the sh scripts again.
>
> Wasn't Solaris, which for awhile at least, was probably the most
popular
> Unix, using ksh by default?
>
>
> --
> Scott Robbins
> PGP keyID EB3467D6
> ( 1B48 077D 66F6 9DB0 FDC2 A409 FA54 EB34 67D6 )
> gpg --keyserver pgp.mit.edu --recv-keys EB3467D6
>
> _______________________________________________
> CentOS mailing list
> CentOS at centos.org
> http://lists.centos.org/mailman/listinfo/centos
>


-- 

*Doug Eckert*
*Technical Architect*

*Global Business Technology*
*Dow Jones* | *A News Corporation Company*
P.O. Box 300 | Princeton NJ 08543-0300
(W) 609.520.4993 (C) 732.666.3681
*Email: **doug.eckert at dowjones.com* <alias at dowjones.com>

On Fri, Apr 24, 2015 at 7:02 AM, mark <m.roth at 5-cent.us>
wrote:
>
>>> I'm sure most people here know about Dash in Debian. Have there
>>> been discussions about providing a more efficient shell in Centos
>>> for use with heavily invoked non-interactive scripts?
>>>
>>> With sh being a link to bash in Centos I don't know if it would
>>> explode if the link was changed to something else, but at least
>>> the scripts we made on our own that run certain services could
>>> be changed and tested manually to another shell.
>>>
>>> Are there other people who have experience in this and can
>>> provide interesting guidance?
>>>
>> Why go to that extreme if you tell a script on line 1 which shell to
run
>> it
>> will do so.
>> #!/bin/dash
>> or what ever shell you want it to run in.  I always do that to make
sure
>> that
>> the script runs as expected, if you leave it out the script will run in
>> whatever environment it currently is in.
>>
>
> I'm confused here, too, and this has been bugging me for some time: why
sh,
> when almost 20 years ago, at places I've worked, production shell
scripts
> went from sh to ksh. It was only after I got into the CentOS world in
'09
> that I saw all the sh scripts again.
>
The original ksh wasn't open source and might even have been an
extra-cost item in AT&T unix.   And the early emulations weren't
always complete so you couldn't count on script portability.  I
generally thought it was safer to use perl for anything that took more
than bourne shell syntax.

But as for efficiency, I'd think a script would have to do quite a lot
of work to offset the need to page in different code for the
interpreter.  Any unix-like system should almost always have some
instances of sh running and other instances of the same executable
should run shared-text, where invoking a shell that isn't already
loaded will have to load the code off the disk.

-- 
   Les Mikesell
     lesmikesell at gmail.com

On Fri, Apr 24, 2015 at 08:32:45AM -0400, Scott Robbins
wrote:
> Wasn't Solaris, which for awhile at least, was probably the most
popular
> Unix, using ksh by default?
Solaris /bin/sh was a real real dumb version of the bourne shell.
Solaris included /bin/ksh as part of the core distribution (ksh88 was a
part of the SVr4 specification) and so many scripts were written with
#!/bin/ksh at the start (including tools like "patchadd").

Note Solaris had bugs in those tools because they didn't start
"#!/bin/ksh -p" so if you had a $ENVFILE that included lines like
"set
-o noclobber" or had aliases then scripts would break (patchadd was a
perfect example).  Many of these got fixed by Solaris 8 :-)

-- 

rgds
Stephen

On 04/24/15 05:59, Les Mikesell wrote:
> The original ksh wasn't open source and might even have been an
> extra-cost item in AT&T unix.   And the early emulations weren't
> always complete so you couldn't count on script portability.  I
> generally thought it was safer to use perl for anything that took more
> than bourne shell syntax.
You're right about the extra cost.  In 1989 I bought the ksh source code 
from AT&T for $100.

Jack