differences between Bourne shell, Korn shell, C shell, and bash

http://www.efytimes.com/e1/creativenews.asp?edid=123101 :

Always wondered what is the difference between these four shells? Here's the answer. …

shell code and useless use of "ls *.tar"

Consider this code (I came across such Korn shell script code recently):

TARFILE=$(ls -1 /tmp/*.tar)

According to http://partmaps.org/era/unix/award.html#ls you ought to replace the ls with a glob, e.g. like this:

[[ -s /tmp/*.tar ]] && set -A tarfiles /tmp/*.tar
for TARFILE in "${tarfiles[@]}"
do
  : # ...
done

Instead you may want to enquire ${#tarfiles[@]}, i.e. the number of files globbed.

Please forgive me the naming here! I was happy to take this note anyway.

migrated a Korn shell script using "Extended Pattern Matching" to bash

https://www.gnu.org/software/bash/manual/html_node/Pattern-Matching.html

I had to "shopt -s extglob" for that.

I inserted the shopt line rather close to the case statement, where the Extended Pattern Matching gets employed. That was inside a loop. That had no effect, but it didn't say so. I rather threw some weird error messages. I reduced the code around the causing line to its minimum, occasionally moved the shopt to outside the loop, and it worked. If it had only been that straigt …

the bash's "nullglob" is rather nice to use

http://www.gnu.org/software/bash/manual/html_node/Filename-Expansion.html

w/o this command line:

$ shopt -s nullglob

a glob pattern, that does not successfully evaluate to existing file names, gets literally resolved to a file name identical to the glob pattern.
With the above command line executed already, this command line will print file infos of /etc/passwd and ignore the unsuccessful other two glob patterns:

$ ll /etc/passwd /etc/passwd? /etc/passwd??

In interactive mode you may want to see the error messages, within a shell script supplying all three parameters to a "for f in …" loop, you will want the unresolving ones to get ignored.

$ for f in /etc/passwd /etc/passwd? /etc/passwd??; do echo $f; done

Well, at least in my script today I found this option rather useful.

I tried to find something comparable in the Korn Shell, but I wasn't successful.

ksh88 man page

www2.research.att.com/sw/download/man/man1/ksh88.html man page

• NAME
• SYNOPSIS
• DESCRIPTION
• * Definitions
• * Commands
• * Comments
• * Aliasing
• * Tilde Substitution
• * Command Substitution
• * Process Substitution
• * Parameter Substitution
• * Blank Interpretation
• * File Name Generation; bash: shopt extglob on # "extended globbing"
• * Quoting
• * Arithmetic Evaluation
• * Prompting
• * Conditional Expressions
• * Input/Output
• * Environment
• * Functions
• * Jobs
• * Signals
• * Execution
• * Command Re-entry
• * In-line Editing Options
• * Emacs Editing Mode
• * Vi Editing Mode
• * Input Edit Commands
• * Motion Edit Commands
• * Search Edit Commands
• * Text Modification Edit Commands
• * Other Edit Commands
• * Special Commands: …, set, …
• * Invocation
• * rksh88 Only
• EXIT STATUS
• FILES
• SEE ALSO
• CAVEATS

DESCRIPTION : Functions :

… Function identifiers can be listed with the -f or +f option of the typeset special command. …

O'Reilly Media book: Learning the Korn Shell, 2nd Edition

• Learning the Korn Shell, 2nd Edition - O'Reilly Media (They don't offer it as an e-book. What a pity.)
• kornshell.com
• http://kornshell.com/doc/
• KornShell 88 Manual Page [Link] (-> get a git clone as described here and improve the links etc.; are their true man page sources?)
• KornShell 93 Manual Page [Link] 

Q: The ksh on "your" AIX – is it ksh88 or ksh93?

A: Well … the ksh on "my" AIX knows the "whence" builtin without "-a", so I think it's a ksh88, because ksh93 would know "whence -a".

(This paragraph will go to another article on ksh. (TBD))

I am using ESC in the shell, and I wonder, why it doesn't respond properly -- I am Korn shell sick

Korn shell - Wikipedia, the free encyclopedia

I have worked on some AIX in an ancient ksh with vi for the last 4 weeks (Mondays through Fridays, Geneva, Switzerland).

No bash on that machine, no emacs either.
Well, I remembered "set -o gmacs" for ksh at least. Maybe the ksh on that machine had never gotten tortured with that form of emacs mode ever before.

No, I am not going to use pdksh instead of bash.

Although I tried my best, I don't think my cautious shell scripting style will have any effect on anybody I met there:

if test "$ivar" -eq 0

instead of

if test $ivar -eq 0