Re: [1003.1(2016/18)/Issue7+TC2 0001418]: Add options to ulimit to match get/setrlimit()

2020-11-17 Thread Jilles Tjoelker via austin-group-l at The Open Group
On Tue, Nov 17, 2020 at 03:14:43PM +, Geoff Clare via austin-group-l at The Open Group wrote: > Or I could just go with my original suggestion of adding: > Conforming applications shall specify each option separately; that is, > grouping option letters (for example, −fH) need not be re

Re: [1003.1(2016/18)/Issue7+TC2 0001418]: Add options to ulimit to match get/setrlimit()

2020-11-17 Thread Robert Elz via austin-group-l at The Open Group
I think we should cease discussions of how options are parsed, or what bash does with ulimit, and return to documenting what is reasonable to document for ulimit. There is another case not yet considered: ulimit -n -n The shells that only allow a single option and report whatever was req

Re: [1003.1(2016/18)/Issue7+TC2 0001418]: Add options to ulimit to match get/setrlimit()

2020-11-17 Thread Chet Ramey via austin-group-l at The Open Group
On 11/17/20 10:56 AM, Geoff Clare via austin-group-l at The Open Group wrote: Chet Ramey wrote, on 17 Nov 2020: On 11/17/20 10:14 AM, Geoff Clare via austin-group-l at The Open Group wrote: Maybe you could handle those by seeing that the option argument is alphabetic (and not "unlimited") and

Re: [1003.1(2016/18)/Issue7+TC2 0001418]: Add options to ulimit to match get/setrlimit()

2020-11-17 Thread Geoff Clare via austin-group-l at The Open Group
Chet Ramey wrote, on 17 Nov 2020: > > On 11/17/20 10:14 AM, Geoff Clare via austin-group-l at The Open Group wrote: > > > Maybe you could handle those by seeing that the option argument is > > alphabetic (and not "unlimited") and treating it as a string of > > option letters instead of reporting t

Re: [1003.1(2016/18)/Issue7+TC2 0001418]: Add options to ulimit to match get/setrlimit()

2020-11-17 Thread Chet Ramey via austin-group-l at The Open Group
On 11/17/20 10:14 AM, Geoff Clare via austin-group-l at The Open Group wrote: Maybe you could handle those by seeing that the option argument is alphabetic (and not "unlimited") and treating it as a string of option letters instead of reporting that it is an invalid number. From `getopt's pers

Re: [1003.1(2016/18)/Issue7+TC2 0001418]: Add options to ulimit to match get/setrlimit()

2020-11-17 Thread Geoff Clare via austin-group-l at The Open Group
Chet Ramey wrote, on 17 Nov 2020: > > 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 wi

Re: [1003.1(2016/18)/Issue7+TC2 0001418]: Add options to ulimit to match get/setrlimit()

2020-11-17 Thread Chet Ramey via austin-group-l at The Open Group
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

Re: [1003.1(2016/18)/Issue7+TC2 0001418]: Add options to ulimit to match get/setrlimit()

2020-11-17 Thread Geoff Clare via austin-group-l at The Open Group
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. > > > > >