View source for Traps and pitfalls specific to running external programs

* I run most of my external commands in '''Linux''', sometimes in '''BSD'''. These procedures may work in the Mac, since it is, in some way, a descendant of BSD, but they will not work in Windows.
* In different Unix-like systems the same command can be in different positions in the filesystem. For example in Linux Debian <code>date</code> is in <code>/usr/bin/date</code>. In the Mac it is in <code>/bin/date/</code>.
* If you run your external command '''synchronously''' your code will be easier to read but '''Cuis UI will''' '''hang''' until the command is done. This might be very unpleasant so if you want to go that way make sure your external command can complete its task quickly, independently of the input. 
* If you run commands through the <code>bash</code> or <code>sh</code> and pass pathnames to it, they should be quoted or even a white space can bring you unexpected results.
* In Smalltalk we write strings with <code>'...'</code> and in the ''Bash'' shell the same character is used for quoting without interpolation, you will soon discover escaping your command can be not trivial. This fact is worsened by the escape character in Smalltalk being again <code>$'</code>.
* Given the previous points I recommend you never to run <code>rm</code> or any destructive command. Mistakes and the unexpected do happen.
* If part of your shell command is taken from user input (e.g. a '''web page form''') keep in mind that '''bad guys exist''' and they try to inject executable code in the forms. Imagine this scenario, you asked the user to give you a mail address and you would like to give that string to the <code>mail</code> command. But the user instead wrote <code>$(cd ; rm -rf *)</code>, say farewell to your home directory.