On 11/16/2011 01:56 PM, Karel Zak wrote:
Example:
> $ prlimit -l -l -l -l -l -l -l -l -l -l -l -l -l -l -l -l -l -l -l
> RESOURCE DESCRIPTION SOFT HARD UNITS
> MEMLOCK max locked-in-memory address space 65536 262144 bytes
> MEMLOCK max locked-in-memory address space 65536 262144 bytes
> ...
> Segmentation fault
Ah.. stupid bug.
> Use the lims array in a more direct way, i.e. the index is limit id.
> Initialize lims array and adapt option parsing in main() accordingly.
> do_prlimits() and show_limits(): loop over all MAX_RESOURCES in the
> lims array.
It means that users cannot control order of the printed and modified
resources. We prefer in all our new utils that output is fully
controlled by users -- only this is a way how you can create stable
and robust scripts.
I have replaced the array with list (see include/list.h). This
solution makes the code more readable and robust.
# ./prlimit --data --nofile
RESOURCE DESCRIPTION SOFT HARD UNITS
DATA max data size unlimited unlimited bytes
NOFILE max amount of open files 1001 3000
thanks, using a list is even cooler!
With my solution, you couldn't display a limit before and after
changing it in the same call like it is possible now:
prlimit -n -n1000: -n -n:1000 -n
RESOURCE DESCRIPTION SOFT HARD UNITS
NOFILE max amount of open files 1024 8192
NOFILE max amount of open files 1000 8192
NOFILE max amount of open files 1000 1000
Have a nice day,
Berny
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
