Huh? Did you read the post I was replying to (update: hmm, you wrote it, so I guess you did)? You seemed to be complaining about the difficuly of executing a pipeline of code while still using a system(@list) type syntax (or maybe I am misinterpreting). I didn't see where it said myprog either needed an executable to run it or was itself an executable. The pipeline started off with myprog, I just want to make sure I execute myprog, and when you exec($command) with only the one argument, you can use the exec {$command} $command syntax (or exec {$args[0]} @args)...which is a somewhat more secure way to exec. I'm not saying the entire program is absolutely secure because of this. (Yes, I agree it's more secure if you supply the entire path to myprog). | [reply]
[d/l]
[select] |
I guess you picked up the conversation half way through and responded, but to clarify, my points are:
- 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.
- Shells are not, repeat NOT inherently dangerous.
There are two ways shell avoidance syndrome (SAS) is justified:
- 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.
- 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.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
| [reply]
[d/l]
[select] |
