Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 exptools; site whuxl.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!whuxl!mike From: mike@whuxl.UUCP (BALDWIN) Newsgroups: net.unix Subject: Re: Comments on UNIX command option syntax Message-ID: <791@whuxl.UUCP> Date: Sun, 10-Nov-85 21:02:23 EST Article-I.D.: whuxl.791 Posted: Sun Nov 10 21:02:23 1985 Date-Received: Tue, 12-Nov-85 03:57:27 EST References: <1260@wanginst.UUCP> <835@psivax.UUCP> <418@graffiti.UUCP> Distribution: net Organization: AT&T Bell Laboratories, Whippany Lines: 42 > Re: Stanley Friesen's comments about proposed UNIX command syntax standard. > > I'm glad that there's someone else on the net who believes that you can't > improve UNIX by adding more restrictions! > -- > Name: Peter da SilvaOh, bug off! The purpose of the syntax standard is to make things more uniform and easier to use. Would you rather every command parses args differently for no good reason?? Do you really want to remember FOR EACH COMMAND whether it uses -, single letter options, lets you bundle args, and allows/disallows/doesn't_care about whitespace for option arguments?? The syntax standard DOESN'T PUT RESTRICTIONS on how you want to parse args; your program won't be silently removed if it doesn't adhere to it. But if you want to be CONSISTENT and not have to tell people YET ANOTHER WAY TO PASS OPTIONS, then you can use getopt(3C) and not worry. Besides, adding getopt to programs usually REMOVES restrictions; lots of programs do it one way or another (bundle/no_bundle, space/no_space), but not both because it is just a pain to take care of all the cases. There are always going to be commands that don't adhere to the standard, like cc, pr, and sort. But that's OK. The purpose of writing down the standard is that when you go to write a NEW command, you have something to aim for. And it's not intended to be the best way ever to do option handling; it is meant to encapsulate the most prevalent means of option handling currently found in UNIX. It is NOT meant to encompass every single way options are dealt with in UNIX. If it DID, it would be so vague and wishy-washy that it would be useless. Do YOU have a counter proposal? If you do, I'd like to hear it. It should NOT be radically different from the way things are done now. I.e., programs like ls, cat, ed, grep, sed, etc., should be able to use it without any problems. It should be easy to teach people. If you DON'T have a proposal, then just SHUT UP. -- Michael Baldwin {at&t}!whuxl!mike