Unix commands

[Kim Gardiner CS2003]

Can you issue UNIX commands using Perl?

Thanks.

 

[tfe]

Kim Gardiner CS2003 ha escrito:

Can you issue UNIX commands using Perl?

Thanks.

Hello,

Sure and "there is more than one way to do it" ...
qx! command with args!;
system("Command","arg1","arg2",...);
`command with args`
open(PIPE, "command |");

 

[Jürgen Exner]

Can you issue UNIX commands using Perl?

Sure you can, provided your operating system supports them.

jue

 

[Craig]

Can you issue UNIX commands using Perl?

The previous respondents gave you good advice. You can get more
detailed information on the system and exec commands in perlfunc. If
you use system, remember to check the return code from the OS.

system($cmd)==0 or die("Cannot $cmd ", $?);

 

[xhoster]

Can you issue UNIX commands using Perl?

That depends. Are you running Perl on UNIX? If not, can you ssh or rsh
into UNIX from whereever you are running Perl?

if (so) {
system "echo yes";
else {
system "echo no";
};

Xho

 

[usenet]

Can you issue UNIX commands using Perl?

You can, but it's often a bad idea.

Some folks treat Perl like a glorified korn shell, and do ghastly
things like this:
my @data = `cat somefile.txt`;

or
my @files = `ls /some/directory`;

Perl has built-in functions for a lot of stuff you might be tempted to
use shell commands for. It's generally preferable to use Perl when you
write Perl programs.

 

[John Bokma]

You can, but it's often a bad idea.

Huh!? Why?

Some folks treat Perl like a glorified korn shell, and do ghastly
things like this:
my @data = `cat somefile.txt`;

or
my @files = `ls /some/directory`;

Perl has built-in functions for a lot of stuff you might be tempted to
use shell commands for. It's generally preferable to use Perl when you
write Perl programs.

Depends on what you're doing of course. Why would I copy a program that
does already its work perfectly and reinvent the wheel? Increase
development time, and make many mistakes while doing so?

 

[Tad McClellan]

Kim Gardiner CS2003 ha escrito:

Sure and "there is more than one way to do it" ...
qx! command with args!;
system("Command","arg1","arg2",...);
`command with args`
open(PIPE, "command |");

The 1st one and the 3rd one are the same one.

 

[Jürgen Exner]

Even if it doesn't, you can still issue them.

Well, guess that's true ;-)

jue

 

[Andrew DeFaria]

Depends on what you're doing of course. Why would I copy a program
that does already its work perfectly and reinvent the wheel? Increase
development time, and make many mistakes while doing so?

Because 1) it's inefficient in that you are forking and exec'ing a
process to do it and 2) portability - there's no guarantee that the next
platform you port this to has the same commands. For example, you use
"ls" above. But there is no "ls" under Windows. If instead you use a
more Perl like way your Perl script will immediately port without and issue.

 

[John Bokma]

Because 1) it's inefficient in that you are forking and exec'ing a
process to do it

Depends a lot on what the task is doing of course. Or do you base this
all on the example David (don't remove attribution lines if you quote)
gave?

and 2) portability

As always, instead of using a dumb set of fixed rules (never use shell
commands because: fork overhead and non portable) one has to consider
everything. For most of the stuff I write fork overhead is a non-issue
as is portability.

- there's no guarantee that the
next platform you port this to has the same commands.

There is no guarantee that what I write is going to be ported at all.

For example, you
use "ls" above.

I didn't. Moreover, it's just an example.

But there is no "ls" under Windows.

Yup, like there is no perl under Windows.

C:\Documents and Settings\John\My Documents\Amber\Sites\johnbokma.com
\site\web>ls -al *.png
-rw-rw-rw- 1 user group 13112 Nov 13 2005 bokma-gnu.png
-rw-rw-rw- 1 user group 108 Nov 13 2005 dash.png


See: http://johnbokma.com/mexit/2006/07/01/

