gripes about /bin/sh AND /bin/csh

Dave Cornutt dave at smaug.UUCP
Sat Jun 14 06:20:50 AEST 1986


Relay-Version: version B 2.10.1 6/24/83; site houligan.UUCP
Path: houligan!novavax!ucf-cs!peora!codas!akguc!akgua!gatech!seismo!harvard!husc6!panda!genrad!decvax!bellcore!ulysses!burl!clyde!cbosgd!osu-eddie!karl
From: karl at osu-eddie.UUCP
Newsgroups: net.unix
Subject: Re: Gripes about /bin/sh AND /bin/csh
Message-ID: <1913 at osu-eddie.UUCP>
Date: Fri, 6-Jun-86 09:27:04 EDT
Article-I.D.: osu-eddi.1913
Posted: Fri Jun  6 09:27:04 1986
Date-Received: Fri, 13-Jun-86 10:41:12 EDT
References: <931 at uwvax.UUCP>
Organization: OSU
Lines: 54
Keywords: RTFM.

In article <1913 at osu-eddie.UUCP>, karl at osu-eddie.UUCP writes:

>In article <931 at uwvax.UUCP> pfeiffer at uwvax.UUCP (Phil Pfeiffer) writes:
>>I'm posting this message in reponse to a request from a fellow UW student.
>>This comes from a novice Unix user.  Maybe some other people in the
>>unix community could prove to me that these gripes are really non-gripes.
>
>I suspect so.
>
>>I'm trying to do some extensive rapid prototyping in shellish right now...
>>...First, there's the bit about brain-damaged
>>quoting (or, non-quoting) of metacharacters.
>
>If you don't understand the quoting habits of csh (or sh), you haven't
>read the manual pages on them - the descriptions are really quite
>clear, compared to a lot of UNIX documentation.  Single chars can be
>quoted with a backslash; strings can be single-quoted to prevent any
>further interpretation; and double-quoted to allow filename
>substitution without meta-char substitution.

In csh, variable substitution takes place inside double-quoted string ALWAYS,
even if the $ sign is backslashed.

>
>>I'm sure a lot of you already
>>know that the ability to use backquote to expand certain command strings
>>just isn't there.
>
>Yes, it is; backquoted command strings are supported by both sh and csh.
>If it weren't, I couldn't issue a command like
>	ls -l `find . -size +100 -print`
>Read the manual.

What the manual doesn't tell you is that backquoting doesn't work with some
built-in csh commands (at least not in our version).  For example, I wrote
a program called "mkumask" that you could give a string like "rw-rw-r--", and
it would print out the value to set the umask to to get those default
permissions on newly-created files.  I figured I could do a command like
this:
	umask `mkumask rw-rw-r--`
and it would set my umask for me.  Guess what?  It chokes.  But if I do it
like this:
	$foo = `mkumask rw-rw-r--`
	umask $foo
it works.  Apparently there is a problem expanding backquotes in some built-
in commands.  Which commands are built-ins?  You have to wade through the
lengthly manual section for csh to find out.  (And they're not all listed
in the same place.)

>
>>'Twould be useful if one could abbreviate commands as
>>variables to make one's code more legible, a la lisp.
>
>Aliasing is supported by csh.  Sh does it with plain variables.  Read
>the manual.

True enough.  Phil: you can create a command alias by doing something like
this:
	alias <name> <command>
For example, if you're used to VMS and you constantly type "rename" in-
stead of "mv", you can do this in your .cshrc:
	alias rename mv
and every time you type "rename" as a command name, csh will translate
that to "mv".  If you type "alias" without any arguments, it will list
your current aliases.  If you want to kill an alias, type "unalias <name>",
and the alias called "name" (if there is one) will no longer be in effect.

>
>>That's irritating.  What's really irritating, however, is the inability to
>>open and read multiple files from the shell.  I mean, even RSX-11M's CSI has
>>this!
>
>Sourcing of other command files is supported by both csh and sh.  Read
>the manual.

That isn't what he meant.  What Phil wants (me too) is some capability
to open a file in a sh/csh script and read a line at a time into a
variable, like this:
	open <some-file> xyz
	while ( ! eof(xyz) )
		read xyz $line_from_file
		<...do stuff with data...>
	end
	close xyz
Neither sh nor has any such capability.  (Ksh might, but I don't have access
to that beast.)  Note that this isn't the same as $data = `cat <some-file>`;
it's difficult to get the individual lines, csh insists on parsing it up
into words, and if the file is large, you run out of memory.  There are
klugey ways of getting around this, but why put up with a kluge?  Bourne
and C shells need some sane way to open and read/write files in a script.

>
>>The requirement was as follows: ...
>
>After reading what you say you wanted to do (sketchy though it was),
>it seems to me you worked at it far too hard.  You're not familiar
>with the tools available to you.  RTFM and make sure you know how
>sharp your tools are before you pick them up, or you'll find yourself
>with cut fingers.
>
>In case you haven't notice the recurring refrain in all of the above
>response, it is this:
>
>	Read the manual.
>-- 
>Karl Kleinpaste

Yeah, and we all know how much fun it is reading that FM when you don't
really know what's going on, and all you get when you ask for help is
"why don't you go away and read this nice manual and leave me alone?"
Nearly everyone is aware that the UN*X manuals are hopeless when used as
tutorials, so in lieu of the existience of a suitable training manual,
we just have to pass on our accumulated, hard-earned knowledge person-to-
person.  We all know that there are jerks that post stuff to the net
just so they can find someone to do their work for them, but this doesn't
sound like one of those cases.  Lighten up, the guy's trying to learn.

Dave Cornutt
Gould Computer Systems 
Ft. Lauderdale, FL

"The opinions expressed herein are not necessarily those of my employer,
not necessarily mine, and probably not necessary."



More information about the Comp.unix mailing list