Wednesday, September 19, 2012

BASH issues that break the rules

I always thought BASH was too complex for it's own good. Unlike the commercial KornShell, BASH has things that break the rules of a good shell, such as forking a process for a built-in command, or caching commands instead of tracking them as aliases.

As I find some other annoyances with the Bourne Again Shell I'll list them in here and the reasons.


  1. Caching commands.
    Instead of tracking aliases to the real command BASH decides to use a different command (built-in) to deal with tracking commands that you have already run.  In the KornShell you would normally run alias -t to see what commands have been tracked when you install a new command and the old version is still running.  However, with BASH you have to use the hash built-in command to identify what commands are being tracked.  The -l or -t option will display a list of the commands tracked, whilst the -r allows you to remove the tracked command(s).
  2. Piping a while loop in BASH forces the built-in into a sub-shell, which means that any variables that you create inside the while loop body will be lost after the execution of the loop ends.  In KSH the while loop remains part of the shell process that is running, so you have access to the variables created in the loop once the loop execution ends.  Try the following code in both shells, and notice the major issue that the BASH generates which breaks all the rules on shell built-ins.

    cat /etc/passwd | while read line
    do
        if echo $line | grep steve >/dev/null 2>&1
        then
            newvar=$line
        fi
    done
    echo "This will only show in KSH: $newvar" 
 

No comments:

Post a Comment