If instead you use
a more Perl like way your Perl script will immediately port without
and issue.

Not all Perl scripts are used on different platforms. Most I write
aren't. But like I said, it's a non-issue if the external program is
ported to the target platform(s) as well.

For example I now and then use wget via Perl. The fork issue is a non
issue IMSHO. And if my customer wants to run it on Windows he gets
instructions on how to install wget (see previous link).

I rather do that then waste his/her valuable time and money on making a
wget clone if wget does /exactly/ what is required.

 

[Andrew DeFaria]

If I'm willing to pay the price of running anything in Perl, do you
really thing I can be bothered about the overhead of forking? If the
time constraints where that critical, the error would have been
writing the program in Perl, not the forking. Then it should have been
written in C instead.

As is comment it depends. When you automate your build system with say
Perl and things are fine but as new requirements come in and more and
more is being built the automatic build system is getting slow, and you
look at it and see that you're spending a lot of time forking and
execing small programs where there are better, more efficient ways to do
that then removing these calls to system is indeed worth while.

When you realize that those 10,000 calls to system 'ls' are really
slowing you down, porting this to C and still forking and execing ls
10,000 times will not be any faster!

__ process to do it and 2) portability - there's no guarantee that the
next
__ platform you port this to has the same commands. For example, you use

I've been programming Perl for over 12 years. I've yet to write a
program that had to be ported to Windows.

You have yet to write a program that could be ported to Windows would be
my suspicion...

So let me get this straight - you've never been asked to have a useful
Perl program that you've written on a Unix system ported over to work on
Windows? Maybe they just don't like you or perhaps your programs are as
useful as you think. I've been asked all the time and I've done it all
the time.

I did once had to port a long shell/awk/SQL script (over 1000 lines)
from Solaris to Windows. After installing a Unix toolkit the script
only required a single change: the location of the temp directory.
I've found more porting issues between different versions of Perl (not
to mention different versions of CPAN modules) than between different
UNIX toolkits (just keep yourself away from all the fancy GNU/Linux
features if you have the need to run it on a real UNIX). After all,
there's POSIX while there isn't a Perl standard.

Sounds to me like you are just inexperienced in the area. I do it all
the time and as such I'm speaking from experience you obviously and have
stated that you lack.

__ "ls" above. But there is no "ls" under Windows. If instead you use a
__ more Perl like way your Perl script will immediately port without
and issue.

Really? Last time I looked Windows didn't come with perl either.

So you've never seen a Perl script run on Windows have you? My god your
a noobie aren't you!

 

[John Bokma]

Taking the poor grammar out of the picture

As soon as people talk about grammer usage (or abuse) in a Usenet post
they have little to say about the issue at hand, which doesn't amaze me
in your case.

Similarly I think it's better to write script in anticipation that
they may be asked to run on systems I've never thought that they
would.

If its not in the requirements and not likely, why bother? I try to find
the best possible solution for my customers instead of making up a set
of silly rigid rules.

[ Cygwin ]

server, grep, awk, diff and quite literally thousands of others, I
cannot guarantee that the client will go for it. Indeed many do not.

So they have no problem with you installing Perl, but they do have a
problem when you install (from your example) ls.

I guess you write all your modules yourself as well then? I mean, they
might have a problem or two with installing some CPAN modules as well.

Yes and many of them can't because they use things like those
described above.

And for most that's a non-issue. Rigid development rules are for
programmers with little skills. Skilled programmers are able to see the
pros and cons of several possible solutions and select one.

My Perl scripts can and are used on various platforms.

So can and are mine, most out of the box. On the other hand I have no
problem at all with using external tools. It all depends on the
requirements of my customers.

And if the client will allow you to install such tools (and upkeep,
patch, update, etc.). This is not always the case in the real world.

Then their problem already starts with using Perl on Windows (for
example). And you using CPAN in general.

Additionally it adds to the requirements and prerequisites for the
usage of your tool - not a good thing.

