Unix commands

[Tintin]

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

That surely beats:

opendir my $dh => '/some/directory' or die "opendir: $!";
my @files = grep {!/^\./} readdir $dh;
closedir $dh;

which takes three times as many lines.

In that instance, the cat is shorter, but why use the above, when you can do

my @files = </some/directory/*>;

 

[Tad McClellan]

This is a multi-part message in MIME format.

Please do not post multi-part messages in MIME format.

Abigail wrote:
So you've never seen a Perl script run on Windows have you?

How does having seen a Perl script run on Windows prove that perl
comes with Windows?

All that proves is the perl _can_ be installed on Windows, and Abigail
did not say that it cannot be installed on Windows.

My god your
a noobie aren't you!

Abigail is a world famous member of the Perl community.

Who are you?

 

[John Bokma]

That's an email address. Tell me, how do I read an email address?

Usenet newbie? It's a message id. View all headers in Thunderbird and all
becomes clear (I hope).

You can look up Usenet posts that way, for example by copying the ID (part
between < and >) after: http://groups.google.com/groups?selm= in your
address bar if the message has been archived in Google Groups.

 

[Charlton Wilbur]

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

No, I just think that lecturing Abigail on accomplishments,
employability, and competence makes you look like a jackass. If
that's your goal, by all means carry on.

Charlton

 

[John Bokma]

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

..

First of all, calling an external program doesn't mean it's non-portable.

Second of all, calling an external program doesn't mean it's inefficient
(inefficient in what? excution time, memory usage, development time?)

Programming is about using the right tool(s). Using an external program
can be the right tool or the wrong tool.

To me, and probably others as well, you make it sound like it's not a
right tool. And between the lines I read "never a right tool". Maybe my
bad, but your heated replies convince me more and more that I am correct
on this.

And no, you can't prove your point (whatever it is) by showing examples of
bad external tool usage and generalize this into: fork overhead and non-
portability. Depending on circumstances those arguments might be
irrelevant.

 

[Andrew DeFaria]

Please do not post multi-part messages in MIME format.

Please don't tell me how to post.

How does having seen a Perl script run on Windows prove that perl
comes with Windows?

I didn't say Perl comes with Windows.

All that proves is the perl _can_ be installed on Windows, and Abigail
did not say that it cannot be installed on Windows.

It was merely a question - not a proof.

Abigail is a world famous member of the Perl community. So what!
Who are you?

You can answer that question yourself.

 

[Jürgen Exner]

<blockquote type="cite">This is a multi-part message in MIME format.<br>
</blockquote>
Please do not post multi-part messages in MIME format.<br>
</blockquote>
Please don't tell me how to post.<br>
<blockquote cite="(e-mail address removed)"

Your choice
*PLONK*

jue

 

[Andrew DeFaria]

Usenet newbie? Hardly.
It's a message id. View all headers in Thunderbird and all becomes
clear (I hope).

What's not clear is how to use it to find the old message. When clicked
upon it brings up a compose window. As such it's useless. TB does not
support linking back through message IDs by default.

You can look up Usenet posts that way, for example by copying the ID
(part between < and >) after: http://groups.google.com/groups?selm= in
your address bar if the message has been archived in Google Groups.

Hmmm...
http://groups.google.com/[email protected]
yields:

The requested message, (e-mail address removed),
could not be found..

Finding it by hand I take it you mean when I said:

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.

This was in response to your statement "Why would I copy a program that
does already its work perfectly and reinvent the wheel?". Sorry but I
still just don't see it. Your claim is that I stated one must follow
some rigid rule. There is no rigid rule in my statement above. It merely
explains why somebody might want to do it. You claim that I advocate
some sort of rigid rule is ludicrous and merely a figment of your
imagination!

 

[Andrew DeFaria]

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

No, I just think that lecturing Abigail on accomplishments,
employability, and competence makes you look like a jackass. If that's
your goal, by all means carry on.

I am sooooo sorry. I'll get right on making all my code non-portable and
inefficient! Give me a break!

 

[Andrew DeFaria]

First of all, calling an external program doesn't mean it's non-portable.

Calling `ls /path/file` certainly is in that ls is not guaranteed to be
there nor is it guaranteed that "/" a valid directory separator. These
are portability concerns not impossible hurdles!

Second of all, calling an external program doesn't mean it's
inefficient (inefficient in what? excution time, memory usage,
development time?) The first two.
Programming is about using the right tool(s). Using an external
program can be the right tool or the wrong tool.

Yes I agree 100%. It can be the right tool and it also can be the wrong
tool.

To me, and probably others as well, you make it sound like it's not a
right tool.

It demonstrably isn't in that using opendir, etc. is better in terms of
both memory usage and execution time and really isn't a gigantic stretch
in terms of development time. Perhaps right and wrong are too strong of
terms. How about good and better?

And between the lines I read "never a right tool". Your imagination!
Maybe my bad, but your heated replies convince me more and more that I
am correct on this.

And no, you can't prove your point (whatever it is) by showing
examples of bad external tool usage and generalize this into: fork
overhead and non-portability. Depending on circumstances those
arguments might be irrelevant.

Fork overhead and non-portability are legitimate concerns. Sure people
can just hack off a system call to ls or something else. Again, I've
never said there's any sort of rigid rules here. However, are you saying
that fork overhead and portability issues irrelevant? All I was saying,
when asked "Why would somebody not use something like 'ls'?", fork
overhead and portability are two very legitimate reasons why somebody
would not want to use "ls" in this circumstance. And there are other
circumstances where the same applies.

 

[John Bokma]

Hardly.

Odd, have problems quoting and posting in general and mistake a message
ID for an email address.

Hmmm...
http://groups.google.com/groups? selm=X5CdnYE4KLbIpDXYnZ2dnUVZ_rHinZ2d@c
omcast.com yields:

The requested message,
(e-mail address removed), could not be found..

Finding it by hand I take it you mean when I said:

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

No, the part before it:

Depends on what you're doing of course.

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.

This was in response to your statement "Why would I copy a program
that does already its work perfectly and reinvent the wheel?".

Yes, it sounded silly. It still does. Like I said: it depends on what
you're doing. The fork overhead and the portability, if you know what
you're doing, might be considered a small price to pay for not inventing
the wheel again.

Sorry
but I still just don't see it. Your claim is that I stated one must
follow some rigid rule.

That's how I read your posts. If people state that there are plenty of
situations one can call an external program because fork overhead and
portability (or lack off) are a non-issue you call them lazy,
incompetent and start a pissing contest.

 

[John Bokma]

I am sooooo sorry. I'll get right on making all my code non-portable and
inefficient! Give me a break!

I and many others prefer if you start to educate yourself on Usenet. I
mean, posting in HTML is not done. And you called yourself "hardly" a
Usenet newbie.

 

[John Bokma]

Calling `ls /path/file` certainly is in that ls is not guaranteed to
be there
where?

nor is it guaranteed that "/" a valid directory separator.

nor is it guaranteed that there is a perl executable, nor is it
guaranteed that it's the version you're expecting. Nor is it guaranteed
that your Perl program doesn't trigger a platform specific bug in Perl
or the modules you're using. Comes with the job.

These are portability concerns not impossible hurdles!

Nor is installing ls (for example) an impossible hurdle. If it is, then
it was implied by the requirements of the job, and I wouldn't have
chosen that solution (if it was already apropriate in the first place).
What is it you don't get?

The first two.

Don't know what your rates are but there are plenty of external programs
that if I have to copy those in Perl that its cheaper to buy an
additional computer or a faster one.

Also, if execution time / memory usage are an issue Perl might be very
well have been a bad choice in the first place.

Yes I agree 100%. It can be the right tool and it also can be the
wrong tool.

Exactly, I already wrote "Depends on what you're doing of course."

It demonstrably isn't in that using opendir, etc. is better in terms
of both memory usage and execution time and really isn't a gigantic
stretch in terms of development time. Perhaps right and wrong are too
strong of terms. How about good and better?

Fine with me. You understand that "Depends on what you're doing" was a
reply to "It's generally preferable to use Perl when you write Perl
programs."

I disagree with that. There are plenty of examples that in my opinion an
external program is preferable. Perl is amongst others a glue language.

Fork overhead and non-portability are legitimate concerns.

In some situations yes. In plenty of others no. Like I wrote (again):
"Depends on what you're doing"

Sure people
can just hack off a system call to ls or something else. Again, I've
never said there's any sort of rigid rules here. However, are you
saying that fork overhead and portability issues irrelevant?

Depends on what you're doing

All I was
saying, when asked "Why would somebody not use something like 'ls'?",
fork overhead and portability are two very legitimate reasons why
somebody would not want to use "ls" in this circumstance. And there
are other circumstances where the same applies.

I quote the whole thing again:

"

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.
"

My "Depends..." was a comment on the "generally ... use Perl ... write
Perl". You seemed to be trying to make a point by staring yourself blind
on ls.

Again notice that "Depends on what you're doing" is includes all kind of
external programs that can be called from Perl.

Which I do now and then, because when I do so I consider it the (my)
best possible solution.

 

[Andrew DeFaria]

No, the part before it:

But I didn't write anything before it. Ergo you are attributing what
somebody else said to me. Your mistake - not mine!

Yes, it sounded silly. It still does. Like I said: it depends on what
you're doing. The fork overhead and the portability, if you know what
you're doing, might be considered a small price to pay for not
inventing the wheel again.

And it might not. You asked a question. Why would you do that? I gave
you an answer. Because it's more portable and efficient. Does that mean
there are no situations where the overhead and portability are not
important? No. There are exceptions to every rule. So what! Why would
people do it? Sometimes (not every time) they are concerned about being
portable or being efficient. The real question is why is this so
difficult for you to understand!

That's how I read your posts.

Oh. I see. So you read into my posts whatever you want using words,
phrases and ideas that I just didn't say just because "that's how I read
your posts". There's a word for that. It's called strawman!

If people state that there are plenty of situations one can call an
external program because fork overhead and
portability (or lack off) are a non-issue you call them lazy,

Actually they called themselves lazy and tried to say it's OK because
Larry Wall says so.

incompetent and start a pissing contest.

When I have to constantly re-write other people's code because they
consciously made it non-portable and inefficient you betcha I'm
thinking, lazy, incompetent programmers... I really don't think I'm
alone in this.

 

[Andrew DeFaria]

I and many others prefer if you start to educate yourself on Usenet. I
mean, posting in HTML is not done.

That's funny because I just seen it done! And I've seen it done many times.

Oh you mean some people don't like it. I know. I don't agree with them.

What you've never met somebody who disagreed with you?

And you called yourself "hardly" a Usenet newbie.

I'm not a newbie. I'm just one who doesn't necessarily agree with that
stance.

Now let me get back to converting all my code to be non-portable and
inefficient. It's a big job ya know!

 

[Andrew DeFaria]

where? Available for execution.
nor is it guaranteed that there is a perl executable, nor is it
guaranteed that it's the version you're expecting. Nor is it
guaranteed that your Perl program doesn't trigger a platform specific
bug in Perl or the modules you're using. Comes with the job.

Right. We have much to be concerned about. Let's not start adding new
problems...

Nor is installing ls (for example) an impossible hurdle. If it is,
then it was implied by the requirements of the job, and I wouldn't
have chosen that solution (if it was already apropriate in the first
place). What is it you don't get?

What I don't get is why you insist on adding more dependencies...

Fine with me. You understand that "Depends on what you're doing" was a
reply to "It's generally preferable to use Perl when you write Perl
programs."

Which were not my words. Perhaps you should argue with that guy. BTW I
happen to agree with him.

I disagree with that. There are plenty of examples that in my opinion
an external program is preferable. Perl is amongst others a glue language. Great. Tell it to that guy...
In some situations yes. In plenty of others no. Like I wrote (again):
"Depends on what you're doing"

I was specifically answering a question that you posed about a specific
set of examples. One example was using "ls". So, is it better to use
"ls" or do it using opendir, etc.?

I quote the whole thing again:

"
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.
"

My "Depends..." was a comment on the "generally ... use Perl ... write
Perl". You seemed to be trying to make a point by staring yourself
blind on ls.

Indeed however the part that I wrote was obviously directed at your
question about why somebody would do such a thing. A "because" is an
answer to a "why" question, not an answer to a "depends" statement. I
take it that English is not your first language...

 

[Andrew DeFaria]

But even if you think that, how does that lead to "never use 'ls'"?

Ugh another one! I never said "never use ls". If you wish to argue that
point then find somebody who actually said that.

While I often write programs that check the content of a single
directory, I don't recall ever writing a program that needed to trawl
through thousands of directories where I couldn't use 'find' (which I
prefer over File::Find).

Here's a secret. Get this. Sometimes I work on, shhhh. gush... a program
that I didn't write. Now don't tell anybody...

All the Perl programs (and most of the programs in other languages)
I've written for my employers have been in-house tools as well. And
because they are in-house tools, I know in which environment they are
going to be run. Really, if I'm writing a tool to deploy a specific
piece of software that only runs on AIX and for which we have bought
half a million dollars worth of hardware on which Windows won't even
run, I'm not going to worry whether my tool is going to be run on
Windows. Specially not if the tool needs to be ready yesterday.

The client that I cited as an example had probably more than 1/2 million
in (Windows) hardware too and swore up and down that they would not be
using Unix. But guess what?

That's OK. Keeps me in business...

I never argued one should write inefficient code. Or to increase
non-portableness.

My statement was simple, some people might avoid using an external
program because they are concerned about portability and being
efficient. That's it! Since you state above that you aren't arguing that
people should not strive to write inefficient code or decrease
portability I can only therefore assume you are now incomplete agreement
with me. Viola! No need to continue this argument!

// 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.

And just a few paragraphs ago, you were talking about writing in-house
tools.

Ah duh, the tool is for use in-house by the client. IOW it's not a tool
made for retail distribution.

 

[John Bokma]

But I didn't write anything before it.

But I did:

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

After that I wrote a kind of rhetorical part: "Why would I copy a program
that does already its work perfectly and reinvent the wheel?"

To which you replied (paraphrased): fork overhead & non-portable

Maybe you want to carefully (this time) read

And it might not. You asked a question. Why would you do that? I gave
you an answer. Because it's more portable and efficient.

Regarding the former: if the program is not available there is no way the
external program does its work perfectly of course.

Now regarding efficiency: that's also not an easy thing to answer for many
reasons. As far as I know (but I am quite out of it to be honest) the
overhead of forking has been reduced a lot over the years, also because
forking is very common. Moreover, on Windows (again as far as I know, I
might be very wrong here) forking is emulated by threading with (again
that disclaimer) way less overhead compared to a classic *nix fork.

However: if efficiency is that big an issue probably you shouldn't have
opted for Perl in the first place.

Does that mean
there are no situations where the overhead and portability are not
important?

Of course there are, but I excluded your portability argument by asking
"why ... its work perfectly" which (work) a non-available program can't
do.

As for the overhead, you might be right in some circumstances, but in that
case I agree with Abigail: you shouldn't have picked Perl in the first
place.

No. There are exceptions to every rule. So what! Why would
people do it? Sometimes (not every time) they are concerned about being
portable or being efficient. The real question is why is this so
difficult for you to understand!

Again, if the overhead of fork forces you to copy a well working program
in Perl you're very likely on the wrong track to begin with. Hourly rates
of skilled Perl programmers exceed the price of a faster computer in a
short time. Using an external program in a way outsources part of the
solution you're working on. And in many cases the external program has
been more widely tested then you can manage on your own.

And if the bottleneck is that serious that the faster hardware is so
expensive that its ok for you to copy an external program into Perl then I
am very sure Perl was a bad choice.

Oh. I see. So you read into my posts whatever you want using words,
phrases and ideas that I just didn't say just because "that's how I read
your posts". There's a word for that. It's called strawman!

Only if I severely misrepresent your argument. After carefully rereading
your attacks (since that's how I read them, which again is not a strawman)
I am even more convinced that I am right.

Actually they called themselves lazy and tried to say it's OK because
Larry Wall says so.

There is nothing wrong with being lazy. It stops one very often from doing
stupid things :-D.

When I have to constantly re-write other people's code because they
consciously made it non-portable and inefficient you betcha I'm
thinking, lazy, incompetent programmers... I really don't think I'm
alone in this.

Sure, every programmer calls the work of many others utter crap. And very
often they are right. But there are also programmers who think that
because they have seen it used wrong in many cases that there is a need to
educate other programmers even when those other programmers clearly have a
very good argument why they are using it in the first place.

I am not a big fan of "foo considered harmful" when it's written like it's
against the law. To me programming is about flexibily and freedom of
expressing oneself. Creativity and such. IMNSHO you tried to make a too
strong case against calling external programs missing a bit what I
originally wrote.

 

[John Bokma]

Oh you mean some people don't like it. I know. I don't agree with
them.

In short you're ignoring the guidelines of a technical group because
you're a loser.

 

[John Bokma]

Available for execution.

Like the perl executable is not guaranteed to be available for
execution? Tell me something new.

Right. We have much to be concerned about. Let's not start adding new
problems...

My point. If the external program does perfectly its work (my
prerequisite) then it's available for execution.

What I don't get is why you insist on adding more dependencies...

Your mistaken (no that's not something new). Instead of copying
perfectly working (prerequisite) functionality to Perl, I decided to use
the aforementioned external program. Or does the program not depend on
the functionality if you write it yourself?

Which were not my words. Perhaps you should argue with that guy. BTW I
happen to agree with him.

Yes, and hence I argue with you. Moreover you just confirmed that I was
right with my reading between the lines instead of using a straw man
:-D (not a surprise there).

Great. Tell it to that guy...

This is Usenet. You jumped in (agree with him), so I discuss with you
and am aware that as a side effect I might reach David as well.

I was specifically answering a question that you posed about a
specific set of examples. One example was using "ls".

It's you who should read better.

"

Depends on what you're doing of course. Why would I copy a program
that does already its work perfectly and reinvent the wheel?

"

How that can refer to a specific set of examples is a bit beyond me.
Maybe you can clarify?

So, is it better
to use "ls" or do it using opendir, etc.?

"Depends on what you're doing of course."

If you need an example, Abigail mentioned one involving grep. I know,
it's not ls and I hope you can live with that.

Which, again, is something that I didn't write!

But like I said earlier, you seem to agree with it (I wrote something
along "read it between the lines"). You just confirmed that you *do*
agree with it (few paragraphs up). I disagree with "generally
preferable" which sounds to me too much like: "Using external programs
from Perl programs considered harmful". People (like you, I am afraid)
take it too serious.

Also, if you agree with someone, and jump into a public discussion,
don't be so amazed that people start to agree or disagree with you. This
is Usenet, remember.

Indeed however the part that I wrote was obviously directed at your
question about why somebody would do such a thing. A "because" is an
answer to a "why" question, not an answer to a "depends" statement.

If you write a Perl program that has to be portable "a [external]
program that does already its work perfectly" implies that it's
available. So your second point (portability) is void, unless you want
to imply that every Perl program has to be written portable because you
can.

As for your first point: I have a gut feeling that fork overhead is
overrated and in cases it plays an important role it might be very well
the case that Perl itself is an option, making your first point somewhat
void as well.

I take it that English is not your first language...

Yet I seem to have less problems with it. But even if you're right,
we're talking about programming here.