Re: [PATCHv3 2/2] [long] improvements to limit/ulimit API and doc (the rest)

[Stephane Chazelas <stephane@chazelas.org>]

[sorry, should have been v3 in the subject of the email I'm
replying to by the way).

2020-11-27 20:13:42 +0000, Stephane Chazelas:
[...]
> I've tried to address that in this v3 patch. Specifying the type
> (as in char*, int...) seems redundant though and not generally
> done in other functions, so I've left it out for now.
[...]
> +	    if (shell) {
> +		/*
> +		 * FIXME: this is dead code as at the moment, there is no API
> +		 * for the user can request all limits *of the shell* be
> +		 * displayed.
> +		 *
> +		 * Should we add a "limit -s -a" or "limit -s all"?
> +		 */
[...]

And in my initial email:

> - I've made it so "limit -s filesize" reports the shell's own
>   limit (-s is for "set" initially, but it could also be "shell"
>   or "self"). But while "limit" outputs all children limits,
>   "limit -s" still copies those children limits to the shell's
>   and there's no way to print *all* self limits. That doesn't
>   make for a very intuitive API.

Maybe one approach could be to introduce some $shell_limits and
$children_limits special associative arrays indexed on limit
name (or number for those limits that don't have a name yet).

Which would allow things like:

(( shell_limits[filesize] >= min )) || die "can't do"

There's the problem of RLIM_INFINITY and the fact that rlim_t is
unsigned so if 64bit, allows values beyond the integer ones
supported by arithmetic evaluation.

Both could be addressed by making the value a floating point
number (append a . or e0 and use inf for RLIM_INFINITY), but
that sounds less than ideal as we're losing precision and limits
are really integers in the first place (and for consistency
limit/ulimit would need to be updated to accept floating point
on input).

There's also the problem that "limit" (contrary to ulimit) lets
you set more than one limit at a time, but not print more than
one limit at a time ("limit cputime" prints the value of
"cputime" but "limit cputime filesize" tries to set the cputime
limit to "filesize").

So, maybe a better approach is to add a "-p" for "print":

- limit or limit -p prints all the known limits for children
- limit -ps prints all the known limits for the shell
- limit -p filesize or limit filesize prints the filesize limit
- limit -p filesize cputime prints the filesize and cputime
  limits.

And maybe a "-r" for "raw" though there's always the problem of
RLIM_INFINITY and uint64.

And of course there's always the possibility of ignoring the
problem altogether as it's not as if anybody is going to miss
that feature very badly.

At the moment, one can always do:

(( ${$(ulimit -f)//unlimited/inf} >= ceil(min / 512.) )) ||
  die "can't do"

(though that's children_limits, and bearing in mind that ulimit
rounds down the number so we'll get false positives like when
min is 1 and the limit is 511B, rounded down to 0).

-- 
Stephane