Re: ulimit behaviour of bash vs. zsh

[Peter Stephenson <p.stephenson@samsung.com>]

On Mon, 06 Oct 2014 14:30:46 +0200
Michael Prokop <news@michael-prokop.at> wrote:
> this is what Bash does:
> 
> $ ulimit -l
> 64
> $ ulimit -l unlimited
> bash: ulimit: max locked memory: cannot modify limit: Operation not permitted
> $ echo $?
> 1
> 
> While that's the behaviour of Zsh:
> 
> % ulimit -l
> 64
> % ulimit -l unlimited
> % echo $?
> 0
> % ulimit -l
> 64
> 
> I find this quite irritating. Is that behaviour by intention? :)

I think it might be, but it's a little obscure and took some tracking
down.  It turns out if you set a soft limit to unlimited the shell is
smart / overdesigned enough to know that the maximum you can actually
set it to successfully is the value of the hard limit, so it silently
downgrades your "unlimited" request to the maximum you can actually
get.  (Line 670 of Src/Builtins/rlimits.c for those following along not
at home; line 652 does the same if the limit isn't known by
name/letter.  Whether setting the internal limits structure before a
system call that may fail is also problematic I don't know.)

Why I'm not sure it's intentional is the documentation says there's a
special value "hard" to set the limit to the value of the hard limit; it
says nothing about do this with the value "unlimited" that I can see.
This bypasses a lot of internal shell logic but ends up doing roughly
the same thing.

I suppose it could at least warn about this.

pws