Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: -M option for limit
- X-seq: zsh-workers 732
- From: Zefram <A.Main@xxxxxxxxxxxxxxxxx>
- To: P.Stephenson@xxxxxxxxxxxxx
- Subject: Re: -M option for limit
- Date: Wed, 10 Jan 1996 09:28:05 +0000 (GMT)
- Cc: zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <12538.9601100851@xxxxxxxxxxxxxxx> from "P.Stephenson@xxxxxxxxxxxxx" at Jan 10, 96 08:51:47 am
Peter wrote:
>A.Main@xxxxxxxxxxxxxxxxx wrote:
>> I think the limit syntax would be much more consistent if it were
>> changed from "limit resource value" to "limit resource=value". This
>> would allow arbitrary mixtures of setting and examining resource
>> limits, as is already possible with things like typeset and alias. The
>> limit builtin is rather well-established, though, so if it's going to
>> be changed it really can't be delayed. Any opinions?
>
>I think this would be an unnecessary incompatibility.
Actually I've come up with a good compromise. If we simply require
limit values to start with a digit (i.e. don't allow "k" to mean "0k"),
it would be possible to unambiguously specify multiple resources on the
command line, each with an optional limit. For example, "limit core
desc 32 vmem" would display the limits for coredumpsize and
vmemorysize, and set descriptors to 32. bash's ulimit works much this
way, though with option flags rather than keywords. At some point I'd
like to modify zsh's ulimit to work like bash's, and do this equivalent
to limit as well.
-zefram
Messages sorted by:
Reverse Date,
Date,
Thread,
Author