I guess you picked up the conversation half way through and responded, but to clarify, my points are:

1. Various shells provide a lot more facilities than just pipelining.

   If myprog is actually myprog.pl, it will run perl.exe.

   If it is myprog.exe it will run that directly, but it will also find it by looking in a whole host of well-known places in a particular pecking order, if myprog.exe doesn't exist in the current working directory.

   Then again, it might be myprog.cmd, or myprog.rb. or myprog.icl or myprog.oz.

   If it was myprog.html it would start one of several browsers depending upon the current users preferences.

   Or one of several media players if it was myprog.mp3 or myprog.wav or myprog.avi etc.

   Duplicating all the facilities of shells is a very big task, and once you have done so what would you have achieved?

   You'd have written another shell and you have to ban yourself from using it because shells are inherently dangerous aren't they.

2. Shells are not, repeat NOT inherently dangerous.

   There are two ways shell avoidance syndrome (SAS) is justified:

   1. Passing tainted input from untrusted sources.

      I don't do that. The only way tainted user input gets into my programs is if someone physically breaks into my office, bypasses my alarm system, start up my computer, cracks the logon to my systems and then types the tainted input at the keyboard. If that happens, I doubt they are going to ponse around trying to find a perl program they can run that will accept and pass on unchecked input to a call to system.

   2. The system shell could have been replaced by some unscrupulous person by a name-a-like that does bad things.

      Again, if your system is so compromised that the bad guys have managed to replace your system shell, you have greater problems than whether your perl scripts pass tainted input to system.

Even if a program is accepting input from untrusted sources, say via the web, then if you follow good practice for such programs--use -T; untaint by inclusion not exclusion; etc.--then there is still no good reason to reinvent all the wheels that shells provide in order to avoid using the shell.

The chances are that 99 attempts out of 100, that when your average Joe Programmer tries to recreate the facilities of a system shell, that they are going to make many of the mistakes and security foopars that have long since been found and fixed in your system shell.

The only good reason for avoiding calling the system shell, is efficiency. If you do not need the shell's facilities--any of the shell's facilities, including searching paths and other well-known environment variables to locate the appropriate executable--then there is no point in invoking the shell and have it invoke the program that you really want to run.

All other justifications for SAS were ill-conceived to begin with, hyped against reason, and are perpetuated without thought.