cut -c18-31,49-51 in perl?

[Anno Siegel]

So it's better to to research little-known options to "cut" to process
multi-line input, so that Perl can fork off a "cut" process to do
things that can be done easily in Perl itself.

"Little known" is in the eye of the beholder. Opening a pipe to (or from)
a command is a standard Perl technique.

I'm taking exception with your apodictic "It forks a process for every
line...", which is simply not true. I said nothing about "better".

What had been done wrong (and not by me, by the way) was calling an
external Unix utility inside a loop. The increase was achieved by
translating the functionality into Perl to avoid calling the utility.
So?


So instead of fixing 1 line perfectly good Perl script, so that it uses
a Perl construct instead of calling out to an external Unix utility, I
should rewrite the whole thing in C? Just because I don't want an
external utility forked off inside a loop, that means "speed is an
issue" and so I shouldn't even be using Perl? That makes no sense.

What are you going on about?

If someone does something dumb, like calling an external program in
a tight loop, there are usually several ways to fix it. If the
external program can run the whole loop in one go, that would usually
be fastest (but benchmark, if it matters!). If speed is not important,
but style is, re-writing the loop in Perl would be preferred.

My point is that you can get the Perl script to run a lot faster by
avoiding calling external utilities like "cut" and instead using the
language features provided by Perl itself, especially inside a loop.

In other cases you can make a Perl script much faster by replacing
a Perl-only operation by a specialized external program. (Try beating
grep in Perl some day.) And the big assumption is "if speed is an issue".
Most of the time it isn't.

Anno

 

[Larry]

If someone does something dumb, like calling an external program in
a tight loop, there are usually several ways to fix it. If the
external program can run the whole loop in one go, that would usually
be fastest (but benchmark, if it matters!). If speed is not important,
but style is, re-writing the loop in Perl would be preferred.

But what about the other reasons to avoid external programs? You could
be relying on idiosyncracies of that particular installation's version
of the program. The program may not even exist on another system.

There are definitely certain external programs that should legitimately
be called from Perl, but not shell-script standards like "cut", "grep",
"echo", "awk", etc. Using them is just a sign of not knowing Perl very
well.

 

[Anno Siegel]

But what about the other reasons to avoid external programs? You could

What about them? They weren't subject of the discussion.

be relying on idiosyncracies of that particular installation's version
of the program. The program may not even exist on another system.

There are definitely certain external programs that should legitimately
be called from Perl, but not shell-script standards like "cut", "grep",
"echo", "awk", etc. Using them is just a sign of not knowing Perl very
well.

Including Abigail? Oh dear...

You act as if I were advocating the use of external programs. I am
not. I am advocating an open style of programming where each tool is
used in its place. If it happens to be convenient and applicable in a
case, use an external program, if it isn't, don't.

The belief that "cut", "grep", etc. must always be done in Perl in a Perl
program is superstition. Perl has system() for a reason.

Anno

 

[Tintin]

The belief that "cut", "grep", etc. must always be done in Perl in a Perl
program is superstition. Perl has system() for a reason.

So long as 90% of your Perl script isn't system calls to unix commands. If
that's the case, you'd be much better off writing a shell script.

 

[Tintin]

Tintin ([email protected]) wrote on MMMMDX September MCMXCIII in
<URL:,,
,, ,, > The belief that "cut", "grep", etc. must always be done in Perl in a Perl
,, > program is superstition. Perl has system() for a reason.
,,
,, So long as 90% of your Perl script isn't system calls to unix commands. If
,, that's the case, you'd be much better off writing a shell script.


Huh? Why? If the 10% is really awkward to do in shell, why not do it
in Perl?

If the 10% is awkward, then either write a shell script to do the 90% and a
Perl script for the remaining 10%.

Based on the many examples I've seen with excessive system calls, the
remaining 10% is generally easy to do in shell.

Right tool for the right job.