7

On occasion I see people calling the system grep from Perl (and other scripting languages for that matter) instead of using the built-in language facilities/libraries to parse files. I would like to encourage people to use the built-in facilities and I want to solicit some reasons as to why it is good practice to use the built-in tools. I can think of some such as

  • Using libraries/language facilities is faster. Performance suffers due to the overhead of executing external commands.
  • Sticking to language facilities is more portable.

any other reasons?

On the other side of the coin, are there ever reasons to favour using system commands instead of the built-in language facilities? On that note, if a Perl script is basically only calling external commands (e.g. custom utilities without libraries), might it be better just to make a shell script of it?

Friedrich 'Fred' Clausen
  • 3,321
  • 8
  • 39
  • 70
  • 1
    because some people do not know libraries/language but know how to do smt with external tools. – KoVadim Dec 10 '13 at 13:32
  • 3
    Calling system is more error prone. On the other hand some system command like `sort` are more memory/cpu efficient than perl, even more so when large amount of data are involved. – mpapec Dec 10 '13 at 13:32
  • 1
    System commands are more unsafe. Even a command which seems harmless can be made to execute arbitrary code. Consider `system("echo", $foo)` if someone adds the file `./echo` with `#!/bin/bash \n rm -rf /` – TLP Dec 10 '13 at 14:00

3 Answers3

8

Actually, when it matters, a specialized tool can be faster.

The real gains of keeping the work in Perl are:

  • Portability (even between machines with the same OS).
  • Ease of error detection.
  • Flexibility in handling of errors.
  • Greater customizability/flexibility.
  • Fewer "moving parts". (Are you sure you correctly escaped everything and setup the environment correctly?)
  • Less expertise needed. (You don't need to know both Perl and the external tools (and their ports) to code and maintain the program.)

On that note, if a Perl script is basically only calling external commands (e.g. custom utilities without libraries), might it be better just to make a shell script of it?

Possibly. You can configure some shells to exit if any program returns an unsuccessful error code. This can make some scripts quite robust. For example, I have a couple of bash scripts featuring the line

trap 'e=$? ; echo "Error." ; exit $e' ERR
ikegami
  • 367,544
  • 15
  • 269
  • 518
  • 1
    There's also the issue that you're depending upon a resource you don't control. For example, what if you depend upon the system `find` command, and some joker writes a shell script `find` command that does a `rm -rf` and puts it earlier in the `$PATH`? – David W. Dec 10 '13 at 22:15
  • Most of the time, people use `system` commands in Perl because they don't know Perl that well and don't realize there's a Perl way of doing it. I see this with `date`, `find`, `copy`, and `mail` all of the time. These are all commands that can easily be handled in Perl using standard modules that come with Perl. However, if you learned Perl by reading a beginner's Perl book and never advanced beyond that, it's likely you're not familiar with Perl modules. – David W. Dec 10 '13 at 22:21
  • @David W., `cp` does have some advantages over File::Copy, but true. – ikegami Dec 11 '13 at 01:42
  • There could be advantages of using system commands. For example, I've had issues with `SVN::Client` and `system svn...` just works better. However, 99% of the time, when someone uses `system cp $foo, $bar` instead of `File::Copy`, it's because they look under the functions section of a 1989 Perl 3.0 programming manual (I think they leak through a hole in the space time matrix), see the `move` command, but no `copy` command. In fact, most system commands I've seen are for the `File::xxxx` modules. – David W. Dec 11 '13 at 02:40
3

"On the other side of the coin, are there ever reasons to favour using system commands instead of the built-in language facilities? On that note, if a Perl script is basically only calling external commands (e.g. custom utilities without libraries), might it be better just to make a shell script of it?"

Risking the wrath of Perl hardliners here. But for me there is an easy reason to use system grep instead of perl grep: I know its syntax.

Same reason to use a Perl script instead of a bash script: I know how to do stuff in Perl and never bothered with bash script syntax.

And as we are talking scripts here, my main concern is getting it done fast and reliable (and readable). At work i do not have to bother with portability as all production is done on the very same system, down to the same software versions of everything for the whole product lifespan.

At home i do not have to care about lifetime or whatever either as the script most likely is single-purpose.

And in neither case i care about performance or software security as i would be using C++ or something else for commercial software or in time or memory limited scenarios.

edit: Not saying these reasons would apply to anyone, or even anyone else. But while in reality i know how to use Perls grep, i really have no idea how to write a bash script and most likely never will. Just putting a few lines in Perl is always faster for me.

DeVadder
  • 1,404
  • 10
  • 18
  • 1
    There's an answer to the _I know **A**, but not **B** to well._ conundrum: Learn **B**. It's my job to learn this stuff and to know it. The main reason I go perusing StackOverflow is to learn new things. It's where I learned about Perl smart matching (yeah!), and where I also learned that Perl smart matching is now deprecated (darn!). It's where I find new books and new techniques I should know. I can understand, if you have to do something quick and dirty to do it quick and dirty, but afterwards, you should learn the correct way too. – David W. Dec 11 '13 at 02:35
  • 1
    It is not my job to be a bash script pro. It is my job to make the modules i am assigned to make. In C++. And sometimes it is my job to create scripts for testing routines or to record, sort and move data automatically. My boss could hardly care less whether i do that in Perl or Bash script as long as i do it in time, reliable and readable. I do understand that other people have other jobs and other bosses, my point is only that it that there may be reasons to not know every tool and thus sometimes to not use the best tool but just a good one for the job. – DeVadder Dec 11 '13 at 07:08
0

Using external tools lead to do more error. Moreover you have you to parse the results (if any) of the external command, which is an other source of error. No need to say that it is bad in terms of security.

user3087025
  • 1
  • 1