[Pkg-zsh-devel] Bug#807836: Bug#807836: builtin unlimit leads to "xargs: invalid number for -s"

[Thilo Six]

Hello Axel,

Axel Beckert schrieb/wrote:

>> in https://bugs.debian.org/807836 it was discovered that the Zsh builtin
>> "unlimit" has potential unforeseen side-effects.
>>
>> An easy to reproduce case for the problem is documented in
>> https://bugs.debian.org/807836#30
> 
> That example is IMHO a wrong usage of awk then. If the consuming
> script isn't capable of parsing scientific notation but uses a tool
> which produces scientific notation if needed, that's for sure not
> zsh's fault.
> 
>> The problem here is that unlimit sets the maximum input size to s.th. that is by
>> far out of the feasibility of the hardware being used.
> 
> So what. Bash does similar things:
> 
> $ ulimit -v -m
> virtual memory          (kbytes, -v) unlimited
> max memory size         (kbytes, -m) unlimited
> 
> I'm sure even with swap, there's no unlimited virtual memory available
> on my machine.


That is my main point. I think the "real problem" here is the definition of a
"hard limit". My definition of a "hard limit" is either the maximum physical
capability of the hardware being used, or a subset of that when a admin sets a
hard limit via e.g. /etc/security/limits.conf .
...and not some random value without any meaning.

Obviously YMMV

So i do not blame anyone, i just ask for clarification on:
    i How is unlimit designed to work.
   ii Improved its documentation to match that design, so that potentially users
      of unlimit have a chance to reliable decide whether unlimt is for them.

Hint:
/usr/share/doc/zsh-common/examples/zshrc.gz
contains "unlimit" and thats iirc is the place where i got it from. Nor from
that example file nor from manpage one can have a glimpse of the real impact
that unlimit has for runtime.

Again i do not blame anyone and i certainly will not jump into a potential flame
war over "how to write good code".

It is just that i had fallen into a trap which could have been avoided with more
information about the consequences of unlimit.


> I'm sorry, but if code is broken by too big integer values or
> unexpected by used scientific notation, it's not valid code but broken
> code.

I second that. But that is an other bug.



kind regards,

     Thilo