Octal chmod status
Rowan Smith
octal equivilant of rwxrwxr-x etc so that I can do the following.
set perm = 'octalconv <filename>'
is ($perm != 0511) then
etc....
AdvaTHANKSnce.
Boyd Roberts
Eh? Why not just use r-x--x--x?
perm=`ls -ld <filename> | sed 's/^.\(.........\) .*/\1/'`
case "$perm" in
r-x--x--x) # or ?r-x--x--x and change the sed
;;
*)
...
;;
esac
And before anyone says ``he wanted csh solution'' I should state that
a csh solution is no solution.
Boyd Roberts bo...@prl.dec.com
``When the going gets wierd, the weird turn pro...''
Randal L. Schwartz
If you want just the permission bits, try:
bits=`perl -e 'printf "%0o", (stat($ARGV[0]))[2] & 07777' filename`
although I would suggest that this is putting the cart before the
horse, and you'll probably be better off by inverting the problem and
making Perl handle the surrounding code as well. (Without more
context, I cannot tell you how to do that.)
print "Just another Perl hacker," # lurking in comp.unix.shell
--
Randal L. Schwartz / Stonehenge Consulting Services (503)777-0095
mer...@reed.edu (guest account) mer...@ora.com (better for permanent record)
cute quote: "Welcome to Portland, Oregon -- home of the California Raisins!"
Howard Cohen
>In article <17205.22...@kcbbs.gen.nz> Rowan...@kcbbs.gen.nz (Rowan Smith) writes:
> Can somebody please give me a command/method by which I can get the
> octal equivilant of rwxrwxr-x etc so that I can do the following.
>
> set perm = 'octalconv <filename>'
>
> is ($perm != 0511) then
> etc....
Well, here's a brute force method I've used successfully. This can
certainly be done in a smarter way, and it could also be made to understand
things like the sticky bit, the setuid bit, the setgid bit, etc. I didn't
need that stuff though because I knew the files were source code.
------------------------- cut here --------------------------------------
#!/bin/sh
LSPERMS=`ls -l "$1" | sed -e "s:^\([^ ][^ ]*\).*:\1:"`
USR=`echo $LSPERMS X| sed -e "s:.\(...\).*:\1:"`
GRP=`echo $LSPERMS X| sed -e "s:....\(...\).*:\1:"`
OTH=`echo $LSPERMS X| sed -e "s:.......\(...\).*:\1:"`
PERMS=""
for elem in $USR $GRP $OTH
do
case "$elem" in
---) PERMS="${PERMS}0";;
--x) PERMS="${PERMS}1";;
-w-) PERMS="${PERMS}2";;
-wx) PERMS="${PERMS}3";;
r--) PERMS="${PERMS}4";;
r-x) PERMS="${PERMS}5";;
rw-) PERMS="${PERMS}6";;
rwx) PERMS="${PERMS}7";;
esac
done
echo $PERMS
------------------------- cut here --------------------------------------
Howard
-------------------------------------------------------------------------------
Howard "I wood if I could" Cohen
h...@sybase.com {pacbell,pyramid,sun,{uunet,ucbvax}!mtxinu}!sybase!hsc
Sybase, Inc. 6475 Christie Avenue, Emeryville, CA 94608, 510-596-3406
Marc Unangst
> Can somebody please give me a command/method by which I can get the
> octal equivilant of rwxrwxr-x etc so that I can do the following.
>
> set perm = 'octalconv <filename>'
>
> is ($perm != 0511) then
> etc....
Boy, all the solutions that have been offered so far have been pretty
gross. Might I suggest this one?
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <errno.h>
int
main(int argc, char **argv)
{
struct stat statbuf;
if(argc != 2) {
fprintf(stderr, "%s: usage: %s file\n", argv[0], argv[0]);
exit(1);
}
if(stat(argv[1], &statbuf) != 0) {
fprintf(stderr, "%s: can't stat file %s: %s\n", argv[0], argv[1],
strerror(errno));
exit(1);
}
printf("%o\n", statbuf.st_mode & 07777);
exit(0);
}
--
Marc Unangst | Real men don't make backups. Real men never
m...@mudos.ann-arbor.mi.us | accidentally delete files that they're going
| to need later.
David W. Tamkin
| Well, here's a brute force method I've used successfully. This can
| certainly be done in a smarter way, and it could also be made to understand
| things like the sticky bit, the setuid bit, the setgid bit, etc. I didn't
| need that stuff though because I knew the files were source code.
|
| ------------------------- cut here --------------------------------------
|
| #!/bin/sh
|
| LSPERMS=`ls -l "$1" | sed -e "s:^\([^ ][^ ]*\).*:\1:"`
| USR=`echo $LSPERMS X| sed -e "s:.\(...\).*:\1:"`
| GRP=`echo $LSPERMS X| sed -e "s:....\(...\).*:\1:"`
| OTH=`echo $LSPERMS X| sed -e "s:.......\(...\).*:\1:"`
How about this to replace those four lines:
eval `ls -ld "$1" | sed 's/^.\(...\)\(...\)\(...\).*/USR=\1 GRP=\2 OTH=\3/'`
| PERMS=""
| for elem in $USR $GRP $OTH
| do
| case "$elem" in
| ---) PERMS="${PERMS}0";;
| --x) PERMS="${PERMS}1";;
| -w-) PERMS="${PERMS}2";;
| -wx) PERMS="${PERMS}3";;
| r--) PERMS="${PERMS}4";;
| r-x) PERMS="${PERMS}5";;
| rw-) PERMS="${PERMS}6";;
| rwx) PERMS="${PERMS}7";;
| esac
| done
|
| echo $PERMS
The rest is pretty darn clever.
David W. Tamkin Box 59297 Northtown Station, Illinois 60659-0297
dat...@ddsw1.mcs.com CompuServe: 73720,1570 MCI Mail: 426-1818
Tom Christiansen
:Boy, all the solutions that have been offered so far have been pretty
:gross. Might I suggest this one?
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)'
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
"The number of UNIX installations has grown to 10, with more expected."
- _The UNIX Programmer's Manual_, Second Edition, June, 1972.
Marc Unangst
>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...
Tom Christiansen
:>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.
I suspect that you neglected to include the shared libraries
that your a.out would have sucked in.
Notice that you KNOW perl is the right answer here because of
the mystical significance of its program's length.
It took me mere seconds to write the perl solution. It requires
no separate a.out and source code, and can be easily embedded in
a shell script if you want. How long does it take you to write
the C code, compile it for every single architecture on which it
might run, then copy the binary around to every machine you want
to run it on?
% time perl getperms.pl .
0.008u 0.043s 0:00.03 50.0% 0+0k 0+0io 53pf+0w
% time getperms .
0.001u 0.028s 0:00.02 50.0% 0+0k 0+0io 11pf+0w
Sure, the C solution does run faster: one one-hundredth of a second
faster. Big deal. That infinitesimal time difference is surely not
worth all the hassle of writing a C program for each and every little
dohickey you need to whip up that's too inconvenient or inefficient to
use the shell for. If we all did that, we'd have 100 little special
purpose binaries sitting around instead of using sed, awk, or perl,
and carrying our scripts, no longer self-conftained, around to wherever
we needed them would be a major pain.
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
Besides, it's good to force C programmers to use the toolbox occasionally. :-)
--Larry Wall in <1991May31.1...@jpl-devvax.jpl.nasa.gov>
Tom Christiansen
:Tom Christiansen <tch...@convex.COM> responds to Marc Unangst:
:
:>Big deal. That infinitesimal time difference is surely not
:>worth all the hassle of writing a C program for each and every little
:Even though I agree that the perl solution was fine (by being so
:small), but I do not understand the bruhaha about the "hassle" of
:writing a C program for small tasks. It is often much simpler and
:*faster* to write the C code than to implement other solutions. At
:least it is much more *readable* than the aformentioned perl script...
Fine, if you want me to optimize for legibility, I'll do that.
require 'stat.pl';
@sb = stat($ARGV[0]);
printf("%04o\n", $sb[$ST_MODE]);
The bruhaha stems from having to install a hundred binaries on a hundred
systems spanning a dozen different architectures. Programs that aren't
self-contained are a major hassle.
For this reason, I'd much rather see an embedded here-is document used
than an auxiliary data file, and I'd much rather see a solution calling
sed, awk, or perl than one requiring dedicated C programs.
In many cases (of which this is a prime example) by the time you've
written your C program, I'll be long done with the perl version, and will
have probably finished a couple other programs as well.
Putting your interpreted programs in a commonly-mounted directory is a
major win in convenience as well as in disk space.
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
"I sincerely hope that the future does not mean we must continually restrict
ourselves to the tools that were available 10 years ago."
Mark Bush in comp.unix.wizards <42...@inca.comlab.ox.ac.uk>
Tony Porczyk
>Big deal. That infinitesimal time difference is surely not
>worth all the hassle of writing a C program for each and every little
Even though I agree that the perl solution was fine (by being so
small), but I do not understand the bruhaha about the "hassle" of
writing a C program for small tasks. It is often much simpler and
*faster* to write the C code than to implement other solutions. At
least it is much more *readable* than the aformentioned perl script...
t.
Jerry Rocteur
> From the keyboard of m...@mudos.ann-arbor.mi.us (Marc Unangst):
> :In article <1992Aug18....@news.eng.convex.com> tch...@convex.COM (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
> Sure, the C solution does run faster: one one-hundredth of a second
> faster. Big deal. That infinitesimal time difference is surely not
> --tom
Why is this person continually annoying people with information about perl ???
Please excuse my ignorance but is perl a shell ????? is this not
comp.unix.shell ?? I may be wrong but *who* want to be pestered with
perl tidbits ?? I don't, if I did I would join a perl newsgroup ??
I work on Pyramid, SCO, AT&T 3B2, Ultrix, Sun and I have not seen perl
on any of these machines, now these companies may be wrong for not
supplying what seems to be a great product, but it is not on the
popular systems and I subscribe to comp.unix.shell.
If perl *is* a shell, then I apologize, but if perl *is* a shell why
is this person doing 'perl -e .......' ????
Just looking for information......
--
__^__ __^__
( ___ )------------------------------------------------------------( ___ )
| / | Jerry Rocteur Email: je...@InCC.COM | \ |
| / | Independent Computer Consultants Division de DELRA s.p.r.l | \ |
|___| Perwez Belgique Europe |___|
(_____)------------------------------------------------------------(_____)
^ ^
Jerry Rocteur
If Mr Christiansen is not familiar with C then maybe his choice is
something else !!!
You use your skills as best as you can, as long as you know yours and
your tools limitations, but C does not have many :-)
Christopher Davis
Tom> The bruhaha stems from having to install a hundred binaries on a
Tom> hundred systems spanning a dozen different architectures.
Tom> Programs that aren't self-contained are a major hassle.
Think about this one for a moment, folks.
In these days of multivendor distributed environments, it's not uncommon
for your home directory to be mounted on VAXen, ULTRIX-running MIPSel,
IBM RTs and RS6000s, NeXTs, Sun3s, Sun4s, Encore Multimaxen, and HP PAs.
I recognized this fact long ago, and set up my "personal" executables in
a two-pronged form:
binary executables are in ~/bin.ARCH/*, where ARCH is usually handled by
tcsh (which sets $HOSTTYPE). Right now all I have is ~/bin.sun4, since
I stopped cross-mounting to the NeXT, but that's more an accident of
acquisition than anything preplanned.
non-binary executables, primarily perl scripts, are in ~/notbin, since
they're "not binary". :) I can tar this up and haul it over to a new
account without worrying about shared library revisions, binary
compatibility, bytesexual perversions, or the thorny issues of differing
/bin/sh implementations, as long as the other site has perl.
(If it doesn't, bang goes a copy in ~/bin.ARCH until the system admins
can compile it ;-)
If I had an account on, say, MIT Athena, I'd have perl available across
the board, and could keep one, not three, copies of my programs...
--
Christopher Davis * c...@eff.org * System Administrator, EFF * +1 617 864 0665
``Ed Gruberman, you fail to grasp Ti Kwan Leep.
Approach me that you might see.'' -- The Master
Tom Christiansen
:Why is this person continually annoying people with information about perl ???
Like stress, annoyance in internally not externally generated.
I merely offer solutions. If you don't like them, and it upsets
you, then you bring this on yourself.
:Please excuse my ignorance but is perl a shell ????? is this not
:comp.unix.shell ?? I may be wrong but *who* want to be pestered with
:perl tidbits ?? I don't, if I did I would join a perl newsgroup ??
In a shell discussions, you expect to hear solutions suggesting
tools like sed, awk, tr, sort, and their ilk. Perl is just
another one of these, albeit more functional.
I try to propose the right solution, irrespective of its parentage.
Often tasks aren't implementable in sh alone, but since this is a
shell newsgroup, as you've pointed out, I try very hard to avoid
writing the answer in C.
I will excuse your ignorance for this post alone. In penitence,
however, you get to read the perl FAQ, which I shall send in the mail.
You're welcome.
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
"The number of UNIX installations has grown to 10, with more expected."
Tom Christiansen
:> Tom Christiansen <tch...@convex.COM> responds to Marc Unangst:
:>
:> >Big deal. That infinitesimal time difference is surely not
:> >worth all the hassle of writing a C program for each and every little
:>
:> Even though I agree that the perl solution was fine (by being so
:> small), but I do not understand the bruhaha about the "hassle" of
:> writing a C program for small tasks. It is often much simpler and
:> *faster* to write the C code than to implement other solutions. At
:> least it is much more *readable* than the aformentioned perl script...
:>
:> t.
:Does this not depend on your skills ?????
Of course: if you knew nothing but assembly language, then you'd write
code in nothing but that, and I would write hundreds of times more
programs than you, solving hundreds of times more problems. Knowing a
variety of tongues and the constraints of the problem, you can select the
best tool for the task at hand, and go on to write another program.
:If Mr Christiansen is not familiar with C then maybe his choice is
:something else !!!
Please don't vous me -- I hate "Mr.", as it implies a difference of
station I am not comfortable with. My name is Tom. Please use it.
I assure you, Jerry, (ou est-ce que je dois dire "M. Rocteur"?),
that I understand C quite well, which is why I often use perl,
at least when awk will not suffice.
:You use your skills as best as you can, as long as you know yours and
:your tools limitations, but C does not have many :-)
If you believe this, then you are clearly unfamiliar with the C
programming language. There are issues of programmer efficiency and
administrator efficiency that are directly compromised when one elects C
in the face of sh/sed/awk or perl solutions. I've written on this before,
and others have written about this matter in these threads, so I will
not repeat myself, at least for now.
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
Unix is like a toll road on which you have to stop every 50 feet to
pay another nickel. But hey! You only feel 5 cents poorer each time.
--Larry Wall in <1992Aug13.1...@netlabs.com>
Christopher Davis
Jerry> Please excuse my ignorance but is perl a shell ????? is this not
Jerry> comp.unix.shell ?? I may be wrong but *who* want to be pestered
Jerry> with perl tidbits ?? I don't, if I did I would join a perl
Jerry> newsgroup ??
Perl is suitable for many of the tasks that shell scripts (in sh, ksh,
bash, or *blech* t/csh) are often written to solve. It's also usable as
a shell with a little work, but it's not primarily an interactive shell.
(Not that there are that many people I know using the Bourne shell
interactively anymore, if they can help it.)
Jerry> I work on Pyramid, SCO, AT&T 3B2, Ultrix, Sun and I have not
Jerry> seen perl on any of these machines, now these companies may be
Jerry> wrong for not supplying what seems to be a great product, but it
Jerry> is not on the popular systems and I subscribe to
Jerry> comp.unix.shell.
You edit with vi (or ex or ed), I presume. You use sh, or csh if you
have a BSDish vendor. You put up with vendor-supplied mailers. You use
and enjoy NIS for host resolution on a Sun. You don't do any networking
on the 3B2. You use OpenWindows instead of MIT X. You don't plan on
compiling anything on Solaris 2.0.
If any of the preceding are false, what's wrong with perl? It's not
supplied with those systems, well, too bad, TCP/IP isn't supplied with
the 3B2, emacs doesn't come with any of those machines, Sun doesn't ship
MIT X or a resolving libc.so...and you'll never have a C compiler if you
move to Solaris 2.0 :)
Where'd you get your news software? I didn't know it was supplied with
any of those systems...
perl is freely available from archive sites, CD-ROM distributors, and
the like. It *runs* on the popular systems, and even MS-Loss. If we
limited ourselves to what was shipped by the vendor, we'd get that much
less use out of our Unix systems.
Jerry> If perl *is* a shell, then I apologize, but if perl *is* a shell why
Jerry> is this person doing 'perl -e .......' ????
Ever do sh -c .....?
Tom Christiansen
:comp.unix.shell ?? I may be wrong but *who* want to be pestered with
:perl tidbits ?? I don't, if I did I would join a perl newsgroup ??
My, but who would want to be pestered with C tidbits? This is
after all a shell group, so we should allow no solutions requiring
anything but shell built-ins, right? Wrong.
--tom
--
Tom Christiansen tch...@convex.com convex!tchrist
Alan Harder
>From the keyboard of je...@incc.com (Jerry Rocteur):
>:Why is this person continually annoying people with information about perl ???
>Like stress, annoyance in internally not externally generated.
>I merely offer solutions. If you don't like them, and it upsets
>you, then you bring this on yourself.
>:Please excuse my ignorance but is perl a shell ????? is this not
>:comp.unix.shell ?? I may be wrong but *who* want to be pestered with
>:perl tidbits ?? I don't, if I did I would join a perl newsgroup ??
>In a shell discussions, you expect to hear solutions suggesting
>tools like sed, awk, tr, sort, and their ilk. Perl is just
>another one of these, albeit more functional.
>I try to propose the right solution, irrespective of its parentage.
>Often tasks aren't implementable in sh alone, but since this is a
>shell newsgroup, as you've pointed out, I try very hard to avoid
>writing the answer in C.
>I will excuse your ignorance for this post alone. In penitence,
>however, you get to read the perl FAQ, which I shall send in the mail.
>You're welcome.
Maybe this thread belongs on alt.talk.religion. Believe me, many
people out there think we're *all* crazy for working with *unix* boxes.
This problem would obviously be easier to solve in cobol on an AS400
machine ;-).
Christopher Davis
Alan> Maybe this thread belongs on alt.talk.religion. Believe me, many
Alan> people out there think we're *all* crazy for working with *unix*
Alan> boxes. This problem would obviously be easier to solve in cobol
Alan> on an AS400 machine ;-).
On one occasion, before I learned perl, I had to reformat a data file
(turns out the stats program had to have spaces between each number, but
we didn't know that when we entered the data :-). Since it was on an
IBM mainframe, we didn't have perl, I couldn't figure out a quick way to
do it with XEDIT, and I couldn't ftp it to a UNIX account because I
didn't have one then.
So I wrote a COBOL program to read in an 80-character line and copy it
to a 160-character line (with interspersed spaces). It was a brutal,
ugly hack, but it saved a hell of a lot of time.
I'm glad I have perl now :-)
Richard G. Hash
>no separate a.out and source code, and can be easily embedded in
>a shell script if you want. How long does it take you to write
>the C code, compile it for every single architecture on which it
>might run, then copy the binary around to every machine you want
>to run it on?
This tends to ignore how long it takes you to compile and install
perl on every machine you want *it* to run on...
Let's see, I have to worry about sun{3,4}, hp9000s{3,7,8}00, dec3100,
Cray YMP, Ncube, RS6000, Apollo, Amhdahl UTS, VAX (Ultrix), and I'm
sure there's some others I can't recall right now. Yup, use 'em all, all
the time. Gee Tom, if you could just ship me some ready-to-install
perl distributions for ALL those machines I'll being using it tomorrow.
Face it, perl isn't everywhere (though I would like for it to be),
and it's not *always* the answer to everything.
>--
> Tom Christiansen tch...@convex.com convex!tchrist
--
Richard G. Hash
Shell Bellaire Research Center, Houston TX
email: r...@shell.com ph: (713) 245-7311
Bill Duncan
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 (bdu...@ve3ied.UUCP -or- ...robohack!ve3ied!bduncan)
Boyd Roberts
thought of `programming the inputs', eg:
chmod -rwxr-xr-x file
does the same as:
chmod 755 file
It should ignore the leading file type character, ie -pds etc.
Larry Wall
: 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.
Oh, and I suppose that what you're doing can't be classified as an
inconsistent language too? The language Unix is vastly more inconsistent
than the language Perl. And guaranteed to remain that way, forever
and ever, amen.
I freely admit Perl is not pretty. I always have. It's mentioned in
the first paragraph of the man page. But I think your long familiarity
with Unix has blinded you to its ugliness, from which Perl's ugliness
derives (at least in part).
What is the sound of Perl? Is it not the sound of a wall that
people have stopped banging their heads against?
: (It's sorta like sed, but not. It's sorta like awk, but not. etc.)
Guilty as charged. Perl is happily ugly, and happily derivative.
: And it goes against the grain of building small tools.
Innocent, Your Honor. Perl users build small tools all day long.
: 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.
Perl is a durn sight easier to carry around than your typical grab bag
of tools. And you can leave it there, making your clients more productive
in their environment too.
You have to admit that it's difficult to misplace the Perl sources. :-)
: 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".
Certainly. There's always tradeoffs.
: 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!
Certainly. That last is a valid criticism for some machines. I'm
trying to make Perl a little smaller, more appropriate to the task, and
more "universal" all the time. I just chopped the yacc grammar for
Perl down by a third on Monday. Perl will be puttable into a shared
library for architectures that support it. I do what I can, and don't
worry about the rest.
: ...
: 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.
No quarrel with that. But you have to allow a little for the desire to
evangelize when you think you have good news. Now, it's expected when
you evangelize that some seed will fall on the pathway, some on rocky
ground, some among weeds, and some into good soil. Sometimes you put
seed into inappropriate places because, as an evangelist, either you
don't have a very discriminating broadcast medium, or you don't know
offhand whether a place is appropriate or not. Not your responsibility.
Like it says, "He that hath ears, let him hear."
Love,
Larry
Peter Delevoryas
> >:Please excuse my ignorance but is perl a shell ????? is this not
> >:comp.unix.shell ?? I may be wrong but *who* want to be pestered with
> >:perl tidbits ??
I do!! I want all the pestering anyone will post! I'm a dope trying to
learn sysadmin, and believe me, I need all the help I can get.
Hopefully this group is not only for geniuses.
Please don't discourage people from posting scripts, etc.
PD
--
login name: L1-A
In real life: Peter Delevoryas
In any other life: a cheap imitation