Re: Unix commands

Andrew DeFaria (Andrew@xxxxxxxxxxx) wrote on MMMMDCCCLXXXIII September
MCMXCIII in <URL:news:8uqdnYpYjoZalDTYnZ2dnUVZ_vCknZ2d@xxxxxxxxxxx>:
== 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}
.