pfeiffer@uwvax.UUCP (Phil Pfeiffer) (06/04/86)
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'm trying to do some extensive rapid prototyping in shellish right now, and
I'm having a hard time saying what I want I want to in shell script.
I never thought I'd say this, but I actually *miss* the DEC standard
11-series command interpreters! First, there's the bit about brain-damaged
quoting (or, non-quoting) of metacharacters. I'm sure a lot of you already
know that the ability to use backquote to expand certain command strings
just isn't there. 'Twould be useful if one could abbreviate commands as
variables to make one's code more legible, a la lisp.
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! I received one response locally that, if this is what I want to do,
then I ought to write a C-program. But I don't *want* to write a c-program
just now -- I just want to prototype something that will work and can be
easily changed. Also, this utility may never need to be cast in C, anyway,
since it doesn't have to work quickly.
The requirement was as follows:
generate several command files to apply a certain sequence of commands
(a template, as it were) to each element in a series of lines in another
file. The templates also had to include expanded shell variables
(names of temp files, actually), which ruled out easy use of "awk".
I finally wound up creating, on the fly, a command file to expand templates.
The templates were then used as command files to create the body of the
command file that I really wanted (which will end up being exported to another
host, and executed using rsh).
Somehow, it just doesn't seem right that command files to create command files
to generate command files should be the clearest way of doing things.
--
-- Phil Pfeiffer
...!{harvard,ihnp4,seismo,topaz}!uwvax!pfeiffer
(608) 263-7308karl@osu-eddie.UUCP (Karl Kleinpaste) (06/06/86)
In article <931@uwvax.UUCP> pfeiffer@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. >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. >'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. >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. >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
dan@prairie.UUCP (Daniel M. Frank) (06/07/86)
>In case you haven't notice the recurring refrain in all of the above >response, it is this: > > Read the manual. >-- >Karl Kleinpaste I was one of the people who first tried to deal with Phil's problem here, and the one who encouraged him to post some of his questions to the net. I'm not particularly pleased by an arrogant response like this. The fact is, that Phil read the manual, and I read the manual, and neither of us could find, either in the manual or by experiment, solutions to some of the questions for which you only have your smug refrain. Perhaps we're just another couple stupid PhD students, but the manual wasn't a lot of help in this case. Unix manuals often leave out important information on the theory that you can read the source, so what do you need a manual for? We posted to usenet in order to draw on some experience that we presume is out there. If you are so smart, and you have all the solutions at your fingertips, why don't you share them instead of demon- strating how superior you are (do you really know the solutions? We can't tell, can we?)? -- Dan Frank ... uwvax!geowhiz!netzer!prairie!dan -or- dan@caseus.wisc.edu
tim@ora.UUCP (Tim O'Reilly) (06/08/86)
In article <143@prairie.UUCP>, dan@prairie.UUCP (Daniel M. Frank) writes: > >In case you haven't notice the recurring refrain in all of the above > >response, it is this: > > > > Read the manual. > >-- > >Karl Kleinpaste > > I'm not particularly pleased by an arrogant response like this. > The fact is, that Phil read the manual, and I read the manual, and neither > of us could find, either in the manual or by experiment, solutions to > some of the questions for which you only have your smug refrain. > > Dan Frank > ... uwvax!geowhiz!netzer!prairie!dan > -or- dan@caseus.wisc.edu I agree that the response wasn't the kindest. But it did match the agressive tone of the original posting, which basically implied that UNIX is brain-damaged, and "why the hell should I be using this stupid OS?" If the original posting had in fact been the kind of simple request for help that you claim it was, I am sure it would have received a more acceptable response.
mike@whuxl.UUCP (BALDWIN) (06/09/86)
> First, there's the bit about brain-damaged >quoting (or, non-quoting) of metacharacters. I don't know what you're getting at here. > I'm sure a lot of you already >know that the ability to use backquote to expand certain command strings >just isn't there. SVR2 /bin/sh does this right. Pre-SVR2 had problems with the output of builtin commands (set, export, etc). You couldn't redirect them or put them in back-quotes the ordinary way. > 'Twould be useful if one could abbreviate commands as >variables to make one's code more legible, a la lisp. With SVR2 /bin/sh you just set up a shell function: foo() { command I want to run; } and say foo Pre-SVR2 you can set up a shell var: foo='command I want to run' and say eval $foo > What's really irritating, however, is the inability to >open and read multiple files from the shell. You must've missed the sections on redirection and "exec" in /bin/sh. The Bourne shell has always handled this rather cleanly! To open 3 files (as fd's 3 4 5) and read/write stuff to them: exec 3<files 4<data 5>output # open files while read file <&3 # read from fd3 do x=`line <&4` # read from fd4 (echo $file: $x $x) >&5 # write to fd5 done exec 3<&- 4<&- 5>&- # close files The C shell doesn't deal with file descriptors at all. Try to get an SVR2 /bin/sh; I think it's the best of the standard shells. -- Michael Baldwin (not the opinions of) AT&T Bell Laboratories {at&t}!whuxl!mike
karl@osu-eddie.UUCP (Karl Kleinpaste) (06/09/86)
In article <143@prairie.UUCP> dan@prairie.UUCP (Daniel M. Frank) writes: >> Read the manual. >>Karl Kleinpaste > > I was one of the people who first tried to deal with Phil's problem >here, and the one who encouraged him to post some of his questions to >the net. I'm not particularly pleased by an arrogant response like this. >The fact is, that Phil read the manual, and I read the manual, and neither >of us could find, either in the manual or by experiment, solutions to >some of the questions for which you only have your smug refrain. *Sigh.* I'm sorry if my response appeared to be arrogant. That was not its intent. It was, however, intended to show that a great many questios of the sort frequently posted to the network can be answered without resorting to the Usenet. > Perhaps we're just another couple stupid PhD students, but the manual >wasn't a lot of help in this case. Unix manuals often leave out important >information on the theory that you can read the source, so what do you >need a manual for? We posted to usenet in order to draw on some experience >that we presume is out there. If you are so smart, and you have all the >solutions at your fingertips, why don't you share them instead of demon- >strating how superior you are (do you really know the solutions? We >can't tell, can we?)? Oh, baloney. Stop making foolish insinuations. From what I recall of the original article, here are my references from csh(1) on what was confusing the original poster. Quotation habits: page 4 of csh(1), under the heading Quotations with ' and ". Aliases: also page 4 of csh(1), under the heading Alias Substitution. Command substitution: page 6 of csh(1), under the heading Command Substitution. Reading other command files: page 14 of csh(1), under the alphabetical listing of Builtin Commands. The command in question is `source.' Note that your page numbers might vary by one or two, depending on what formatting habits your printers have. I don't recall anything else just now, and I haven't got the original article in front of me just now. Yes, it was in the manual. All of it, as nearly as I could see. I won't attempt to answer the final full-blown question because what was provided was too sketchy to do anything in detail without a great deal more info from the original person. So my original `refrain' stands: Read the manual. All of your questions posted to the network were answered right there. I honestly don't know why you couldn't find it yourself in the first place. -- Karl Kleinpaste
pfeiffer@uwvax.UUCP (Phil Pfeiffer) (06/09/86)
Since the first posting, people have explained to me that I was both right and
wrong: right about /bin/csh's metasyntax and file I/O shortcomings, but wrong
about what /bin/sh could and could not do. I apologize for not studying the
/bin/sh manual more thoroughly the first time; I might have been quicker
to do this if I hadn't been operating under the misguided assumption that
operating systems don't support multiple incompable command languages, and
hadn't spent so much time on the csh man page and the Joy document.
Many thanks to the people who took time to respond to my query. The posted
/bin/sh examples for file redirect certainly helped. A lot of problems, like
creating command files to create command files to create command files, went
away when I gritted my teeth and decided to use both /bin/csh and /bin/sh for
my project. I still have some direct responses to my posting to digest, which
also look promising, particularly with regard to metacharacter syntax. Some
of this information deserves to be more than just oral tradition; I'm not
familiar enough with the USENIX community to know whether someone has compiled
some of these idioms into a document.
I have given up on creating "executable variables" in a form acceptable to both
rsh AND csh. This all started when I tried to prefix commands with a string
named "rsh_prefix" which would evaluate to null or "rsh hostname -l username",
depending on the environment; I had enough problems trying to quote metachars
and avoid the use of temp files that I gave up and rsh'ed everything, including
local commands. Any advice that people have on this score would also be
appreciated.
--
-- Phil Pfeiffer
...!{harvard,ihnp4,seismo,topaz}!uwvax!pfeiffer
(608) 263-7308karl@osu-eddie.UUCP (Karl Kleinpaste) (06/09/86)
In article <107@ora.UUCP> tim@ora.UUCP (Tim O'Reilly) writes: >I agree that the response wasn't the kindest. But it did match the >agressive tone of the original posting, which basically implied that >UNIX is brain-damaged, and "why the hell should I be using this stupid >OS?" That was largely why my response gained its (unintentional) character of supposed arrogance. >If the original posting had in fact been the kind of simple request >for help that you claim it was, I am sure it would have received a >more acceptable response. Exactly. It was particularly offensive to me in that it contained patently false assertions, with, uh, commentary to go with it. Uppermost in my mind in this area was the claim that command substitutions using backquotes "just isn't there," followed by the additional complaint that it would be nice to have shorthand mechanisms available, when in fact they already exist in both csh and sh (by aliases and variables, respectively). If you need help, then ask for *help*; don't criticize before you know what the @#$% you're dealing with. It is obvious that the original poster did not. -- Karl Kleinpaste
levy@ttrdc.UUCP (Daniel R. Levy) (06/10/86)
In article <1924@osu-eddie.UUCP>, karl@osu-eddie.UUCP (Karl Kleinpaste) writes: [Way too many words] Mr. 'paste, you have filled the net with far more bytes than your flamee did. You should have flamed the poor guy by private mail if at all. I mailed him some examples and he was quite grateful. -- ------------------------------- Disclaimer: The views contained herein are | dan levy | yvel nad | my own and are not at all those of my em- | an engihacker @ | ployer or the administrator of any computer | at&t computer systems division | upon which I may hack. | skokie, illinois | -------------------------------- Path: ..!{akgua,homxb,ihnp4,ltuxa,mvuxa, vax135}!ttrdc!levy
guy@sun.uucp (Guy Harris) (06/10/86)
> ...if I hadn't been operating under the misguided assumption that operating > systems don't support multiple incompable command languages... You've obviously never used VMS, which supports DCL and the old RSX-11 MCR.... Operating systems like UNIX, which blessedly have command processors which are ordinary user programs, and let a user specify what program is to be the first program started for their login session, can support as many command languages as you want. ("csh" is a Berkeley addition, so you can argue whether UNIX supports it as a standard command language or not.) > Some of this information deserves to be more than just oral tradition; I'm > not familiar enough with the USENIX community to know whether someone has > compiled some of these idioms into a document. Unfortunately, I doubt that anybody has. The existence of Michael Baldwin's trick of using null "exec" commands to open and close file descriptors within the shell is implied by a comment buried in the manual - it says under the "exec" command that "...if no other arguments are given, (it causes) the shell input/output to be modified." No Advanced Shell Programming tutorial comes with the UNIX documentation, and that would be the place to discuss redirection of other file descriptors, this trick, etc.. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
rab@smu (06/12/86)
in defense of karl, i deal with users who daily come up with brainless questions. having a phd or being in the process of getting one has NOTHING to do with one's level of common sense, or should we say, uncommon sense. 90% of all questions asked by graduate students in my area could be answered by reading the manual. i am glad that someone FINALLY made a point of this -- in public. if the person had enough nerve to ask something like that in public, then they deserve to be answered in public. i understand that phil may have had trouble reading through several pages of information on each shell, but the shells do a lot -- and it IS covered. i have nothing against providing information, but there is a proper way to request it. as well, the tone of the original note came across as a DECite who was exposed to this "horrible" os named UNIX. i was about as incensed as karl when i read the note to begin with. i am tired of persons who know little if anything about UNIX abusing it and berating its abilities without substantiation. i suppose it's no small wonder that UNIX has been around for almosst 20 years and is still the premier os on earth? rick barrett convex!smu!rab
dave@smaug.UUCP (Dave Cornutt) (06/13/86)
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@osu-eddie.UUCP Newsgroups: net.unix Subject: Re: Gripes about /bin/sh AND /bin/csh Message-ID: <1913@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@uwvax.UUCP> Organization: OSU Lines: 54 Keywords: RTFM. In article <1913@osu-eddie.UUCP>, karl@osu-eddie.UUCP writes: >In article <931@uwvax.UUCP> pfeiffer@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."
chris@umcp-cs.UUCP (06/16/86)
In article <44@houligan.UUCP> dave@smaug.UUCP (Dave Cornutt) writes: >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. I assume you mean `neither sh nor csh'. Well, you can fake it in csh, but it is easy to do in sh: while read x; do echo "input line: $x" done < file If you need to read stdin as well it gets harder; and it becomes much harder if you want the loop to affect a shell variable that can be tested outside the loop, for the loop is run in a fork. However, if all else fails you can always write a temporary script and source it: # set these based on SysV/BSD flavour # as Larry Wall has demonstrated, this can even be done dynamically # n=; c=\\c # SysV n=-n; c= # BSD tf=/tmp/ugly.$$; rm -f $tf; trap 'rm -f $tf' 0 1 2 3 15 while read line; do case "$line" in ... something_fancy) flag=true # set the flag echo "flag=true" >$tf;; # and record it another_fancy_thing) echo $n "foo? " $c # ask a question # Getting the answer is harder, for `read' will not accept # redirection. The simplest solution is a program that reads # one line from stdin and echoes it: # answer="`gets 0<&3`" # and read stdin for answer # Unfortunately, `gets' is gone in 4.3. `head -1' works; but # the following should even be portable: answer=`sh -c "read input; echo \"\\\$input\"" 0<&3` case "$answer" in y|yes|indeed|sure|ok|yup|fine) # add others as desired echo "can run commands too" >$tf;; esac;; ... esac done 3<&0 <file # now regain any effects lost after the loop, and do other tricks . $tf For completeness, the line that reads stdin should run the output through `tr' to translate to lowercase (or the case below that should list all, er, cases: rather tedious). I left that one out because SysV changed `tr' to be incompatible with V7 derivatives, and more of the magic `compatiblisation' code like the `echo' command just seemed to me to be overkill. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
cycy@isl1.ri.cmu.edu (Christopher Young) (06/17/86)
Personally, I agree with Karl; read the manual. Also, there exist fairly
good tutorials which cover a reasonable amount of material on various subjects
related to UNIX. "In Introduction to the UNIX Shell", by S.R. Bourne, while
old (1978), isn't a bad place to begin. It is part of the standard
documentation set.
But what I think really ticked off Karl, and what got to me, was the tone of
Phillip's initial query. He know's nothing about UNIX, nothing about either of
the two shells he was concerned about, and yet he went off on a rampage about
illusory inadequacies on them. It struck me as rather insulting. I was
a UNIX consultant at the computer center of my old university for three years,
and I always hated having to deal with people who approached me like that. I
didn't like it inperson, and I certainly don't think it's very nice on the net
too. I understand Phillip's note was probably born of frustration, but still...
-- Chris Young.
arpa: cycy@cmu-ri-isl1
uucp: {...![arpa/uucp gateway (eg. ucbvax)]}!cycy@cmu-ri-isl1gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/17/86)
In article <44@houligan.UUCP> dave@smaug.UUCP (Dave Cornutt) writes:
-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.
while line_from_file=`line`
do ... do stuff with $line_from_file ...
done < some-filedricej@drilex.UUCP (Craig Jackson) (06/18/86)
I think that the point of Phil's original article has been lost: there exist
other operating systems, with other command languages, which can do certain
common things in a more straitforward way than either /bin/sh or /bin/csh.
I think the reading from more than one file at once is a good example; I
hadn't thought of the solution using multiple descriptors; and I've rtFm many,
many times. In fact, I rtFm for /bin/sh every time I write more than a
two-line routine. As for /bin/csh, I've never been able to spare the mental
space to remember them both at once.
To reiterate my heresy: there are nicer command languages than the Unix shells.
(REXX is a nice one, even though it does come from Satan.:-))
--
Craig Jackson
UUCP: {harvard,linus}!axiom!drilex!dricej
BIX: cjackson