Unix commands
Kim Gardiner CS2003
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 ", $?);
xho...@gmail.com
> 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
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
Warren Block
Even if it doesn't, you can still issue them.
--
Warren Block * Rapid City, South Dakota * USA
use...@davidfilmer.com
> 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.
--
The best way to get a good answer is to ask a good question.
David Filmer (http://DavidFilmer.com)
John Bokma
> Kim Gardiner CS2003 wrote:
>> Can you issue UNIX commands using Perl?
>
> 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?
--
John Experienced Perl programmer: http://castleamber.com/
Perl help, tutorials, and examples: http://johnbokma.com/perl/
Abigail
September MCMXCIII in <URL:news:1168642359.6...@38g2000cwa.googlegroups.com>:
?? Kim Gardiner CS2003 wrote:
?? > Can you issue UNIX commands using Perl?
??
?? You can, but it's often a bad idea.
Really? You have something against code reuse?
?? Some folks treat Perl like a glorified korn shell, and do ghastly
?? things like this:
?? my @data = `cat somefile.txt`;
What's so ghastly about that? I often write
my $text = `cat file`;
instead of
my $text;
{
local $/;
open my $fh => "<", 'file' or die "open: $!";
$text = <$fh>;
}
which takes 6 lines instead of 1. Even if you don't count the lines
that delimit the block, you still end up with four times as many lines.
Of course, one could do it in one "line" of Perl:
my $text = do {local (@ARGV, $/) = 'file'; <>;};
but I think that `cat file` is much clearer.
?? or
?? 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.
?? 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.
Agreed, but the for the examples you mention, Perl *doesn't* have buildins.
Tools I often call from Perl and for which Perl equivalents could be used
include (but aren't limited to): mv, cp, rm, mkdir, cat, mail, ls, uname, ...
Abigail
--
perl -MLWP::UserAgent -MHTML::TreeBuilder -MHTML::FormatText -wle'print +(
HTML::FormatText -> new -> format (HTML::TreeBuilder -> new -> parse (
LWP::UserAgent -> new -> request (HTTP::Request -> new ("GET",
"http://work.ucsd.edu:5141/cgi-bin/http_webster?isindex=perl")) -> content))
=~ /(.*\))[-\s]+Addition/s) [0]'
Tad McClellan
> Kim Gardiner CS2003 ha escrito:
>
>> Can you issue UNIX commands using Perl?
> 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.
--
Tad McClellan SGML consulting
ta...@augustmail.com Perl programming
Fort Worth, Texas
Jürgen Exner
> Jürgen Exner <jurg...@hotmail.com> wrote:
>> Kim Gardiner CS2003 wrote:
>>> Can you issue UNIX commands using Perl?
>>
>> Sure you can, provided your operating system supports them.
>
> Even if it doesn't, you can still issue them.
Well, guess that's true ;-)
jue
Andrew DeFaria
Some folks treat Perl like a glorified korn shell, and do ghastly things like this: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?
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.
--Andrew DeFaria
Why do the Alphabet song and Twinkle, Twinkle Little Star have the same tune?
John Bokma
> 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.
Abigail
MCMXCIII in <URL:news:X5CdnYE4KLbIpDXY...@comcast.com>:
__
__ John Bokma wrote:
__
__ > 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
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.
__ 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. 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.
__ "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.
Abigail
--
# Count the number of lines; code doesn't match \w. Linux specific.
()=<>;$!=$=;($:,$,,$;,$")=$!=~/.(.)..(.)(.)..(.)/;
$;++;$*++;$;++;$*++;$;++;`$:$,$;$" $. >&$*`;
Andrew DeFaria
Andrew DeFaria <And...@DeFaria.com> 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 Perlwhen 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) portabilityAs 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.
Still I try to write scripts that work, anticipate bugs and error conditions, etc. even when I'm pretty convinced that they are not probable.
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. You apparently don't seem to think that's important. This is good to know.
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/
Now while I understand the significance and usefulness of a package like Cygwin, which can solve the gzip and wget issues you blog about but also solve a host of other needs from ftp, httpd, smtp, ls, X server, grep, awk, diff and quite literally thousands of others, I cannot guarantee that the client will go for it. Indeed many do not.
As such, when faced with the programming challenge of getting a list of files in the current directory that begin with "a" one can rely on my @output = `ls a*` or one could do it in a Perl like manner. The later will port and be quicker for those clients who respond "Sorry but we don't support/want to install Cygwin|other utility".
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.
My Perl scripts can and are used on various 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.
Think about how hard perl -MCPAN would be if it required you to install all those tools instead of used various methods to get the job done when such tools are not present.
--Andrew DeFaria
Why doesn't the glue stick to the inside of the bottle?
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.
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.
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.
__ "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.
--Andrew DeFaria
You never really learn to swear until you learn to drive.
Abigail
== This is a multi-part message in MIME format.
== --------------000304000205010703050300
== Content-Type: text/plain; charset=ISO-8859-1; format=flowed
== Content-Transfer-Encoding: 7bit
==
== 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!
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.
And even ten, saying "if you do it 10,000 times, it's slow, so you should
never use it" is sillyness. 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?
== > __ 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?
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.
== 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.
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 (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.
== > 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.
Yes, and? Just because you have to port your programs to Windows, doesn't
mean I have to restrict myself and not to use the excellent tools any
Unix system gives me.
== > __ "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!
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.
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.
Abigail
--
$_ = "\112\165\163\1648\141\156\157\164\150\145\1628\120\145"
. "\162\1548\110\141\143\153\145\162\0128\177" and &japh;
sub japh {print "@_" and return if pop; split /\d/ and &japh}
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.
>> 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?
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.
And even ten, saying "if you do it 10,000 times, it's slow, so you should never use it" is sillyness.
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. I don't do Windows and I've never done Windows. And I don't apply for jobs that involve doing anything on Windows.
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
(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.
Yes, and? Just because you have to port your programs to Windows,
doesn't mean I have to restrict myself and not to use the excellent tools any Unix system gives me.
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.
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.
--
Andrew DeFaria
Does your train of thought have a caboose?
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
--
Charlton Wilbur
cwi...@chromatico.net
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.
>> 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?
Andrew DeFaria
Andrew DeFaria <And...@DeFaria.com> wrote:
Taking the poor grammar out of the pictureAs soon as people talk about grammer usage (or abuse) in a Usenet post they have little to say about the issue at hand,
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, ISo they have no problem with you installing Perl, but they do have a problem when you install (from your example) ls.
cannot guarantee that the client will go for it. Indeed many do not.
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.
My big question to you is: Don't you do the same?!?
And for most that's a non-issue.Not all Perl scripts are used on different platforms.Yes and many of them can't because they use things like those described above.
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.
Then their problem already starts with using Perl on Windows (for example).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.
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.
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.
A debat which you avoid by making up a brain dead rule.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.
I did not, and I repeat for the insane people here, NOT make up a brain dead rule as you call it. I made no rule at all.
Think about how hard perl -MCPANWhat!? Installing external libraries on Perl? That *is* allowed and a single executable not?
--
Andrew DeFaria
Why do they sterilize needles for lethal injections?
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.
--Andrew DeFaria
I hit the CTRL key but I'm still not in control!
Dan Mercer
"Andrew DeFaria" <And...@DeFaria.com> wrote in message
news:X5CdnYE4KLbIpDXY...@comcast.com...
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
Dan Mercer
"John Bokma" <jo...@castleamber.com> wrote in message news:Xns98B777C654...@130.133.1.4...
: Andrew DeFaria <And...@DeFaria.com> 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
Andrew DeFaria
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.
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.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!
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.
That was a joke son - don't take offense.
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?
--
Andrew DeFaria
The good old days: When sex was dirty & Michael Jackson was black
Tintin
"Abigail" <abi...@abigail.be> wrote in message
news:slrneqg79p...@alexandra.abigail.be...
> ?? 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/*>;
--
Posted via a free Usenet account from http://www.teranews.com
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 "<X5CdnYE4KLbIpDXY...@comcast.com>" were I
clearly wrote: "Depends on what you're doing of course."
Now who has a problem with interpretoring [1] things?
[1] <apadnbh91OFHpTTY...@comcast.com>
Andrew DeFaria
Andrew DeFaria <And...@DeFaria.com> 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 "<X5CdnYE4KLbIpDXY...@comcast.com>"
were I clearly wrote: "Depends on what you're doing of course."
Now who has a problem with interpretoring [1] things?
[1] <apadnbh91OFHpTTY...@comcast.com>Another email address...
--Andrew DeFaria
Be different. Conform.
Tad McClellan
> This is a multi-part message in MIME format.
Please do not post multi-part messages in MIME format.
> Abigail wrote:
>> 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?
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
> John Bokma wrote:
>> Andrew DeFaria <And...@DeFaria.com> 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 "<X5CdnYE4KLbIpDXY...@comcast.com>"
> 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> 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.
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.
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
Andrew DeFaria <And...@DeFaria.com> wrote:
This is a multi-part message in MIME format.Please do not post multi-part messages in MIME format.
Abigail wrote:
How does having seen a Perl script run on Windows prove that perl comes with Windows?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?
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?You can answer that question yourself.
--
Andrew DeFaria
When God is amazed, does he say: "Oh my Me!"?
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="midslrneqig...@tadmc30.august.net"
Your choice
*PLONK*
jue
Andrew DeFaria
Maybe reread "<X5CdnYE4KLbIpDXY...@comcast.com>"
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.
The requested message, X5CdnYE4KLbIpDXY...@comcast.com, 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
Doesn't "expecting the unexpected" make the unexpected the expected.
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.
--
Andrew DeFaria
It's not hard to meet expenses, they're everywhere.
Andrew DeFaria
Andrew DeFaria <And...@DeFaria.com> wrote:
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.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?)
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.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.
--Andrew DeFaria
CONGRESS.SYS Corrupted: Re-boot Washington D.C (Y/n)?
Abigail
MCMXCIII in <URL:news:45a92ff4$0$13114$8826...@free.teranews.com>:
||
|| "Abigail" <abi...@abigail.be> wrote in message
|| news:slrneqg79p...@alexandra.abigail.be...
|| > ?? 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/*>;
Because glob expands like the csh does. And the csh often does things
I don't expect. So I avoid glob. Besides, glob() has changed subtlety
between perl versions.
Abigail
--
perl -e '$a = q 94a75737420616e6f74686572205065726c204861636b65720a9 and
${qq$\x5F$} = q 97265646f9 and s g..g;
qq e\x63\x68\x72\x20\x30\x78$&eggee;
{eval if $a =~ s e..eqq qprint chr 0x$& and \x71\x20\x71\x71qeexcess}'
John Bokma
> John Bokma wrote:
>>>> Maybe reread "<X5CdnYE4KLbIpDXY...@comcast.com>"
>>> That's an email address. Tell me, how do I read an email address?
>> Usenet newbie?
> 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,
> X5CdnYE4KLbIpDXY...@comcast.com, could not be found..
"if the message has been archived in Google"
<Xns98B79525AE...@130.133.1.4>
> 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
> John Bokma wrote:
>> Andrew DeFaria <And...@DeFaria.com> wrote:
>>> 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.
> 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?
>> 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.
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.
>> 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.
Exactly, I already wrote "Depends on what you're doing of course."
<Xns98B6B0CB3A...@130.133.1.4>
>> 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?
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.
>> 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.
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:
"
>> 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 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.
Abigail
MCMXCIII in <URL:news:7sCdnV2zsL0xszTY...@comcast.com>:
//
// 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....
But even if you think that, how does that lead to "never use 'ls'"?
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).
// > (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.
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.
// 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.
I never argued one should write inefficient code. Or to increase
non-portableness. But programming means making trade-offs. One
trade-off you make is the choice of language. You pick Perl for
whatever reason, but you trade in bucket loads of efficientness.
Whining about efficiency on seeing a single fork/exec but keeping
your mouth shut about the choice of a very slow language is stupid.
// > 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!
Good for you. I myself couldn't care less what MS requires on
whatever installation of Windows. As I said, I don't deal with
Windows and I can afford it to pick my place of employment such
that I don't have to deal with Windows either.
// 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 just don't like wasting my companies time to make a tool more complex
so it may be run (something I wouldn't even know lacking the OS to
test it out) on a platform that's very unlikely to be used.
// > 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.
And just a few paragraphs ago, you were talking about writing in-house tools.
Abigail
--
A perl rose: perl -e '@}-`-,-`-%-'
Abigail
MCMXCIII in <URL:news:7sCdnV2zsL0xszTY...@comcast.com>:
## 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?
Funny that you mention that example. Some time ago I wrote a program
that repeatedly (as in hundreds of thousands of times) needed to find
words given a certain pattern (the pattern varied). My first attempt
was to read in all the words in an array and use 'grep {/pattern/}'.
It was unbearingly slow, until I started to use the external grep.
The program became much, much faster.
Abigail
--
$_ = "\112\165\163\1648\141\156\157\164\150\145\1628\120\145"
. "\162\1548\110\141\143\153\145\162\0128\177" and &japh;
sub japh {print "@_" and return if pop; split /\d/ and &japh}
Andrew DeFaria
Finding it by hand I take it you mean when I said:No, the part before it:
Because 1) it's inefficient in that you are forking and exec'ing a
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.
--
Andrew DeFaria
One time a cop pulled me over for running a stop sign. He said "Didn't you see the stop sign." I said "Yeah, but I don't believe everything I read."
Andrew DeFaria
Andrew DeFaria <And...@DeFaria.com> wrote:
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.
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.
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
Does your train of thought have a caboose?
Andrew DeFaria
Calling `ls /path/file` certainly is in that ls is not guaranteed to be therewhere?
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?
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"
I quote the whole thing again:
"
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 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.
--
Andrew DeFaria
If you can smile when things go wrong, you have someone in mind to blame.
Andrew DeFaria
But even if you think that, how does that lead to "never use 'ls'"?
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).
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.
That's OK. Keeps me in business...
I never argued one should write inefficient code. Or to increase non-portableness.
// 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.
--
Andrew DeFaria
They show you how detergents take out bloodstains. I think if you've got a T-shirt with bloodstains all over it, maybe your laundry isn't your biggest problem.
Abigail
MCMXCIII in <URL:news:I-adnetb0NVz4DTY...@comcast.com>:
,, This is a multi-part message in MIME format.
,, --------------040403050602070104090103
,, Content-Type: text/plain; charset=ISO-8859-1; format=flowed
,, Content-Transfer-Encoding: 7bit
,,
,, Abigail wrote:
,, > 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...
Your point being? What does that have to do with calling or not calling
external programs?
,, > 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?
You were hired again? Is that situation different from someone saying that
it has to work on perl 5.6, but then they start using it in an environment
that has 5.005? Or perl4? How portable are you? On which versions of perl
will your script run?
As I said, I write in-house tools. For environments I not only know, but
I also have a say in how that will look like in the future.
And I expect any programmer to know in which environment(s) his work
will have to run and code accordingly. And I don't like people advocating
I should code in a way that my programs run in environment they have to
code for. I write for my environment, and your write for yours.
,, Ah duh, the tool is for use in-house by the client. IOW it's not a tool
,, made for retail distribution.
Djees, with such a definition, any software is "in-house". Eventually,
someone will run it and not sell it, making it "in-house".
Abigail
--
perl -we 'eval {die ["Just another Perl Hacker\n"]}; print ${$@}[$#{@${@}}]'
Andrew DeFaria
Andrew DeFaria (And...@DeFaria.com) wrote on MMMMDCCCLXXXIV September
MCMXCIII in <URL:news:I-adnetb0NVz4DTY...@comcast.com>:
,, This is a multi-part message in MIME format.
,, --------------040403050602070104090103
,, Content-Type: text/plain; charset=ISO-8859-1; format=flowed
,, Content-Transfer-Encoding: 7bit
,,
,, Abigail wrote:
,, > 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...
Your point being? What does that have to do with calling or not calling
external programs?
,, Ah duh, the tool is for use in-house by the client. IOW it's not a tool
,, made for retail distribution.
Djees, with such a definition, any software is "in-house". Eventually,
someone will run it and not sell it, making it "in-house".
And they were bragging about you...
--
Andrew DeFaria
What has four legs and an arm? A happy pit bull.
John Bokma
> John Bokma wrote:
>>> 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:
> But I didn't write anything before it.
But I did:
"Maybe reread "<X5CdnYE4KLbIpDXY...@comcast.com>" 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
<slrneqirua...@alexandra.abigail.be>?
>> 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.
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.
>> 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.
There is nothing wrong with being lazy. It stops one very often from doing
stupid things :-D.
>> 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.
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
> John Bokma wrote:
>>> Calling `ls /path/file` certainly is in that ls is not guaranteed to
>>> be there
>> where?
>
> Available for execution.
Like the perl executable is not guaranteed to be available for
execution? Tell me something new.
>>> 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.
> 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.
>> 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...
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?
>> 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.
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).
>> 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...
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.
>>> 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"
> 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.
"
>>"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?
"
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.
>> I quote the whole thing again:
>>
>> "
>>>> It's generally preferable to use Perl when you write Perl programs.
> 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.
>>> 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.
> 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.
Andrew DeFaria
Andrew DeFaria <And...@DeFaria.com> wrote:
Oh you mean some people don't like it. I know. I don't agree withthem.In short you're ignoring the guidelines of a technical group because you're a loser.
--Andrew DeFaria
I wouldn't be caught dead with a necrophiliac.
Andrew DeFaria
Andrew DeFaria <And...@DeFaria.com> wrote:
John Bokma wrote:But I did:
But I didn't write anything before it.Finding it by hand I take it you mean when I said:No, the part before it:
Because 1) it's inefficient in that you are forking and exec'ing a
"Maybe reread "<X5CdnYE4KLbIpDXY...@comcast.com>" 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
<slrneqirua...@alexandra.abigail.be>?
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.
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.
There is nothing wrong with being lazy. It stops one very often from doing stupid things :-D.
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.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.
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.
--
Andrew DeFaria
Taxation with representation isn't so hot, either!
Andrew DeFaria
Andrew DeFaria <And...@DeFaria.com> wrote:
John Bokma wrote:
Available for execution.Calling `ls /path/file` certainly is in that ls is not guaranteed tobe therewhere?
Like the perl executable is not guaranteed to be available for execution? Tell me something new.
Yes, and hence I argue with you.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.
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).
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 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...
And by and large I'd say that 70-80% of the time the implementor does not spend even a second of time making an informed and thoughtful decision between "should I implement this in an efficient and portable manner or should I just call X". Often they call X because that's the only way they know to do it. They do it, as you freely admit to, because they are lazy and it's "easier" than thinking or typing (still wish to brag about being lazy - you probably do. Do you realize how foolish that makes you appear?). And often when confronted why they chose to use X instead of something more efficient or portable they often don't have any particularly convincing argument other than "well it was easy/quick/a one time script/I'm lazy/etc". I know, I've asked and these are the answers I receive 70-80% of the time.
It's you who should read better.I was specifically answering a question that you posed about a specific set of examples. One example was using "ls".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"
"
""It's generally preferable to use Perl whenDepends on what you're doing of course. Why would I copy a program
you write Perl programs.
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?
Here's the whole quote:
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 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.
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.
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.I quote the whole thing again:Which, again, is something that I didn't write!
"
It's generally preferable to use Perl when you write Perl programs.
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.
--
Andrew DeFaria
I have seen the truth and it makes no sense.
John Bokma
> John Bokma wrote:
>> Maybe you want to carefully (this time) read
>> <slrneqirua...@alexandra.abigail.be>?
> There's nothing to more carefully read.
I was afraid so. Maybe you should. You know now how to read "email" ;-)
>> 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.
> Argh! You just like to argue don't you.
Yes, of course. You too, otherwise you would not even have cared to
reply to me in the first place.
Also I like to show that there is no such thing as "generally
preferable" regarding not calling external programs.
[ straw man ]
>> Only if I severely misrepresent your argument.
> Which you have, over and over again...
Since you admitted that you agree with David's earlier statement I
haven't. Conclusion: I read correctly between the lines that you have in
general disagree on calling external programs from Perl.
Also, if you think I misrepresent your argument just quote your
argument, my misrepresentation and your clarification on my
misrepresentation. Picture, or it didn't happen.
>> After carefully rereading your attacks (since that's how I read them,
>> which again is not a strawman)
> No, which again is a strawman...
Picture, or it didn't happen.
>> I am even more convinced that I am right.
> Because you apparently need to be.
Ah, and you don't? Is that why you on purpose posted in HTML and lowered
yourself to argumentum ad hominem on several occasions?
>> There is nothing wrong with being lazy. It stops one very often from
>> doing stupid things :-D.
> Right. Bragging that you're lazy.... That's rich!
Calling people lazy because you disagree isn't?
I prefer to deliver the best possible solution to my customers. That
means that I shop at CPAN and many other places whenever possible,
including the use of external 3rd party programs. Yes, I am lazy. I
prefer to work as short as possible on a project.
"Laziness drives one to work very hard to avoid future work for a future
self. Impatience has the same endgame."
<http://www.paulagordon.com/shows/wall/>
>> ... 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.
> Right, the "I'm lazy" argument...
Which you don't seem to understand. Which is odd, because it's closely
related to Perl culture, at least that's how I see it.
>> I am not a big fan of "foo considered harmful" when it's written like
>> it's against the law.
> Great! Go argue with that other guy.
You seem to be the argumentive one, which is more fun :-D.
>> 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.
> I ain't missed nothing here. It's you who doesn't have a clue.
Picture, or it didn't happen ;-)
Andrew DeFaria
Since you admitted that you agree with David's earlier statement I haven't. Conclusion: I read correctly between the lines that you have in general disagree on calling external programs from Perl.Only if I severely misrepresent your argument.Which you have, over and over again...
Also, if you think I misrepresent your argument just quote your argument, my misrepresentation and your clarification on my misrepresentation.
Picture, or it didn't happen.
Right, the "I'm lazy" argument...Which you don't seem to understand. Which is odd, because it's closely related to Perl culture, at least that's how I see it.
--
Andrew DeFaria
A truly wise man never plays leapfrog with a unicorn.
John Bokma
> John Bokma wrote:
>> Andrew DeFaria <And...@DeFaria.com> wrote:
>>
>>> John Bokma wrote:
>>>>> Calling `ls /path/file` certainly is in that ls is not guaranteed
>>>>> tobe there
>>>> where?
>>> Available for execution.
>> Like the perl executable is not guaranteed to be available for
>> execution? Tell me something new.
> Ugh your circularly illogical arguments are really tiring...
Just a side note: I hope your source code uses more white space compared
to your Usenet posts. You even remove the white space I have included
for readability. Let me guess, you spend a lot of time when working in a
team on "correcting" the /style/ of others. And you call that working
very hard on a project ;-)
>> Yes, and hence I argue with you.
> You'd argue with a rock!
If that rock is stupid enough to keep coming back for more, sure why
not?
>> 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).
> You're reading between the lines was that there's some hard and fast
> rule.
"In general it's preferable"
How flexible is that? Also your other statements showed that you have
quite a rigid opinion on using external tools (lazy (in a bad way) was
one of them)
>> 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.
> Right, yet you put words in my mouth (and David's BTW) that I've said
> "thou must rigidly adhere to this rule" when neither of us said that.
"In general it's preferable" sounds quite rigid to me. Even if it's not
rigid, the way it was expressed it can be used as a straw man at all
times. You know, when one programmer looks over the code of someone else
and just for the sake of argument says: you n00b don't call external
programs because there is a huge fork overhead, and it's not portable
(even if neither are an issue). You probably recognize the first
programmer.
> You obviously don't understand that there is indeed a real difference
> between "In general this is a good idea" to "thou must do X" but
> you'll argue with a rock that they are exactly the same thing!
They might mean different things, but the former is often used in
various arguments like it's the latter. I have surely read your posts
this way. I doubt it's my bad.
> And by and large I'd say that 70-80% of the time the implementor does
> not spend even a second of time making an informed and thoughtful
> decision between "should I implement this in an efficient and portable
> manner or should I just call X". Often they call X because that's the
> only way they know to do it.
I am convinced that there is more Perl (or any code in general) out
there that suffers from the implementor writing a very bad
implementation of something that is already available either as a
library or as an external tool. "Rules" (for your sake) like "In general
it's preferable" only give them a few meters more rope to hang
themselves (and everybody else involved).
> They do it, as you freely admit to,
> because they are lazy and it's "easier" than thinking or typing (still
> wish to brag about being lazy - you probably do. Do you realize how
> foolish that makes you appear?).
No, because I don't call that lazy but underskilled.
> And often when confronted why they
> chose to use X instead of something more efficient or portable they
> often don't have any particularly convincing argument other than "well
> it was easy/quick/a one time script/I'm lazy/etc".
Yup, for the same reason people come up with /huge/ fork overheads and
"but the ZX Spectrum doesn't have ls built in ROM".
> I know, I've asked
> and these are the answers I receive 70-80% of the time.
So you're just saying that a majority of the programmers are
underskilled. Doesn't amaze me the least. Question is: how often did
people say that they did it and you disagreed with them without even
taken into account the real situation and just grabbed at straws like
"fork overhead" and "non-portable" just because of "your" "in general".
>> How that can refer to a specific set of examples is a bit beyond me.
>> Maybe you can clarify?
> God you are exceptionally obtuse and argumentative. Let's be complete
> shall we?
>
> Here's the whole quote:
>
>>> 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.
It's /generally/
>> Depends on what you're doing of course.
Depends on what you're doing of course.
> Do you see any example Perl code in there? I see two. One is `cat
> somefile.txt` and the other is `ls /some/directory`. Those were the
> examples I was talking about you nimrod! You sir are an intellectually
> dishonest man and really not worth arguing with.
Yet I am convinced you can't resist replying 5 more times ;-). But even
with cat and ls: "it depends on what you're doing of course".
>>> 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.
> So, IOW, when confronted with a direct question you avoid it.
Nope: I said: depends on what you're doing.
> This
> combined with the above obvious misquotation, lack of reading and
> comprehension skills or pure intellectual dishonesty severely lowers
> your credibility in many people's eyes.
Ah, you are now representing a group of people? Or do you think your
argument gets better the more you drag into it? Like I said, Abigail
provided an example involving grep. I did miss your reply to that
however.
>> 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.
> There's a world of difference between a recommendation and a rigid
> rule as you claim.
Sure. The said thing is people forget that often when they look over the
code of someone else. Then suddenly overheads and portability is dragged
into the discussion even if it's not important. You, in my opinion, did
this.
> You're all over the map in your argument, use
> strawmen arguments, deliberately misquote context and you are evasive
> when asked a direct question. In short you're not worth arguing with
> as you are dishonest at best.
argumentum ad hominem or: picture, or it didn't happen.
[ Usenet ]
> From what I can tell this is where a bunch of losers who like to
> argue
> hang out. Which is why I rarely post. However I thought that
> occasionally I could make a point and people who have more integrity
> than you have shown here would benefit. Apparently I misjudged the
> number of people here with integrity! Either that or they are very
> quiet...
Maybe if you stop making all that noise. A lot of people have kill filed
you just because you ignored the posting guidelines on purpose.
I agree that one shouldn't stick to rules for the sake of rules. But
ignoring a guideline just because you consider it losing face /is/
losing face big time. Can you explain what the use is of posting both in
plain text and HTML in a group that prefers for several reasons plain
text? Ignoring a guide line because you can is as stupid as turning a
gut feeling in a guide line wether it's strict and rigid or not.
>> 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.
> No it doesn't.
Odd, how can it work perfectly if it isn't available?
>> unless you want to imply that every Perl program has to be written
>> portable because you can.
> It's a good thing to do - despite what you think. Does it have to be
> done 100% of the time. Obviously not.
It's only a good thing to do when it's a requirement. If it's not then I
prefer to code as I consider it the best. Which means that if I consider
a non-portable piece of code the best I just do it.
Just writing portable code because "It's a good thing" is silly to say
the least.
>> As for your first point: I have a gut feeling
> ...but no data...
Nor have you. Abigail has, but you ignored that. Says a lot.
> While we are talking about programming here we are arguing about
> semantic misunderstandings caused by our usage of English prose here.
> Your misunderstandings, misquotings and the like plainly show this.
I have the feeling that the lead cause of what you consider
"misunderstandings" is that you put your head in your ass a bit too
strong, and now it's stuck. Or maybe it has been stuck there for a
while, it's a bit hard to see the difference without an actual picture.
Uri Guttman
A> || > opendir my $dh => '/some/directory' or die "opendir: $!";
A> || > my @files = grep {!/^\./} readdir $dh;
A> || > closedir $dh;
A> Because glob expands like the csh does. And the csh often does things
A> I don't expect. So I avoid glob. Besides, glob() has changed subtlety
A> between perl versions.
then you should look at file::slurp's read_dir sub. it already
filters out . and .. for you as well. one feature i want to add to is
supporting filters but that is just an internal call to grep which is
not a major win.
uri
--
Uri Guttman ------ u...@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
Joe Smith
> Charlton Wilbur wrote:
>> 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!
You missed the point entirely.
Abigail has been posting to the perl newsgroups (and the perl-porters list)
for several years. We know of Abigail's accomplishments.
> Listen sonny, I've probably worked at far more companies than you
That statement is why we are laughing at you.
Joe Smith
> Tad McClellan wrote:
>> Abigail is a world famous member of the Perl community.
> So what!
>> Who are you?
> You can answer that question yourself.
Yes, you're right about that.
I several people who I respect responding on this thread, and one person
who I don't know but is acting in an insulting manner. From his actions,
I can determine that Andrew DeFarina is someone who should be ignored.
ax...@white-eagle.invalid.uk
> John Bokma wrote:
>> 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.
Really... why do you want to make your posts awkward for others to read?
Axel
Andrew DeFaria
Do you see any example Perl code in there? I see two. One is `cat somefile.txt` and the other is `ls /some/directory`. Those were the examples I was talking about you nimrod! You sir are an intellectually dishonest man and really not worth arguing with.Yet I am convinced you can't resist replying 5 more times ;-). But even with cat and ls: "it depends on what you're doing of course".
--Andrew DeFaria
Bureaucracy: a method of turning energy into solid waste
Abigail
MCMXCIII in <URL:news:x7ps9it...@mail.sysarch.com>:
`' >>>>> "A" == Abigail <abi...@abigail.be> writes:
`'
`' A> || > opendir my $dh => '/some/directory' or die "opendir: $!";
`' A> || > my @files = grep {!/^\./} readdir $dh;
`' A> || > closedir $dh;
`'
`' A> Because glob expands like the csh does. And the csh often does things
`' A> I don't expect. So I avoid glob. Besides, glob() has changed subtlety
`' A> between perl versions.
`'
`' then you should look at file::slurp's read_dir sub. it already
`' filters out . and .. for you as well. one feature i want to add to is
`' supporting filters but that is just an internal call to grep which is
`' not a major win.
But I already have 'ls'. I know 'ls', and I don't know 'File::Slurp'
(I assume it's spelled with capital letters and not in all lowercase).
Abigail
--
perl -le 's[$,][join$,,(split$,,($!=85))[(q[0006143730380126152532042307].
q[41342211132019313505])=~m[..]g]]e and y[yIbp][HJkP] and print'
Martijn Lievaart
> Listen sonny, I've probably worked at far more companies than you,
You're fired very frequently? I'm not surprised.
M4
--
Redundancy is a great way to introduce more single points of failure.
Andrew DeFaria
On Sat, 13 Jan 2007 13:10:33 -0600, Andrew DeFaria wrote:
Listen sonny, I've probably worked at far more companies than you,You're fired very frequently? I'm not surprised.
John Bokma
> Martijn Lievaart wrote:
>> On Sat, 13 Jan 2007 13:10:33 -0600, Andrew DeFaria wrote:
>>
>>> Listen sonny, I've probably worked at far more companies than you,
>> You're fired very frequently? I'm not surprised.
> I've never been fired.
Yup, people just started to ignore you and then you moved on.
Tad McClellan
> I can determine that Andrew DeFarina is someone who should be ignored.
I determined that 30 months ago.
--
Tad McClellan SGML consulting
ta...@augustmail.com Perl programming
Fort Worth, Texas
Tad McClellan
> Andrew DeFaria <And...@DeFaria.com> wrote:
>
>> Martijn Lievaart wrote:
>>> On Sat, 13 Jan 2007 13:10:33 -0600, Andrew DeFaria wrote:
>>>
>>>> Listen sonny, I've probably worked at far more companies than you,
>>> You're fired very frequently? I'm not surprised.
>> I've never been fired.
>
> Yup, people just started to ignore you and then you moved on.
We can only hope that history will repeat itself here.
Andrew DeFaria
John Bokma <jo...@castleamber.com> wrote:
Andrew DeFaria <And...@DeFaria.com> wrote:
Martijn Lievaart wrote:Yup, people just started to ignore you and then you moved on.
On Sat, 13 Jan 2007 13:10:33 -0600, Andrew DeFaria wrote:I've never been fired.
Listen sonny, I've probably worked at far more companies than you,You're fired very frequently? I'm not surprised.
We can only hope that history will repeat itself here.
--
Andrew DeFaria
You know how most packages say "Open here"? What if it said, "Open somewhere else?"
John Bokma
> John Bokma <jo...@castleamber.com> wrote:
>> Andrew DeFaria <And...@DeFaria.com> wrote:
>>
>>> Martijn Lievaart wrote:
>>>> On Sat, 13 Jan 2007 13:10:33 -0600, Andrew DeFaria wrote:
>>>>
>>>>> Listen sonny, I've probably worked at far more companies than you,
>>>> You're fired very frequently? I'm not surprised.
>>> I've never been fired.
>>
>> Yup, people just started to ignore you and then you moved on.
>
> We can only hope that history will repeat itself here.
:-D