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-7308mike@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
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-7308guy@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)