Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Perl > Perl Misc > Unix commands

Reply
Thread Tools

Unix commands

 
 
John Bokma
Guest
Posts: n/a
 
      01-13-2007
Andrew DeFaria <(E-Mail Removed)> wrote:

> 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?

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


--
John Experienced Perl programmer: http://castleamber.com/

Perl help, tutorials, and examples: http://johnbokma.com/perl/
 
Reply With Quote
 
 
 
 
Andrew DeFaria
Guest
Posts: n/a
 
      01-13-2007
Abigail wrote:
> 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!

--

Andrew DeFaria <http://defaria.com>
You never really learn to swear until you learn to drive.

 
Reply With Quote
 
 
 
 
John Bokma
Guest
Posts: n/a
 
      01-13-2007
Andrew DeFaria <(E-Mail Removed)> wrote:

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

>> 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/
 
Reply With Quote
 
Andrew DeFaria
Guest
Posts: n/a
 
      01-13-2007
Abigail wrote:
> 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.
--
Andrew DeFaria <http://defaria.com>
Does your train of thought have a caboose?

 
Reply With Quote
 
Charlton Wilbur
Guest
Posts: n/a
 
      01-13-2007
>>>>> "ADF" == Andrew DeFaria <(E-Mail Removed)> writes:

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


--
Charlton Wilbur
http://www.velocityreviews.com/forums/(E-Mail Removed)
 
Reply With Quote
 
John Bokma
Guest
Posts: n/a
 
      01-13-2007
Andrew DeFaria <(E-Mail Removed)> wrote:

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

>> 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!


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
hubris, says Larry Wall." <http://www.paulagordon.com/shows/wall/>

> 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?

--
John Experienced Perl programmer: http://castleamber.com/

Perl help, tutorials, and examples: http://johnbokma.com/perl/
 
Reply With Quote
 
Andrew DeFaria
Guest
Posts: n/a
 
      01-13-2007
Charlton Wilbur wrote:
> 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.

--

Andrew DeFaria <http://defaria.com>
I hit the CTRL key but I'm still not in control!

 
Reply With Quote
 
Dan Mercer
Guest
Posts: n/a
 
      01-13-2007

"Andrew DeFaria" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed). ..
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.

--
Andrew DeFaria
Why do the Alphabet song and Twinkle, Twinkle Little Star have the same tune?


 
Reply With Quote
 
Dan Mercer
Guest
Posts: n/a
 
      01-13-2007

"John Bokma" <(E-Mail Removed)> wrote in message news:Xns98B777C654642castleamber@130.133.1.4...
: Andrew DeFaria <(E-Mail Removed)> wrote:
:
: > 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/


 
Reply With Quote
 
John Bokma
Guest
Posts: n/a
 
      01-13-2007
Andrew DeFaria <(E-Mail Removed)> wrote:

> 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 "<(E-Mail Removed) >" were I
clearly wrote: "Depends on what you're doing of course."

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


[1] <(E-Mail Removed)>

--
John Experienced Perl programmer: http://castleamber.com/

Perl help, tutorials, and examples: http://johnbokma.com/perl/
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Unix commands implemented ? (grep, wc, cat...) Spendius Java 2 12-13-2004 01:58 PM
Need Help Differentiating Bad Commands From Incomplete Commands Tim Stanka Python 1 08-02-2004 02:08 AM
Get all commands from unix Yadagiri Rao KP Java 4 08-07-2003 02:49 PM
Run unix commands from Java Yadagiri Rao KP Java 2 08-05-2003 02:11 PM
Re: man pages for C commands (GCC commands) Ben Pfaff C Programming 4 06-28-2003 06:21 PM



Advertisments