best shell for writing a shell script

[Shivkumar]

Dear Sirs,

While writing a shell script which shell is best to use:-

$ whereis sh
sh: /sbin/sh /usr/bin/sh /usr/newconfig/sbin/sh

$ whereis ksh
ksh: /usr/bin/ksh

I also noticed at various shell scripts use of #!/bin/sh

why born shell sh are located at different paths ? which is the real and correct one ?

Which is the best path to specify the shell path ?

Can i use ksh shell instead of sh ? what are the things i need to think while using ksh as shell for writing sys admin related scripts ?

Will it create an issue if a shell script written in korn shell executed from a born shell ?

Thanks,
Shiv

[Victor Fridyev · Accepted solution]

Hi,

Look at ls -ls {all shells} and you will see that almost all these files are the same.
Depending on the installation, you may have to different SH shells /bin/sh and /usr/bin/sh. /bin/sh is a small one and it works in single user mode.

ksh and sh are amost the same in HPUX, AFAIK. I did not see any difference when I used #!/usr/bin/sh and #!/usr/bin/ksh
It seems to me, there was a problem with transferring PATH to children processes in ksh.

[Steven E. Protter]

Shalom again Shiv,

There is almost no difference between the Posix Shell and the Korn Shell. They are 99% alike.

I generally use /usr/bin/sh for the Posix shell. The one root uses has special functionality for root only. Though others can use it, root's should never be changed.

Korn is /usr/bin/ksh

I generally go with the right tool for the job approach, which means I use the shell that came with the product I'm working with. If Oracle scripts shipped with a particular shell, there is a finite possibility that they actually tested them under that shell on HP-UX(not 100% for certain).

In practical terms 99% of the time you can use Posix and Korn interchangibly.

SEP

[A. Clay Stephenson]

The Bourne shell is almost never used these days on any UNIX platform. Under HP-UX both /sbin/sh and /usr/bin/sh are the POSIX shell and that is the preferred weapon of choice. #!/usr/bin/sh should be used on all your scripts other than those which might have to be executed before /usr is mounted. The difference between /usr/bin/sh and /sbin/sh is that /sbin/sh is statically linked whereas /usr/bin/sh is dynamically linked. This means that the /usr/bin/sh is more memory efficient especially when multiple copies of the shell are running.

The Korn shell and POSIX shell are all but identical. Despite its popularity, the one shell I tend to avoid is bash -- even on Linux. I have found that this construct:
echo "One Two Three" | read A B C
often fails under bash implementations; the most consistant shell for Linux that I have found is zsh.

[A. Clay Stephenson]

By the way, the most consistant shell that I have found across all platforms (even Windows) is Perl. That is what I use for all my new development these days.

[James R. Ferguson]

Hi Shiv:

Everyone has their own idea of "best". After all, if that wasn't true then there wouldn't be any more than one variation of anything.

That said, I'll direct my answers to the HP-UX environment.

First, '/bin' is a deprecated path called a "transition link". Transition links are symbolic links dating to the HP-UX version 9-to-10 era when the the layout of the filesystems was redrawn. In 11i version 3 (not yet released) I believe that these links will finally disappear. Hence, do not use them. That is, don't write "/bin/sh". Instead write "/usr/bin/sh".

The default shell for HP-UX is the Posix shell which lives as '/usr/bin/sh' or as '/sbin/sh'. The difference is that the shell binary in '/usr/bin' uses dynamically linked libraries (ones whose linkage is resolved at runtime) whereas the '/sbin/sh' binary uses statically linked libraries (built at compile-time).

The advantage to having dynamic libraries is that multiple users share some common code and therefore the overall memory footprint of each instantiation of the shell is less than multiple users of the statically linked shell.

However, since '/usr' isn't mounted in single-user mode; and/or when scripts are run during bootup *before* '/usr' is mounted; a statically linked binary with everything tidily set is a requirement during bootup. This is the reason that the '/sbin/sh' binary should *always* be the one used for 'root'. If you fail to heed the advise, you would find that your system won't startup.

The Posix shell is exceedly close to a Korn shell and the two are virtually interchangeable. You can find a Korn88 shell in '/usr/bin/ksh' and a Korn93 shell in '/usr/dt/bin/dtksh'.

The C shell is lives in '/usr/bin/csh', but I wouldn't use it at all. There are a multitude of resaons why *not* to use it, and they are well enumerated here:

http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/

The very, old, Bourne shell can still be found as '/usr/old/bin/sh' but is virtually useless.

