Shell Programming and Scripting

@ Corona688

I see. Well then, this is me, back pedaling. I have no doubt what you are saying is accurate. And from that I gather that Perl is running on top of the shell rather than independent of it. That I didn't realize.

It follows that 'system' in Perl is an alias for 'shell' then, to put it in simple terms. That being the case demonstrates a LOT of overhead that I wasn't aware of. Thanks for enlightening me.

So when writing scripts to manage local stuff, use the shell. I'm good with that.

I'm wondering now if the same is true for Python?

Oh, it is independent of it.

system() is not. system() means "run this command in a shell". it kind has to use a shell, because that's what it means.

So, to run external commands, it generally has to use a shell.

Perl built-ins and perl modules, on the other hand, are native. (Unless they use system() for something.) Quite probably. Remember, that's what system() means -- "run this command in a native shell".

Also remember that not using a shell to handle it means you have to handle splitting, pipes, and path lookups yourself. That's all the shell's job traditionally. So it's either do all the hard work yourself, build at least half of a good shell into your language, or hand the job off to the shell.

As for python's overhead in general, one might wonder, how many files does it take to do absolutely nothing? The answer is interesting:

Code:

~ $ strace bash /dev/null 2>&1 | grep -c open
8
~ $ strace perl /dev/null 2>&1 | grep -c open
8
~ $ strace awk '{}' /dev/null 2>&1 | grep -c open
5
~ $ strace python /dev/null 2>&1 | grep -c open
53
~ $

Perl stands for Practical Extraction and Report Language. It would logically be the best choice for that purpose. It falls down when it comes to external commands.
Bash is right at home in that respect.

RE: the numbers
My everyday OS is Centos6. Because it sports Gnome2, library and software versions have to be kept back for compatability reasons, which might explain the differences here.

Yes, these numbers are interesting. I guess they represent processes?

Code:

strace python /dev/null 2>&1 | grep -c open
174
strace perl /dev/null 2>&1 | grep -c open
31
strace awk '{}' /dev/null 2>&1 | grep -c open
7
strace bash /dev/null 2>&1 | grep -c open
9

Could it be that Python and Perl are compiled? and bash is not? I dunno.

Edit:
A little off topic, but you mentioned doing the shell's work one's self. There's a module for Perl...
Zoidberg - a modular perl shell | SourceForge.net
Just an FYI I forgot to mention.

No. They are exactly what I said -- the number of files they open to do exactly nothing. No. They are all compiled.

While it may be a different (or more difficult) than bash, with respects, perl does not "fall down" when it comes to external commands. It just depends on what you are trying to accomplish.

Back in the day, Mandrake (now Mandriva) chose Perl as the language to write all their system configuration tools with. They even wrote console counterparts to their tools integrating ncurses with Perl. It became one of the easiest to use and most popular of all Linux distros. Mageia and PCLinuxOS still use Mandriva as a base for their own respective distros because those tools are so good. Those distros are prolly the best resources for anyone wanting to learn Perl and is looking for Perl source examples to study. The Linux game 'Frozen Bubbles' is written also with Perl. Lots of graphics and animation. Perl is not the dog to throw rocks at.

Compared to small bash scripts and one-liners you could say Perl 'falls down' because it gobbles resourses. It's argued that it's not the best choice in that arena, and I agree. Shell scripts do have their place. But when it comes to gathering and reporting data, which is what the script in the first post is all about, or interfacing with humans, like the examples given above, I argue that Perl does it better (and faster) than any shell script could, at least any that I've ever seen.

P.S.
With respect to the shell's versatility, notice that Chubler_XL took the time and went to the trouble of converting the OPs script (post #19). Good job Chubler_XL. Whether it will handle just about any kind of data you throw at it remains to be seen.

Cheers

It uses several award-winning C libraries to do so, which work equally well in C, Perl, Python, Ruby, or dozens of other languages. Shell, admittedly, is not one of them.

Strip perl of its modules, and it's way worse at I/O than shell. I don't think you know a lot about shell or perl, really. But we've gotten off topic.

My points:

1) It's possible to write bad code in any language.
2) Bad perl code is not better than good shell code.

Therefore:

Perl code is not automatically better than shell code, even for tasks you consider it "ideal" for.

(This is not one of them, for reasons I've spent the last several pages explaining repeatedly.)

I thought you gave up that argument pages ago.

If you have any specific concerns about his program, please name them and we will happily correct any errors. Otherwise please stop your baseless fearmongering. That you don't know the potholes to avoid doesn't mean we don't.

Blocking injection, and handling error conditions in general, has always been the programmer's responsibility. If you think you can't exploit a perl script, you need to learn a lot more about programming in general.