Dynamic Programming with Shell Script

The Unix shell has two purposes, these being to serve as an interactive Unix command line, and to interpret shell scripts. One programs a shell script to glue together Unix programs and automate tasks. The shell is good at combining simple Unix commands, but bad at directing long-running programs which instead need their own ExtensionLanguage. Shell script is bad for portability beyond Unix; many VMS and Windows users do not install Posix environments.

Though there are several shells, most shell scripts use a variant of the Bourne shell. Today, a Bourne shell with Posix features lives at /bin/sh above every Unix system or Unix clone except the ancient ones.


Kernigh and Shell Script

ObjectNecromancer consists of CMake build lists glued together with a PerlFive script called raise.pl. Kernigh chose perl over /bin/sh because perl provides access to system calls like opendir, fchdir, mkdir, and has a strict mode; /bin/sh provides neither. Now perl also has better arrays, conditionals, loops, and 'my' variables, but perl still provides shell-inspired features such as string interpolation and here documents.

But /bin/sh remains better than PerlFive for interfacing with external Unix commands such as pax and unzip. Thus a redesign (in progress as of December 2006) is placing a DoExtract.sh script between raise.pl and commands that do archive extraction. Kernigh had to program this script slowly and carefully. Fortunately, Unix clones provide useful commands like ls -A, wc -l, and xargs -J.

External link

Scripting: Higher-Level Programming for the 21st Century - why scripting is so great
Opening the Software Toolbox - why Unix commands are so useful

Common shells


You may edit this wiki page. The text is in the PublicDomain.


Page Information

  • 1 year ago [history]
  • View page source
  • You're not logged in
  • No tags yet learn more

Wiki Information

Recent PBwiki Blog Posts