But you reinvent the tool. Now if there is anything silly in software
development it's refusing to use a library / external tool because of a
"you never should" rule.

Programming is about flexibility.

Finally often the external tool
does a lot more stuff than what you need. They call this wasteful.

Most external tools have switches that enable / disable features. Code
that doesn't get executed doesn't matter. And if there is a slight
overhead because the tool does something extra, this overhead might be
insignificant compared to rolling out your own code in Perl.

It all depends on circumstances, not on some silly rule you prefer to
live by.

Again this is good to know. I always like knowing who I would *not*
recommend for a job. Welcome to the list.

I am glad to be on it, especially based on your other drivel I am
sharing the honor with Abigail and probably a lot of other programmers
in this group.

Exactly is a debatable term here.

A debat which you avoid by making up a brain dead rule.

Think about how hard perl -MCPAN

What!? Installing external libraries on Perl? That *is* allowed and a
single executable not?

 

[Andrew DeFaria]

Bleh. If you do 10,000 calls to 'ls' and it's slow, then it's the disk
access that's the bottleneck, not the forks.

My point is, if 10,000 accesses are required, strapping them with
additional inefficiencies of 10,000 fork/execs is silly. Now you are
free to be silly if you want....

And even ten, saying "if you do it 10,000 times, it's slow, so you
should never use it" is sillyness.

Probably is - however I didn't say that. So if you wish to argue your
own made up things I guess I can't stop you. But the only thing silly
here is your strawman.

If your program does 10,000 regex matches and it's slow because of
that, do you draw the conclusion you should
never use a regex because doing 10,000 of them might form a bottleneck
in some program?

No my argument is that you shouldn't do 10,000 fork/execs to grep to do
these regex matches - you should do them internally as that's more
efficient. Are you really that dense that you cannot see that?

No. I don't do Windows and I've never done Windows. And I don't apply
for jobs that involve doing anything on Windows.

And as I can see you are extremely open minded! Bravo!

Good for you. I typically work in environments where if the
environment would need to be ported, it would take a lot of people
several years to do it

Could that be because they all have their heads as far up their asses as
you do? Just an opinion.

(and the only time I worked for a company where the company decided to
port their product to Windows they abandoned their effort after 18
months, as they found out their customers weren't interested). If it
were to be done, any program would have to be modified anyway.

Listen sonny, I've probably worked at far more companies than you, many
who use various platforms. I was talking about writing tools that are
used in house and not necessarily products sold to end users, though
there is wisdom in writing portable code nevertheless. I really have a
hard time understanding your viewpoint. You are actually arguing that
writing non-portable code that is inefficient is a good thing! I'm sure
you'll go far with that attitude.

Yes, and? Just because you have to port your programs to Windows,

Actually many times I've ported my programs and tools to Unix too!

doesn't mean I have to restrict myself and not to use the excellent
tools any Unix system gives me.

You just go ahead and stick your little head back into that ground and
ignore the fact that Unix isn't the only operating system in town. Now
don't get me wrong, I use Unix all the time and prefer it. However at
least I don't live in a cave.

I've seen Perl scripts on Windows. And I've seen 'ls' on Windows as
well. And 'cat'. And 'echo'. And every other common Unix tool. Unix
tools have been ported to Windows. More than once even.

Granted! Hey I'm a firm advocate on usage of Cygwin. In fact I'd jump
for joy if MS required it on every installation of Windows!

However in the real world you don't always have that. You see aside from
you sitting in your dark Unix dungeons and dragons cave I've been out in
the real world and while ls, cat, echo, etc. can be installed on a
Windows box often it isn't. To code assuming it's there, all the while
incurring additional fork/exec overhead when there are many much more
efficient and much more Perl like ways of doing it (in your Perl script,
we were talking about Perl, remember?) seems to me to be stupid, short
sighted, lazy, etc.

I'm just saying that if you want to use the argument that certain
tools aren't standard on Windows, you should consider that perl isn't
standard either.

If I'm asked to write a Perl script by the client then assuming there'll
be a Perl interpreter is not a silly assumption.

 

[Charlton Wilbur]

ADF> Listen sonny, I've probably worked at far more companies than
ADF> you, many who use various platforms. I was talking about
ADF> writing tools that are used in house and not necessarily
ADF> products sold to end users, though there is wisdom in writing
ADF> portable code nevertheless. I really have a hard time
ADF> understanding your viewpoint. You are actually arguing that
ADF> writing non-portable code that is inefficient is a good
ADF> thing! I'm sure you'll go far with that attitude.

You *really* ought to do enough research to find out who you're
lecturing. I don't think you intend this tirade to come across as
comedy.

Charlton

 

[John Bokma]

Abigail wrote:
[..]

And even ten, saying "if you do it 10,000 times, it's slow, so you
should never use it" is sillyness.

Probably is - however I didn't say that. So if you wish to argue your
own made up things I guess I can't stop you. But the only thing silly
here is your strawman.

= John Bokma wrote: = Andrew DeFaria
Depends on what you're doing of course. Why would I copy a program
that does already its work perfectly and reinvent the wheel? Increase
development time, and make many mistakes while doing so?

Because 1) it's inefficient in that you are forking and exec'ing a
process to do it and 2) portability - there's no guarantee that the >
next platform you port this to has the same commands. For example, you
use "ls" above. But there is no "ls" under Windows. If instead you use
a more Perl like way your Perl script will immediately port without
and issue.

