Re: Unix commands

Andrew DeFaria (Andrew@xxxxxxxxxxx) wrote on MMMMDCCCLXXXIII September
MCMXCIII in <URL:news:7sCdnV2zsL0xszTYnZ2dnUVZ_oipnZ2d@xxxxxxxxxxx>:
//
// 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 '@}-`-,-`-%-'
.

Relevant Pages

  • Re: Unix commands
    ... ==> writing the program in Perl, ... ==> program that had to be ported to Windows. ... After installing a Unix toolkit the script ... And every other common Unix tool. ...
    (comp.lang.perl.misc)
  • Re: Perl versus other scripting language
    ... I don't see this as a disadvantage. ... but there are more perl modules that don't work at all under ... Windows, or that work badly, or which work with a version of perl but don't ... Unix manpages (a lovely thing if you work under Windows with no ...
    (perl.beginners)
  • Re: How does perl know its environment.
    ... >>It doesn't have paths built into the binary and it doesn't use the ... In Windows, I just let it find the lib ... I don't have Unix, so I don't know if it's true there or not. ... A perl program may get misleading info as to the path of the ...
    (comp.lang.perl.misc)
  • Re: How do Unix grep, find, sort?
    ... "noleander" wrote in message ... > reading the replies above I've settled on Perl. ... > just about any function a Unix relic would need. ... I'm new to Windows, after programming for 20 years in Unix. ...
    (microsoft.public.windows.server.scripting)
  • Re: TPU Section files...
    ... OpenVMS Tools for Windows and UNIX ... Writing a simple TPU Section file that does ...
    (comp.os.vms)