Date:Tue, 30 Jul 2019 00:46:38 -0700
From:L A Walsh
Message-ID: <5d3ff5de.50...@tlinx.org>
| It isn't a judgment call to list only the options it supports on a given
| system. I'd think that would be clear.
That's an opinion, and that makes it something which ev
On 2019/07/29 22:09, Robert Elz wrote:
> Whether bash ought limit its usage output option list to those
> options supported on the system it is running on, or whether it
> is better to list everything it knows about (either my, or your,
> system might have more limits bash knows nothing about)
ps: if you want to find out which ulimit options
are supported on your system, use (parse) the output
of ulimit -a
Modified script that does that appended .. still
bash specific, as the output format of ulimit -a is
also not specified ... in fact, giving any options to
ulimit at all, aside from -f
The ulimit usage lists all the limits that bash supports.
Of those, the ones that actually work are the ones that your
system also supports.
On my system (like yours) ulimit -P and ulimit -k fail, as
while the system has pseudo tty's and kqueues, there are no
per process limits on how many can be
in bash 4.4.12,
giving an invalid option to ulimit gives a usage:
ulimit: usage: ulimit [-SHabcdefiklmnpqrstuvxPT] [limit]
-SH are for Soft/Hard, so they don't count and -a is for all,
so skipping the first 4, the rest:
but the rest:
ops=$(ulimit -h |& perl -ne 'm{\[([^\]]++)\]} && print "$1\n"')
