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

Pete Geenhuizen <pete at geenhuizen.net> wrote:
> Initially Bourne was used because it was typically a static binary, 
> because the boot process didn't have access to any shared libraries.  
> When that changed it became a bit of a moot point, and you started to 
> see other interpreters being used.
When dynamic linking was intruduced in 1988, people did kno know what we now 
know and provided sh, mv, tar, ifconfig and mount as statib binaries in
"/sbin".

Since Solaris 10 we know better and there is no static binary anymore.

BTW: the real Bourne Shell is now 100% portable and enhanced since a longer 
time. If you like to test the real Bourne Shell, check the latest schilytools:

	https://sourceforge.net/projects/schilytools/files/

The Bourne Shell is also much faster than bash. In special on platforms like 
Cygwin, where Microsoft enforces extremly slow process creation.
> Even though Solaris started using ksh as the default user environment, 
> almost all of the start scrips were either bourne or bash scripts.  With 
> Bash having more functionality the scripts typically used the 
> environment that suited the requirements best.
There are no bash scripts on Solaris as bash has too many deviatioons from the 
standard.

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/'

Interesting thread i started! Sorry if my question was too vague: -->

On Fri, 4/24/15, Joerg Schilling <Joerg.Schilling at fokus.fraunhofer.de>
wrote:
> The Bourne Shell is also much faster than bash. In special on platforms
like
> Cygwin, where Microsoft enforces extremly slow process creation.
This gets at what I was thinking. For scripts that are not run interactively, it
seems wasteful to load all of Bash autocomplete, command history and all
its rich features.

For running in high volume mail server for example, *short* scripts that take
a few input args and invoke another program. Or do a mysql update (but
it has been pointed out invoking mysql from a shell script is also inefficient
since mysql client is also very feature rich with command history and things).
Or take some arguments and make a curl HTTP request somewhere.

So my question is should I install ksh (I see it is available in yum centos
base repo) and use that? Or should we consider to rewrite these short
scripts to perl? I read on the web that perl with a few typical libraries is
far slower to start up than a shell script.  ??  (no heavy computations)

Just a side tangent was question if it would be of interest to link /bin/sh
to something other than /bin/bash, if machine would implode or if it would
make machine faster in any way.

thanks everyone!

On Fri, Apr 24, 2015 at 3:45 PM, E.B. <emailbuilder88 at yahoo.com>
wrote:
> Interesting thread i started! Sorry if my question was too vague: -->
>
> On Fri, 4/24/15, Joerg Schilling <Joerg.Schilling at
fokus.fraunhofer.de> wrote:
>
>> The Bourne Shell is also much faster than bash. In special on platforms
like
>> Cygwin, where Microsoft enforces extremly slow process creation.
>
> This gets at what I was thinking. For scripts that are not run
interactively, it
> seems wasteful to load all of Bash autocomplete, command history and all
> its rich features.
>
> For running in high volume mail server for example, *short* scripts that
take
> a few input args and invoke another program. Or do a mysql update (but
> it has been pointed out invoking mysql from a shell script is also
inefficient
> since mysql client is also very feature rich with command history and
things).
> Or take some arguments and make a curl HTTP request somewhere.
>
> So my question is should I install ksh (I see it is available in yum centos
> base repo) and use that? Or should we consider to rewrite these short
> scripts to perl? I read on the web that perl with a few typical libraries
is
> far slower to start up than a shell script.  ??  (no heavy computations)
I'd do some serious timing tests in your typical environment before
believing anything about this.  The part that takes substantial time
is if you have to load code from disk.   Anything already running
(loaded from the same inode, so including hard links to different
names) should run shared-text without loading a new copy (also saving
memory...).  Anything that had been loaded recently but needs a new
copy should be reloaded quickly from cache.  Loading a new instance of
some little used interpreter is going to hit the disk.

Your most likely win would be to consolidate operations into longer
scripts and use perl where it can do work that would involve several
other programs as shell commands.   For example, I'd expect a single
perl program with several mysql operations to be much faster than a
shell script that needs to invoke mysql more than once - plus it is a
lot easier to access the data in a perl program.

-- 
   Les Mikesell
     lesmikesell at gmail.com