Other shells have been ported to HP-UX. The "Boune-Again_Shell" ('bash') is one popular one. Generally, these, and others often would be installed in '/usr/bin'. Exactly where they live matters less than the fact that the scripts that use them would declare their interpreter with the "she-bank" sequence -- "#!/usr/bin/bash" for instance, to tell that the script is a 'bash' shell script. The "she-bang" characters (#!) tell the kernel that what follows is the interpreter, or program to use.

A very good site for shell scripts and tips is:

http://www.shelldorado.com/

A guide to shells can be found here:

http://docs.hp.com/en/B2355-90046/index.html

All shell scripts start with a declaration of the shell interpreter, clearly identifing the shell in use, like this:

#!/usr/bin/sh
#!/usr/bin/ksh
#!/usr/dt/bin/dtksh

Any script, written in any shell languare, or any binary (written in any language) can always be called from a shell.

Regards!

...JRF...

[James R. Ferguson]

Hi (again) Shiv:

Please see my last post here, too:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=992587

Regards!

...JRF...

[Shivkumar]

Few years ago; i started a process in different shell which was written in some other shell. I don't recall but it created some issue.

regards,
shiv

[Shivkumar]

Few years ago; i started a process in different shell which was written in some other shell. I don't recall exact error but it created some issue.

regards,
shiv

[James R. Ferguson]

Hi Shiv:

You commented, that "[A] few years ago; i started a process in different shell which was written in some other shell. I don't recall exact error but it created some issue."

I would suspect that there were variables defined in one script that you expected to be available in the environment of the other but were not.

For instance, if script-1 needs to make script-2 aware of a variable when it launches script-2, then script-1 needs to 'export' the variable first:

# cat script1
echo "hello"
export WHO=Shiv

# cat script2
echo "I am ${WHO}

Now script2 would report that it is "Shiv".

Another way of sharing variables is to pass them as arguments between scripts. Then, $1, $2...$n represent the arguments:

# ./script2 Shiv

...runs ./script2 passing "Shiv" as $1.

Yet another way to share variables between scripts is to include a file in a shell script. The process is called "sourcing" a file. You cause this by writing a "dot" followed by a "blank" followed by the file name:

#/usr/bin/sh
echo "the next line says include the file"
. $HOME/includeme
echo "done"

# cat $HOME/includeme
WHO=Shiv

This technique is often used to include environmental variables from a common file into a script instead of declaring them in a login profile.

Regards!

...JRF...

[Shivkumar]

Hi James;

Suppose a shell script written by someone is using #!/usr/bin/sh (which we can file by viewing the script) and my default shell is #!/usr/bin/ksh; do you suggest it is better to change my shell in #!/usr/bin/sh before executing that script ?

warm regards,
shiv

[James R. Ferguson]

Hi Shiv:

You wrote: "Suppose a shell script written by someone is using #!/usr/bin/sh (which we can file by viewing the script) and my default shell is #!/usr/bin/ksh; do you suggest it is better to change my shell in #!/usr/bin/sh before executing that script ?"

There is no reason to change your default login shell, which you have defined in 'etc/passwd', for you account, to be the Korn shell.

When you run a Posix shell script, its instructions are interpreted by the Posix shell because you *specified* '/usr/bin/sh' as the interpreter in the first line of your script. This is correct form and will yield an execution consistent with the declared interpreter.

Regards!

...JRF...

[Arunvijai_4]

Hi Shiv,

You got all the answers from ITRC gurus. We always use /usr/bin/ksh n our shell scripts since we had to follow some coding standards. It varies across organisations, some prefer to use /sbin/sh since it will be available even in single user mode.

Hope this is clear.

-Arun

[dirk dierickx]

you can use any shell you want for writing your scripts. the reason why a lot of scripts are using /bin/sh is that is is the basic script that should be available at all times (so it is the best choice for init scripts). sh is available on all unix systems, including linux where ksh is not installed by default. so it's possible to write an 'sh' script that works for all unix versions.

i use 'sh' for all my scripts as well. there is not much it can not do, and well, if a scripts is to large i just switch to perl.

[Muthukumar_5]

When you are using shell type then it has to be available in user mode. /usr file system will not there in single user mode. You have to use /sbin/sh only there.

When you are using in 3 or 5th run level then based on the requirement you can use ksh or sh or bash (if you are installed). It is better to go with ksh in hp-ux.

If you are not changing shell format in shell script then you will not get any error when executing ksh script in sh mode. Else it will prompt errors.

--
Muthu

[Arunvijai_4]

Hi Shiv,

http://www.askdavetaylor.com/whats_acceptable_syntax_in_unix_and_linux_sh_scripts.html

Hope this link will be useful.

-Arun

[Yogeeraj_1]

hi shiv,

if you were to start writing your own script, i would agree with the comment above that it is preferrable that you start learning perl!

it is much more powerful

kind regards
yogeeraj

[rmueller58]

if you write to Bourne shell, most shell interpreters will handle the command. I've had to write specific scripts because of handling certain types of functions in BASH or KSH..

I prefer not to use CSH because nothing fits except C. KSH on UX or BASH on Linux is probably the best route to follow.

"#which ksh" will define where the interpreter sits.

A K-shell script may or may not work under bourne.. variables may need to be reset, via a sub shell.

[Geoff Wild]

/bin/sh is symbolic link to /usr/bin/sh

That is the POSIX shell (on HPUX) and will work with KSH scripting standards.

I usually use #!/bin/sh less typing :)

Rgds...Geoff

[Mark Ellzey]

Shiv,

It doesn't matter what your login shell is when you execute a script that has the 'she-bang' line at the top of the script. The script that you execute will always be run under the the shell listed in the 'she-bang'.

For example, I administer a number of sites where startup/install/configuration scripts for our software package are written in csh (ugh!). I use the POSIX shell (/usr/bin/sh) as my login shell, and when I execute one of those scripts, the subshell they execute in is csh.

If you ever edited the root crontab with crontab -e, you've noticed that when you file (:wq) it, a message is displayed:
warning: commands will be executed using /usr/bin/sh
This means that cron will use /usr/bin/sh to run the commands. However, if you are executing a script that has #!/usr/bin/csh as the first line of the script, it will spawn a csh subshell to execute the script in.

Cheers,
Mark