On 11/17/20 4:53 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Chet Ramey wrote, on 16 Nov 2020:
On 11/16/20 11:05 AM, Geoff Clare via austin-group-l at The Open Group wrote:
Chet Ramey wrote, on 16 Nov 2020:
Thanks. Looks like bash is parsing the ulimit options in an unusual
way instead of using getopt() or similar.
Quite the opposite. The bash ulimit builtin uses the same internal_getopt
code as the rest of the builtins, with the addition that option-arguments
are allowed to be missing and that `-f' is the default in the absence of
any other resource options.
What's happening is that the bash getopt treats `-xARG' identically to
`-x ARG'. When it sees `-fH' it assumes, since -f takes an option argument,
that `H' is that argument.
This is the same thing that POSIX getopt does; of course, it doesn't handle
optional arguments at all.
Huh? This contradicts what you said above: "with the addition that
option-arguments are allowed to be missing".
That is not a missing option-argument. A missing option argument is
something like `ulimit -c'. The POSIX getopt would not consider `-fH'
a missing option argument either, assuming `f:' were specified in the
option string; that's the point.
It also doesn't match
the behaviour I see in bash 5:
$ bash -c 'ulimit -fc'
bash: line 0: ulimit: c: invalid number
There's nothing mysterious here. The `c' constitutes the option-argument.
Numbered item 2 in the POSIX getopt description says the same thing.
The only way it would not be considered an option argument is if it looked
like an option itself: a separate argument preceded by a `-'. Which leads
me to the next example:
$ bash -c 'ulimit -f -c'
file size (blocks, -f) unlimited
core file size (blocks, -c) 100000
If it did not handle optional option-arguments, then this last command
would fail with "bash: line 0: ulimit: -c: invalid number".
Indeed, that's one aspect of the optional argument implementation.
But all of this discussion about getopt and optional arguments is a red
herring anyway. POSIX finesses all of this by not having option arguments
in the `ulimit' description at all, and the `newlimit' in the standard and
the current proposal is a separate operand. That limits you to modifying
one limit per call.
To match your description it would need to include:
... [-c[limit]] [-f[limit]] ...
Nah. I'd have to do that for every option, and I'd like to keep the manual
under 200 pages. The descriptive text explains things.
In that case you should give a synopsis that does not specify syntax,
instead of giving one that contradicts the description.
The readers seem to pick it up pretty well. I haven't received reports that
the description `contradicts' the syntax summary.
I understand that the POSIX syntax summary is a language, and if you're
fluent in its syntax and semantics, it's easy to read things in its terms.
Not a lot of people do that.
2. Otherwise, optarg shall point to the string following the option
character in that element of argv, and optind shall be incremented by 1."
This requires that if the option string includes "f:" and the argument
list has -f followed by -c then the -c is returned in optarg. That's not
what bash's ulimit does.
Let's try this again. The example in question here is `ulimit -fc'. If the
`f' were specified as returning an option-argument, the POSIX getopt would
certainly return `c' in optarg. The bash option string includes `;', which
specifies that the option-argument may not be present, but it is. If you
consider `-f -c', the `-c' looks like an option, so the optional argument
code considers the option-argument to be missing.
The POSIX `ulimit' description specifies that `newlimit' is an operand, not
an option-argument, so this discussion is academic.
One consequence of the POSIX description is, as I said above, that it
restricts each invocation to modifying one limit. That's how it can finesse
the `newlimit is an operand'. I'm not going to reduce functionality and
throw away backwards compatibility without a better reason.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