Maybe my grammar is bad, but you either missed "Depends on what you're
doing of course", in which case your 1) and 2) are just more or less
repeating what I stated and is a bit of pointless or you just falled of
your horse...

No my argument is that you shouldn't do 10,000 fork/execs to grep to
do these regex matches - you should do them internally as that's more
efficient.

Again, depends on what you're doing and trying to achieve.

And as I can see you are extremely open minded! Bravo!

Nothing wrong with specialism. Abigail probably has also never
programmed in C#, and will never do so, nor will apply for jobs. That's
a choice and has nothing to do with being open minded or not.

Listen sonny, I've probably worked at far more companies than you,

Hurray, the "my dick is bigger then yours so I have pleased more
females" argument.

the real world and while ls, cat, echo, etc. can be installed on a
Windows box often it isn't.

OMG!!!11111eleven you mean like, eh, perl.exe for example?

we were talking about Perl, remember?) seems to me to be stupid, short
sighted, lazy, etc.

"A truly great computer programmer is lazy, impatient and full of

If I'm asked to write a Perl script by the client then assuming
there'll be a Perl interpreter is not a silly assumption.

Two very important questions are: which version of Perl, and what
modules are installed. Even your script and modules have to be
installed.

How is that different from installing an additional tool?

 

[Andrew DeFaria]

You *really* ought to do enough research to find out who you're
lecturing. I don't think you intend this tirade to come across as comedy.

What an argument to authority?!? Apparently you are also in the "let's
write non-portable and inefficient code" camp.

 

[Dan Mercer]

John Bokma wrote:

Some folks treat Perl like a glorified korn shell, and do
ghastly things like this:


my @data = `cat somefile.txt`;

or
my @files = `ls /some/directory`;

Perl has built-in functions for a lot of stuff you
might be tempted to use shell commands for. It's
generally preferable to use Perl when you write Perl programs.


Depends on what you're doing of course. Why would I copy
a program that does already its work perfectly and reinvent
the wheel? Increase development time, and make many mistakes
while doing so?

Well, for one thing, "my @files = `ls /some/directory`" can give you
bad data that could lead your program into executing a path you never
anticipated (think, filename with embedded newline). Also, when
your code is peer reviewed, your peers will think you are a fargin' idiot.

Dan Mercer


