[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: when options conflict
From: |
Benno Schulenberg |
Subject: |
Re: when options conflict |
Date: |
Tue, 23 May 2006 23:25:14 +0200 |
User-agent: |
KMail/1.9.1 |
Paul Eggert wrote:
> That part of the Posix utility syntax guidelines is meant not
> only for appending-type stuff. Howver, it is intended only for a
> repeated option with option-arguments.
Cool. Now... the thing says that "the option and option-argument
combinations should be interpreted in the order specified". As
argued before, this means to me that _order matters_ for repeated
options. For min() and max() functions order is irrelevant, so
these cannot be the intended ways of interpreting repeated options.
When arguments are simple numbers, how can order matter? Only when
either the first one or the last one counts. The last one counting
is more useful.
> We should not attempt to
> use that wording as a means to wiggle out of the general
> principle that the order of different options should not matter.
Fine. For different options. But not for repeated occurrences of
the same option with different arguments.
> > Instead of "Write only a count of selected lines" the -c option
> > should say "Instead of the selected lines, write per file only
> > a count of these lines".
>
> That change would be fine, but it doesn't affect the conclusion.
Sure it does. The general case for grep is to search multiple
files. Now imagine a confused user specifying both -l and -c
on the command line. What should grep do? What is the logical
intersection of 'only filenames' and 'filenames plus counts'? To
me that is clear: 'filenames'. So -l blots out -c in the case of
multiple files; for the corner case of a single file, the most
logical thing to do is to have -l blot out -c too.
> >> -l says "output file names only". These options clearly
> >> conflict.
> >
> > Not when the description of the -c option were phrased
> > correctly.
>
> More would have to be changed.
Yes, the description of the -l option could be improved too.
> The description under STDOUT
> currently doesn't make sense if -l and -c are both specified.
It makes perfect sense to me. It says: "If the -l option is in
effect [...] Otherwise [...] The remainder [...]".
This 'remainder' part refers only to the 'Otherwise' part, not
to 'the -l option'. So when -l is in effect, -c is never even
considered.
> > But for all repeated options,
> > like -C or --color or -D or -d or -m, in the current
> > implementation the last value given is the one that counts.
>
> That doesn't sound right to me. For example, if -m NUM means
> "output no more than NUM lines", then multiple instances of -m
> should accumulate by taking the minimum, and "-m 50 -m 100"
> should be equivalent to "-m 50". Under this interpretation,
> order wouldn't matter, which is a good thing.
No, it's the wrong thing. When I say "yes... no... eh, yes", which
one do I mean; when I say "50... 100... 80", which one do I mean?
It's the last thing I mentioned what counts.
But fine. Let's assume that min() is what governs -m. What
about -C? Should also there the smallest number count, being the
logical intersection? Fine. What about --color? Of never, auto,
always; which is the smallest? -d, read, skip or recurse? -D,
read or skip?
No! Being able to override an option-argument with a new argument
is _so_ convenient, and it is what grep now does in almost every
case, surely that is not by accident?
> > Why not make the logical pair -H/-h behave
> > the same way? It robs the user of no functionality, it just
> > gives him or her a tiny bit extra
>
> It robs the user by adding unnecessary complexity to the system.
> This is an extra overhead for the user.
I give up.
Benno
- Re: when options conflict, (continued)
- Re: when options conflict, Paul Eggert, 2006/05/19
- Re: when options conflict, Tony Abou-Assaleh, 2006/05/20
- Re: when options conflict, Benno Schulenberg, 2006/05/20
- Re: when options conflict, Paul Eggert, 2006/05/20
- Re: when options conflict, Benno Schulenberg, 2006/05/21
- Re: when options conflict, Paul Eggert, 2006/05/22
- Re: when options conflict, Benno Schulenberg, 2006/05/22
- Re: when options conflict, Paul Eggert, 2006/05/22
- Re: when options conflict, Benno Schulenberg, 2006/05/22
- Re: when options conflict, Paul Eggert, 2006/05/23
- Re: when options conflict,
Benno Schulenberg <=
- Re: when options conflict, Julian Foad, 2006/05/25
- Re: when options conflict, Tony Abou-Assaleh, 2006/05/26
- Re: when options conflict, Tony Abou-Assaleh, 2006/05/22
- Re: when options conflict, Paul Eggert, 2006/05/23
- Re: when options conflict, Tony Abou-Assaleh, 2006/05/23
Re: when options conflict, Tony Abou-Assaleh, 2006/05/20