Using perl to write shell scripts

[Alexandra]

I would prefer to write some shell scripts in perl because I'm more
familiar with it that
with writing bourne shell scripts.
The problem is that I have to do a lot of file copying, deleting, and
permission changing.
I wrote a perl script but it has 6 straight lines of back ticks to call
a shell command.
I was wondering if the performance of the script suffers any by making
all these calls
and whether it would be beneficial to use the Shell module. I really
don't understand
the usefulness of the Shell module. What's the difference between
using:
`cp /usr/local/thisfile /usr/local/thatfile`;
as opposed to using the Shell module:
cp("/usr/local/thisfile","/usr/local/thatfile");

Scott

[Marco Natoni]

Scott (?),

The first idiom surely forks a new process and opens a pipe with it,
while the second (maybe) not. Another, and better, solution is to use
the File::Copy module, that will make your script more stable and
portable.

However, you can test your idioms using the Benchmark module.

Best regards,
Marco

[Bart Lateur]

Alexandra wrote:

>The problem is that I have to do a lot of file copying, deleting, and
>permission changing.
>I wrote a perl script but it has 6 straight lines of back ticks to call
>a shell command.

Er... why? chmod() and unlink() are both perl built-ins, and

>`cp /usr/local/thisfile /usr/local/thatfile`;

with the module File::Copy, you can do that, too.

use File::Copy;
cp '/usr/local/thisfile', '/usr/local/thatfile';
or
copy '/usr/local/thisfile', '/usr/local/thatfile';

--
Bart.

[Michael Carman]

Alexandra wrote:
>
> I would prefer to write some shell scripts in perl because I'm more
> familiar with it that with writing bourne shell scripts. The problem
> is that I have to do a lot of file copying, deleting, and permission
> changing.

Perl does have unlink() and chmod() builtins. You can copy/move files
directly in Perl with the File::Copy module.

> I wrote a perl script but it has 6 straight lines of back ticks to call
> a shell command.

I like Perl too, but that doesn't mean you always have to use it.

If that's all your script does, you could go ahead and learn a little
about shell scripting. There's no point in just wrapping OS calls in
Perl. Or, you could implement everything in Perl using the functions I
mentioned above.

Sometimes the decision to write something in Perl vs. shell is
determined by where the script will be used. If it's only going to run
on your local *nix box shell is fine, or Perl with liberal use system
calls. If you want to use it on multiple platforms, then try to write it
in pure Perl.

> I was wondering if the performance of the script suffers any by making
> all these calls and whether it would be beneficial to use the Shell
> module.

Every time you make a system call, Perl has to fork a subprocess and
wait for it to return. There is some overhead with doing that, so
writing your script in shell might be marginally faster. But unless
you're forking a *lot* of processes, the difference shouldn't be
noticable.

Once again, you're delegating a lot more to the OS than you have to. Use
the builtins whenever you can.

> I really don't understand the usefulness of the Shell module.

It allows you to use shell commands as if they were Perl builtins.

> What's the difference between using:
> `cp /usr/local/thisfile /usr/local/thatfile`;
> as opposed to using the Shell module:
> cp("/usr/local/thisfile","/usr/local/thatfile");

AFAIK, nothing other than personal preference for which form you would
rather write.

-mjc

[Alexandra]

Bart Lateur wrote:

> Er... why? chmod() and unlink() are both perl built-ins, and
>
> >`cp /usr/local/thisfile /usr/local/thatfile`;
>

chmod() is a builtin. Fascinating. I did not know that. ulink deletes
files!!!
Wow! I just looked in my perl book and chown's a builtin too!!! Happy days!
Rmdir and mkdir are builtins!!! I wish, I'd have checked this out before
attempting
to write a non perl script. I don't know why I never stopped to check to
see if perl had equivalent commands!? I don't need to put shell commands in
my perl script.
I can write my shell scripts totally in perl!!! If I had known this
yesterday I could have saved my self hours of aggravation. I'm delighted to
realize that I can write all my scripts in perl :)))))))))

Thanks,
Scott

[Alexandra]

Marco Natoni wrote:

> The first idiom surely forks a new process and opens a pipe with it,
> while the second (maybe) not. Another, and better, solution is to use
> the File::Copy module, that will make your script more stable and
> portable.
>
> However, you can test your idioms using the Benchmark module.
>
> Best regards,
> Marco

That's a good idea. I also need to mess with the file permissions,delete
files, delete directories, and add directories. Is there a perl module
that'll handle these? (besides Shell.pm of course)

Thanks,
Scott

[Alexandra]

Michael Carman wrote:

> Alexandra wrote:
> Perl does have unlink() and chmod() builtins. You can copy/move files
> directly in Perl with the File::Copy module.

I just found this out from another poster. I can now write in perl w/o using
system calls.

> I like Perl too, but that doesn't mean you always have to use it.
>
> If that's all your script does, you could go ahead and learn a little
> about shell scripting. There's no point in just wrapping OS calls in
> Perl. Or, you could implement everything in Perl using the functions I
> mentioned above.

I'm choosing to do the latter after struggling to "convert" this simple line
in a shell script: @action=split(':',$line); Plus my scripts need to open,
close databases and CDB files. The only reason I resorted to shell scripting
was to use rm, rmdir, mkdir,
chown, chmod because I didn't realize perl had builtin's for these.

> Once again, you're delegating a lot more to the OS than you have to. Use
> the builtins whenever you can.

Now that I realized that chown, ulink, chmod, mkdir, rmdir ARE builtins and I
can use File::Copy I really have no need to use shell scripting.

Thanks for the info
Scott