Because 1) it's inefficient in that you are forking and exec'ing a process to do it and 2) portability - there's no guarantee that
the next platform you port this to has the same commands. For example, you use "ls" above. But there is no "ls" under Windows. If
instead you use a more Perl like way your Perl script will immediately port without and issue.

 

[Dan Mercer]

:
: > Taking the poor grammar out of the picture
:
: As soon as people talk about grammer usage (or abuse) in a Usenet post
: they have little to say about the issue at hand, which doesn't amaze me
: in your case.
:
: > Similarly I think it's better to write script in anticipation that
: > they may be asked to run on systems I've never thought that they
: > would.
:
: If its not in the requirements and not likely, why bother? I try to find
: the best possible solution for my customers instead of making up a set
: of silly rigid rules.
:
: [ Cygwin ]
: > server, grep, awk, diff and quite literally thousands of others, I
: > cannot guarantee that the client will go for it. Indeed many do not.
:
: So they have no problem with you installing Perl, but they do have a
: problem when you install (from your example) ls.

Where I work, Perl is on the allowed list of utiliies and they foolishly
forgot to limit it by platform. So, while I don't have Cygwin or UWIN or
MKS, I do have grep and ls and many other Unix utilities - rolled in
Perl.

Dan Mercer
:
: I guess you write all your modules yourself as well then? I mean, they
: might have a problem or two with installing some CPAN modules as well.
:
: >> Not all Perl scripts are used on different platforms.
: > Yes and many of them can't because they use things like those
: > described above.
:
: And for most that's a non-issue. Rigid development rules are for
: programmers with little skills. Skilled programmers are able to see the
: pros and cons of several possible solutions and select one.
:
: > My Perl scripts can and are used on various platforms.
:
: So can and are mine, most out of the box. On the other hand I have no
: problem at all with using external tools. It all depends on the
: requirements of my customers.
:
: >> Most I write aren't. But like I said, it's a non-issue if the
: >> external program is ported to the target platform(s) as well.
: > And if the client will allow you to install such tools (and upkeep,
: > patch, update, etc.). This is not always the case in the real world.
:
: Then their problem already starts with using Perl on Windows (for
: example). And you using CPAN in general.
:
:
: > Additionally it adds to the requirements and prerequisites for the
: > usage of your tool - not a good thing.
:
: But you reinvent the tool. Now if there is anything silly in software
: development it's refusing to use a library / external tool because of a
: "you never should" rule.
:
: Programming is about flexibility.
:
: > Finally often the external tool
: > does a lot more stuff than what you need. They call this wasteful.
:
: Most external tools have switches that enable / disable features. Code
: that doesn't get executed doesn't matter. And if there is a slight
: overhead because the tool does something extra, this overhead might be
: insignificant compared to rolling out your own code in Perl.
:
: It all depends on circumstances, not on some silly rule you prefer to
: live by.
:
: > Again this is good to know. I always like knowing who I would *not*
: > recommend for a job. Welcome to the list.
:
: I am glad to be on it, especially based on your other drivel I am
: sharing the honor with Abigail and probably a lot of other programmers
: in this group.
:
: >> I rather do that then waste his/her valuable time and money on making
: >> a wget clone if wget does /exactly/ what is required.
: > Exactly is a debatable term here.
:
: A debat which you avoid by making up a brain dead rule.
:
: > Think about how hard perl -MCPAN
:
: What!? Installing external libraries on Perl? That *is* allowed and a
: single executable not?
:
: --
: John Experienced Perl programmer: http://castleamber.com/
:
: Perl help, tutorials, and examples: http://johnbokma.com/perl/

 

[John Bokma]

Which rigid rule are you referring to since I made no such claim. I
gave reasons why I thought it was better to do X than Y not that one
had to do X instead of Y. Can you understand that logical difference?

Maybe reread "<[email protected]>" were I
clearly wrote: "Depends on what you're doing of course."

Now who has a problem with interpretoring [1] things?


[1] <[email protected]>