fmbutt@cloud9.Stratus.COM (Farooq Butt) (10/31/89)
Dear Unix Wizards/question-answerers:
here is code fragment from the 4.3 BSD Tahoe distribution of UNIX.
It is from a program called "uux" from the uucp suite.
Uux is supposed to take '-' as an argument where saying:
"uux -"
means "take input from stdin." But to my shock and horror,
when I compiled uux and gave it the "-" argument it refused to
recognize it and did not take input from stdin. Since "uux -p"
here means the exact same thing as "uux -" I satisfied myself
to use it without reasoning why. However lately, I've had the chance
to look at the code again and it seems that what the guys who wrote
4.3 Tahoe UUCP must not have been using the same "getopt" routine I
am on a Sun. The code fragment in question is here:
while ((c = getopt(argc, argv, "-prclCg:x:nzLa:")) != EOF)
switch (c) {
case '-':
/* FALLTHROUGH */
case 'p':
pipein = 1;
break;
case 'r':
startjob = 0;
break;
case 'c':
Copy = 0;
Linkit = 0;
break;
...... and more code unrelated to getopt......
Questions:
. Should that code above work in principle given a "standard"
getopt routine ?
. Does getopt have its roots in BSD or SysV ?
. Is the SunOS getopt (the one I am using) buggy and simply
not dealing with a lone "-" ?
. How would one get getopt to deal with single dash options ?
(I want to say cat FOO | uux - -r 'jkfghkjhgfdkjh' )
^
|
This '-' is the arg getopt
does not like
Thanks for the help !!!
--
NOTHING in the above article has the slightest relationship to reality.
If any reality correspondences are found, please notify me IMMEDIATELY.
Any threats, abuse or stupidity of any kind are purely UNINTENTIONAL.
My employer does not know that I exist and is not responsible for anything.exspes@gdr.bath.ac.uk (P E Smee) (11/16/89)
In article <1989Nov7.000009.23547@virtech.uucp> cpcahil@virtech.uucp (Conor P. Cahill) writes: >In article <1989Nov3.110330.27751@gdt.bath.ac.uk>, exspes@gdr.bath.ac.uk (P E Smee) writes: >> In article <11456@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >> >-As for the religious point of view, dashes should just go away and be >> >-replaced by entries in the file system such as "/dev/stdin". >> >> Urk! Would you *really* rather have to type "/dev/stdin" rather than >> simply "-"? >> Instead, how about an extension to general >> filename expansion to say that the token "-" *always* means stdin... > >Using /dev/stdin falls in line with the standard unix way of referenceing >special files (like /dev/tty, /dev/mem...). >Your solution for re-mapping the "-" will only work >for programs started by the shell... Yeah, I know all about /dev/*, and don't have any trouble with the idea of /dev/stdin *existing*. However, I *don't* want to have to type it. My concern is really only with shell command lines, because they are the only things I have to type in (more than once :-). I see no problem with simultaneously having a /dev/stdin AND a simple-to-type thingie which the shell expands to mean 'stdin' in whatever guise it likes. Much the same as I see no problem with having a bunch of files in my homedir, and an easy-to-type ~/* to refer to them when I'm talking thru the shell. Of course there are problems with '-', since some things already give it other custom meanings (tar comes to mind) but there must be some one or two char string going spare. Maybe ~~ or $~ or something. -- Paul Smee | JANET: Smee@uk.ac.bristol Computer Centre | BITNET: Smee%uk.ac.bristol@ukacrl.bitnet University of Bristol | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk (Phone: +44 272 303132) | UUCP: ...!uunet!ukc!gdr.bath.ac.uk!exspes
roy@phri.UUCP (Roy Smith) (11/17/89)
In <1989Nov15.183752.19153@gdt.bath.ac.uk> exspes@gdr.bath.ac.uk (P E Smee): > Yeah, I know all about /dev/*, and don't have any trouble with the idea > of /dev/stdin *existing*. However, I *don't* want to have to type it. > [...] there must be some one or two char string going spare. Why not just make a symbolic link from /- to /dev/stdin? Then you can have your two character string and the rest of us don't get our kernels and/or standard libraries cluttered up with stuff we don't want. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {att,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
peter@ficc.uu.net (Peter da Silva) (11/18/89)
a Syntactical Brainstorm: What syntax should the shell use for /dev/stdin? You can't use -, other programs already use it for other things. Well, what syntax does the shell (bourne shell) use for file descriptors? command file # file is an argument to command command > file # file is a place to redirect stdout command 2> file # file is a place to redirect stderr command 2>&1 # stdout is a place to redirect stderr Aha! command &1 # stdout is an argument to command. So: command &n gets expanded to /dev/fd/n...? -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.hackercorp.com>. 'U` -------------- +1 713 274 5180. "vi is bad because it didn't work after I put jelly in my keyboard." -- Jeffrey W Percival (jwp@larry.sal.wisc.edu)
ag@amix.commodore.com (Keith Gabryelski) (11/19/89)
In article <7043@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >What syntax should the shell use for /dev/stdin? > command &1 # stdout is an argument to command. '&' in the shell is an actual separator of commands, that is: command1 & command2 will execute command1 in the background then command2 (in the foreground). command >&1 does not break '&' normal use because it is used in the twople '>&' that is, no white space can be used between the '>' and the '&', thus no ambiguity. I doubt the general usefullness of having the shell expand any sequence of symbols to '/dev/stdin' (except in globbing: /dev/stdi* :-). This seems like a job for programable function keys or possibly a typing tutor :-). Pax, Keith -- ag@amix.commodore.com Keith Gabryelski ...!cbmvax!amix!ag
exspes@gdr.bath.ac.uk (P E Smee) (11/19/89)
In article <4127@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > > Why not just make a symbolic link from /- to /dev/stdin? Then you >can have your two character string and the rest of us don't get our kernels >and/or standard libraries cluttered up with stuff we don't want. Well, probably because on most of the Unixes I use, I don't get to put things into /. On the other hand, suppose I could always put it at ~/-. Or make myself a single character setenv var... -- Paul Smee | JANET: Smee@uk.ac.bristol Computer Centre | BITNET: Smee%uk.ac.bristol@ukacrl.bitnet University of Bristol | Internet: Smee%uk.ac.bristol@nsfnet-relay.ac.uk (Phone: +44 272 303132) | UUCP: ...!uunet!ukc!gdr.bath.ac.uk!exspes
peter@ficc.uu.net (Peter da Silva) (11/22/89)
> In article <7043@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: > >What syntax should the shell use for /dev/stdin? > > command &1 # stdout is an argument to command. > '&' in the shell is an actual separator of commands, that is: Yes, I know. So? > command >&1 (and command && command) > does not break '&' normal use because it is used in the twople '>&' So &1 would be a similar dipthong, with no white space allowed. It's no greater a syntax problem than the distinction between !cmd 2 > file! and !cmd 2> file!. > I doubt the general usefullness of having the shell expand any sequence of > symbols to '/dev/stdin' (except in globbing: /dev/stdi* :-). And how about in variable expansion, command line substitution, and shell functions? -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "I agree 0bNNNNN would have been nice, however, and I sure wish X3J11 had taken time off from rabbinical hairsplitting to add it." -- Tom Neff <tneff@bfmny0>
ag@amix.commodore.com (Keith Gabryelski) (11/23/89)
>> command >&1 >(and command && command) > >> does not break '&' normal use because it is used in the twople '>&' > >So &1 would be a similar dipthong, with no white space allowed. but command1&command2 is currently valid syntax in the bourne shell. Should we break this because some people can't put S=/dev/stdin;export S in their .profile? -- ag@amix.commodore.com Keith Gabryelski ...!cbmvax!amix!ag
peter@ficc.uu.net (Peter da Silva) (11/28/89)
[ I suggested &n refer to /dev/fd/n ] > command1&command2 > is currently valid syntax in the bourne shell. And it'd remain so. You might have problems if you have a program called '1', '2', and so on. That's pretty unlikely. -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM
exspes@gdr.bath.ac.uk (P E Smee) (11/29/89)
In article <7118@ficc.uu.net> peter@ficc.uu.net (Peter da Silva) writes: >And it'd remain so. You might have problems if you have a program called >'1', '2', and so on. That's pretty unlikely. Actually, Brian Kernighan and Rob Pike suggest such a program (shell script) in 'The Unix Programming Environment'. Basically, it invokes print with an argument of -$0 -- that is, if invoked as '2' it filters its stdin into 2 columns, if invoked as '3' into 3 columns, ... To 'implement' a new number of columns you just add another link to the script. Doesn't half pollute your ~/lib namespace ... -- Paul Smee, Univ. of Bristol Comp. Centre, Bristol BS8 1TW (Tel +44 272 303132) Smee@bristol.ac.uk :-) (..!uunet!ukc!gdr.bath.ac.uk!exspes if you HAVE to)
dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) (12/01/89)
In article <118@amix.commodore.com> ag@amix.commodore.com (Keith Gabryelski) writes: >Should we break this >because some people can't put > > S=/dev/stdin;export S > >in their .profile? Some of you are being rather presumptuous when discussing the topic of /dev/stdin vs "-". The existence of getopt allows C programs to accept arguments in a consistent way across many OSes, not just UNIX. The idea of "use standard input here" is also portable across many OSes. The idea of using "-" to mean "standard input" is also portable across many OSes. The idea of /dev/stdin is NOT. Rahul Dhesi <dhesi%cirrusl@oliveb.ATC.olivetti.com> UUCP: oliveb!cirrusl!dhesi
peter@ficc.uu.net (Peter da Silva) (12/02/89)
In article <1143@cirrusl.UUCP> dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes: > The existence of getopt allows C programs to accept arguments in a > consistent way across many OSes, not just UNIX. Unfortunately, it means that C programs are *inconsistent* with the command line interface of most operating systems. In the latest UNIX Review, Eric Allman describes a better way. It's called "parseargs", and uses a table to describe the command line arguments. This permits the use of multi- character arguments in operating systems where this is the standard, and generates usage and error messages directly. If a program (let's call it foo) uses it, then it could be called as: foo -[abcdef] foofile [file]... foo /{add,block,create,delete,edit,find} foofile [file[,file]...] foo /[abcdef] foofile [file]... foo foofile {add,block,create,delete,edit,find} [file]... foo foofile/{AD,BL,CR,DL,ED,FD}[=file[,file]...] Depending on the operating system it's running under. Not only that, but it's easier to use than getopt: main(ac, av) int ac; char **av; { parseargs(argument_descriptor_table, av); ... } -- `-_-' Peter da Silva <peter@ficc.uu.net> <peter@sugar.lonestar.org>. 'U` -------------- +1 713 274 5180. "The basic notion underlying USENET is the flame." -- Chuq Von Rospach, chuq@Apple.COM