Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site psivax.UUCP Path: utzoo!watmath!clyde!cbosgd!ihnp4!houxm!mtuxo!mtunh!vax135!cornell!uw-beaver!tektronix!hplabs!sdcrdcf!psivax!friesen From: friesen@psivax.UUCP (Stanley Friesen) Newsgroups: net.unix Subject: Re: Comments on UNIX command option syntax Message-ID: <852@psivax.UUCP> Date: Wed, 13-Nov-85 11:32:15 EST Article-I.D.: psivax.852 Posted: Wed Nov 13 11:32:15 1985 Date-Received: Mon, 18-Nov-85 05:28:01 EST References: <1260@wanginst.UUCP> <835@psivax.UUCP> <418@graffiti.UUCP> <791@whuxl.UUCP> Reply-To: friesen@psivax.UUCP (Stanley Friesen) Distribution: net Organization: Pacesetter Systems Inc., Sylmar, CA Lines: 80 In article <791@whuxl.UUCP> mike@whuxl.UUCP (BALDWIN) writes: >> Re: Stanley Friesen's comments about proposed UNIX command syntax standard. > > >Oh, 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?? I agree, but I think it could do this better than it does. Uniformity is *nice*, but it can be carried too far. Actually you seem to have misunderstood the purpose of my remarks. I was trying to propose a few minor changes in the standard which I feel would improve its utility and flexibility, without harming its value as a standard. > >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. Oh, I intend to use getopt(3C) as much as possible, but I would hate to see it enforce *all* of the proposed rules. And yes the full set of rules in the standard is restrictive, too restrictive. For me to be willing to actually use the standard it would have to be much less restrictive. As it stands, I will ignore the standard whenever it is convenient to do so! It wi8ll not get very far as a standard, and will not produce much uniformity, if loads of people ignore it as being too restrictive. Whoever is in charge of it should rewrite it to be more flexible. >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. > Agreed, this is why I will probably use getopt(), but *not* the syntax standard! >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. Now, when I invent a new language, say 'Blaise', and write a compiler for it(a NEW command) I must either cripple it by leaving out the '-l' option capability, or violate the standard by allowing post argument options with position dependent meaning! The standard should include all *major* ways of using options in current comamnds. I consider the compilers to be *major* commands, even though there are only a few of them. The standard needs to include them! > 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. > And it misses, it fails to incorporaste the very commonly used option handling syntax of every existing compiler on UNIX! Just because it covers the syntax of the greatest *number* of seperate commands does not mean it covers the syntax of the *most* *used* commands. It needs to do *both*. >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. > Agreed, but see above, it misses some *important* current uses. >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. Yes, I do have some suggestions, and I gave them in my original article. To start with drop the rule about *all* option preceding *all* arguments. -- Sarima (Stanley Friesen) UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen ARPA: ttidca!psivax!friesen@rand-unix.arpa