kos@ernie.Berkeley.EDU (Joshua Kosman) (07/21/86)
Anybody know an easy way to intercept, suppress or otherwise get rid of the error message that getopt() issues when user supplies an illegal flag? It seems uncharacteristically presumptuous -- I'll write my own "Usage:" messages myself, thanks. Joshua Kosman kos@ernie.berkeley.EDU "Life is like a bowl of soup with hairs floating on it. You have to eat it nevertheless." -- Flaubert
gwyn@BRL.ARPA (VLD/VMB) (07/21/86)
There should be an extern int variable named "opterr" that determines whether or not getopt() prints an error message. I think setting it to zero (opposite of what the SVR2 manual says) disables the message.
ggr@packard.UUCP (Guy Riddle) (07/22/86)
) Anybody know an easy way to intercept, suppress or otherwise get rid of the ) error message that getopt() issues when user supplies an illegal flag? ) It seems uncharacteristically presumptuous -- I'll write my own "Usage:" ) messages myself, thanks. Yes, use extern int opterr; opterr = 0; === Guy Riddle == AT&T Bell Laboratories Liberty Corner ===
levy@ttrdc.UUCP (07/22/86)
In article <14935@ucbvax.BERKELEY.EDU>, kos@ernie.Berkeley.EDU (Joshua Kosman) writes: >Anybody know an easy way to intercept, suppress or otherwise get rid of the >error message that getopt() issues when user supplies an illegal flag? >It seems uncharacteristically presumptuous -- I'll write my own "Usage:" >messages myself, thanks. > Joshua Kosman GETOPT(3C) UNIX System V GETOPT(3C) ... extern int optind, opterr; ... DIAGNOSTICS Getopt prints an error message on stderr and returns a question mark (?) when it encounters an option letter not included in optstring. This error message may be disabled ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ by setting opterr to a non-zero value. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ... Please, read the man page. (Note too that getopt(3) NEVER generates Usage: messages.) This message would have been mailed except I am not sure how to send mail to kos@ernie.Berkeley.EDU. -- ------------------------------- 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, go for it! allegra,ulysses,vax135}!ttrdc!levy
purtill@petrus.UUCP (Mark Purtill) (07/26/86)
In article <1078@ttrdc.UUCP>, levy@ttrdc.UUCP (Daniel R. Levy) writes: > In article <14935@ucbvax.BERKELEY.EDU>, kos@ernie.Berkeley.EDU (Joshua Kosman) writes: > >Anybody know an easy way to intercept, suppress or otherwise get rid of the > >error message that getopt() issues when user supplies an illegal flag? ... > GETOPT(3C) UNIX System V GETOPT(3C) ... > included in optstring. This error message may be disabled > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > by setting opterr to a non-zero value. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > ... > Please, read the man page. ... Not that the man page we have here (seems to be BSB 4.3) does not have the sentence marked with ^^^^s for a very good reason: its not true. Under 4.3 you can't suppress the messages except by rewriting getopt. Why did you(dan) assume someone from Berkeley was using sys V? mark purtill (201) 829-5127 ^.-.^ Arpa: purtill@bellcore.com 435 south st 2H-307 ((")) Uucp: ihnp4!bellcore!purtill morristown nj 07960
guy@sun.UUCP (07/27/86)
> > GETOPT(3C) UNIX System V GETOPT(3C) > ... > > included in optstring. This error message may be disabled > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > by setting opterr to a non-zero value. > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > Not that the man page we have here (seems to be BSB 4.3) does not have the > sentence marked with ^^^^s for a very good reason: its not true. Under > 4.3 you can't suppress the messages except by rewriting getopt. It's not true in ANY version of UNIX, System V *or* 4.3BSD. In BOTH versions, if you set "opterr" to *zero*, it will suppress the error messages. Read the code, not the manual page! The S5 page lies because it says setting "opterr" to a non-zero value turns off error messages; the 4.3 page doesn't indicate that setting "opterr" to zero turns off error messages. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
nonh@utzoo.UUCP (Chris Robertson) (07/31/86)
In article <5530@sun.uucp> guy@sun.UUCP writes: >Read the code, not the manual page! This may come as a great surprise to you, but some of us don't HAVE source code :-( -- Christine Robertson {linus, decvax, ihnp4}!utzoo!{nonh, toram!chris} Cat, n. - lapwarmer with built-in buzzer.
guy@sun.uucp (Guy Harris) (08/01/86)
> >Read the code, not the manual page! > > This may come as a great surprise to you, but some of us don't HAVE source > code :-( This may come as a great surprise to you, but I'm at least as aware of that as you. However, the person in question was talking about 4.3BSD, which means they almost certainly had source code (no vendor is offering 4.3BSD yet, since the 4.3BSD tape only came out recently). Anybody with source has certainly learned by now that the UNIX documentation is only a rough approximation to the truth. The source code is, in some cases, the final arbiter; in others, the documentation is correct. The *only* way to resolve this is a combination of additional knowledge and good taste (to judge whether the change to the code implied by the documentation is correct or not). This is an awful situation. With any luck, documentation from UNIX resellers has been cleaned up somewhat; if not, beat up your vendor to improve their documentation. -- Guy Harris {ihnp4, decvax, seismo, decwrl, ...}!sun!guy guy@sun.com (or guy@sun.arpa)
bzs@bu-cs.BU.EDU (Barry Shein) (08/04/86)
From: guy@sun.uucp (Guy Harris) >Anybody with source has certainly learned by now that the UNIX documentation >is only a rough approximation to the truth. The source code is, in some >cases, the final arbiter; in others, the documentation is correct... No, no, the COMPUTER is the final arbiter. When in doubt make up a few little code samples and see what they do. This doesn't require sources, except your own and works well, I'm serious. It never ceases to astound me how many times people come in to my office and ask me a question that is amply answered with "go ask the computer, why bother me, I can't simulate a computer as fast as it can simulate itself..." -Barry Shein, Boston University
zben@umd5 (Ben Cranston) (08/14/86)
Sez: guy@sun.uucp (Guy Harris) > Anybody with source has certainly learned by now that the UNIX documentation > is only a rough approximation to the truth. The source code is, in some > cases, the final arbiter; in others, the documentation is correct... Sez: bzs@bu-cs.BU.EDU (Barry Shein) > No, no, the COMPUTER is the final arbiter. When in doubt make up a few > little code samples and see what they do. This doesn't require > sources, except your own and works well, I'm serious. It never ceases > to astound me how many times people come in to my office and ask me a > question that is amply answered with "go ask the computer, why bother > me, I can't simulate a computer as fast as it can simulate itself..." While I agree generally, there are sometimes questions dealing with writing transportable code that should definitely *NOT* be determined by the use of trivial test programs. A code fragment like: a[i] = b[i++]; for example is likely to do different things on different machines, and only an experienced human being can give you the answer you REALLY want: "Yes, it does what you want on *THIS* machine, but *DON'T* use code like this because it is not portable." -- umd5.UUCP <= {seismo!umcp-cs,ihnp4!rlgvax}!cvl!umd5!zben Ben Cranston zben @ umd2.UMD.EDU Kingdom of Merryland Sperrows 1100/92 umd2.BITNET "via HASP with RSCS"