NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/unix/shell/3605

Text File | 1992-08-25 | 4.9 KB | 109 lines

Newsgroups: comp.unix.shell
Path: sparky!uunet!uunet.ca!canrem!telly!robohack!ve3ied!bduncan
From: [e-mail] (Bill Duncan)
Subject: Re: Octal chmod status
Organization: TFMCS
Date: Tue, 25 Aug 1992 04:25:22 GMT
Message-ID: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Lines: 98

In article <[e-mail]> [e-mail] (Tom Christiansen) writes:
>From the keyboard of [e-mail] (Marc Unangst):
>:In article <[e-mail]> [e-mail] (Tom Christiansen) writes:
>:>You might, and people might even use it if they want to lug
>:>another huge a.out and overly large and misplaceable foo.c
>:>around with them wherever they go.  I'd just use this:
>:>
>:>    perl -e 'printf("%04o\n", (stat($ARGV[0]))[2] & 07777)'
>:
>:Hmm.  Huge a.out, huh?  Overly large foo.c, huh?  Hmm.
>:
>:mju@mudos:~$ ls -l getperms getperms.c
>:-rwxr-xr-x   1 mju      group       4780 Aug 19 01:06 getperms
>:-rw-r--r--   1 mju      group        445 Aug 15 01:08 getperms.c
>:mju@mudos:~$ cd /usr/local/bin
>:mju@mudos:/usr/local/bin$ ls -l perl*
>:lrwxrwxrwx   1 root     other          9 Aug 19 01:07 perl -> perl4.019
>:-rwxr-xr-x   1 bin      bin       283992 Aug 19 01:06 perl4.019
>:mju@mudos:/usr/local/bin$ cd ../src
>:mju@mudos:/usr/local/src$ ls -l perl-4.019.tar.Z
>:-rw-r--r--   1 mju      mju       801616 Aug 10 13:04 perl-4.019.tar.Z
>:mju@mudos:/usr/local/src$ exit
>:
>:Sure looks like my program is smaller.  Could just be an optical
>:illusion, though...
>
>It is.  You're confused.
>
>    % ls -l getperms*
>      60 -rwxr-xr-x  1 tchrist     60785 Aug 19 07:48 getperms
>       2 -rw-r--r--  1 tchrist       452 Aug 19 07:48 getperms.c
>       2 -rw-r--r--  1 tchrist        42 Aug 19 07:49 getperms.pl
>
>You may only include the size of the perl compiler if you
>include the size of the C compiler.  You may only include
>the size of the perl libraries if you include the size of
>the perl libraries.
>
> etc...

As long as you're making up the rules like this, then multiply it out
by the number of times each part will be used.  The C compiler etc. get
used once to produce the binary, and I agree that if you write throwaway
code, the perl one-liner might come out ahead.

If it's something that will be used over and over however, be nice to your
neighbors (if it's multi-user), and use the resources appropriately.  No need
to suck perl in every time you need permissions of a file, or to center a line
of text, unless you only need it once of course.

As I said in an earlier discussion involving centering a line of text, this
is "deja vu".  It sounds alot like the APL zealots who though everything
should be done in their pet language, instead of stepping back and looking
at things a bit more objectively.  In fact I'm sure alot of these types
of jobs, an old APL hack might do in a "fractional line of code"!  Would
you switch to APL on that basis?

I will use awk, sed, sh, m4, C, and whatever other tools are available to
get a job done as expiditiosly as possible, while leaving a client with
something that can be maintained.

My problem with perl stems from 2 things.
    a) Philosophically, it's ugly.  It tries to do too many things in one
       place.  Thus, it's borrowed from many of the simpler unix tools,
       but tried to stuff it all in one with an inconsistent language.
       (It's sorta like sed, but not.  It's sorta like awk, but not. etc.)
       And it goes against the grain of building small tools.

    b) On a more practical front, I don't like to carry all the perl
       sources to every new client before I can become "productive" in
       their environment.

I've seen you mention other scripting languages Tom, but I've only seen
any of your perls...  I agree that not everything should be done in "C".
You also need to weigh how often it will be used, and how fast is "fast
enough".

But how about something a little smaller, more appropriate for the task,
and more "universal".  I don't know what you're running on, but it would
take alot longer than those times to suck in half a meg on my machine,
just to get perms on a file!

It seems to me, that we may be talking different problem sets too.  You
Tom, may need to support a dozen different architectures on a network.
And each client may only have one user, so the performance issue wouldn't
apply.  In that case, your time is more valuable, and the one-liner is
more justifiable.

Many other people (myself included), work with single architecture machines
where there may be many users.  So your argument about "all the binaries..."
doesn't apply, but performance issues do.

You can't look at problems in isolation without further context before
deciding what is or is not appropriate.  Unfortunatly, far too many
programmers do.

Bill Duncan ([e-mail] -or- ...robohack!ve3ied!bduncan)