Quote:
Originally Posted by
ongoto
@ Corona688
The devils' advocate here.
You're right. Calling 'uname -r' is not a call to the shell.
In perl, it is. It runs an entire complete shell, for convenience, to run a single command.
Quote:
/bin/uname is a binary that has nothing to do with the shell. I should say 'system calls' instead.
That's is not what "system call" means.
It is a fork(), an exec(), and probably several dup()'s, pipe()'s, reads(), and write()s on the perl side -- then all the same on the bash side. And then, finally, uname gets to do the system call to get the system's name and prints it into that pipe.
Creating a process is actually a fair amount of work, which is why it's generally done as little as possible. Doubling the amount of work necessary for it is not efficient, which is why perl makes a poor shell replacement.
Quote:
Some say that, because Perl uses system calls, you might as well use Bash. That presumes that Linux binaries are Bash builtins.
That's not what "system call" means.
You have completely missed my point, besides.
Quote:
If you call uname or ping, or any other binary from Bash; is that different than calling one from Perl?
Yes.
Yes, it is.
That is my point.
When you call an external command in perl, it just calls bash to do the real work for it, so that it nicely separates parameters and parses the way BASH has taught you to expect. Imagine if BASH had to call Perl to do anything, and you get an idea just how roundabout an arrangement this is.
You can avoid this by doing fork() and exec() instead of system(), but then you don't get all the nice things a shell does for you, like waiting for the process to finish and properly reaping it.
Quote:
You dont have to fork a shell to run Linux binaries.
You don't have to fork a shell, but you
do have to fork. That's just how it works -- fork() to create a copy of yourself, then exec() to turn the copy into something else. In BASH, you fork once. In Perl you fork twice -- the first time, to create bash! The second time is bash fork()-ing then exec()-ing whatever.
Quote:
Most returns go to stdout or stderr. Why would you need a shell.
Exactly!
Whenever you do system() in perl, that uses a shell. For that matter, system() in
lots of languages uses a shell -- including C and awk. That's just what system() means -- run this command in a native shell. In UNIX, that's a Bourne shell of some sort. In Windows, system() launches a Windows CMD interpreter.
Whenever you do ` ` in perl, that uses a shell too. Pretty sure Perl's popen-equivalent does also.
It's very inefficient if you're dealing with a lot of little commands. Twice the amount of work to use a process in Perl than BASH.
Why does it do this? Because BASH actually does a whole lot of things for you, to the point you haven't realized the problems it solves actually exist yet. Being able to say system("uname") instead of system("/usr/bin/uname"); works because BASH looks that up for you. To properly duplicate this and all the other little niceties the shell has taught you are "normal" would mean adding a lot more than you might expect.