I would actually go a different way here. Instead of using variables, use functions. And don't return the string, accept the arguments. This would allow you to do things such as swap out implementations later. So, instead of:

  system($cp, $from, $to);
[download]

call:

  cp($from, $to);
[download]

And then your function can start by just calling:

sub cp {
  system('/bin/cp', @_);
}
[download]

but later, it can become:

sub cp {
  require File::Copy;
  File::Copy::cp(@_);  #doesn't work for wildcards, I think.
  # File::Copy::cp(map {glob $_}, @_) # <-- might be needed for wildca
+rds
}
[download]

Similarly for other commands. So you can't convert everything at once to pure perl. No big deal. You can convert what you find you need to, when you need to.

Reasons for this approach:

• Speed. Oftentimes, doing stuff in perl is just as fast as doing it in C. For example, copying files is more limited by disk/network speed than CPU speed, so perl will be just as fast for the copying part. But doing it in pure perl means you don't have the overhead of a fork and exec. Or more than one fork and exec if you use the shell in between. I have one perl program that literally copies dozens of GB, over 100,000 files, and this switch did affect the time it takes to perform the copies.
• Portability. You don't need to worry about different OS's and their different calling mechanisms. e.g., cp on unix/linux vs copy on windows. File::Copy will do it right on all of them. The above program I work on works on Windows (ia32, x64, ia64), AIX, Sun (SPARC, x64), HP (PA-RISC, ia64 aka IPF), and Linux (ia32, x64, ia64, ppc64, s390x). We've added multiple platforms over the last few years with basically no tweaking. We only call out to the shell when we have no other choice in perl.
• Portability. Yes, again. Different distros of Linux often do things different. While cleartool probably isn't going to move (since it's not owned by any distro), cp might. So when you move from RH to SuSE to Debian to Gentoo - or vice versa - something may have changed. By reducing your dependency on the hardcoded locations of applications, you reduce your exposure to those changes.
• It's just cool. ;-) You own your own work. And, with that, comes the flexibility to do things the way you need to. Need to handle regexp's in your copy command instead of globs? No problem! Cleartool acting funny when passed in multiple files? Just a tweak to the sub, and that can be dealt with as well (by calling it repeatedly)! You centralise your interface, making it possible to fix an external problem in a single internal location, rather than dealing with it all over your code.

At least, that's my approach. :-)

---

---

Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!

Titles consisting of a single word are discouraged, and in most cases are disallowed outright.

Read Where should I post X? if you're not absolutely sure you're posting in the right place.

Please read these before you post! —

• How do I compose an effective node title?
• How do I post a question effectively?
• Markup in the Monastery

Posts may use any of the Perl Monks Approved HTML tags:

a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr

You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)

	For:		Use:
	&		&
	<		&lt;
	>		&gt;
	[		&#91;
	]		&#93;

Link using PerlMonks shortcuts! What shortcuts can I use for linking?

See Writeup Formatting Tips and other pages linked from there for more info.