Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: PATCH: suggestion for new condition
- X-seq: zsh-workers 4978
- From: Peter Stephenson <pws@xxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx (Zsh hackers list)
- Subject: Re: PATCH: suggestion for new condition
- Date: Mon, 25 Jan 1999 11:57:20 +0100
- In-reply-to: "Sven Wischnowsky"'s message of "Mon, 25 Jan 1999 11:40:18 NFT." <199901251040.LAA12723@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Sven Wischnowsky wrote:
>
> Dunno if you'll like this one.
>
> I sometimes missed an easy way to check if a certain parameter was set
> or of a specific type. The patch below adds the condition `-v' for
> this:
>
> `-v param' is true if the parameter `param' is set
You can do this already with `if (( $+param )) ...'.
> `-v param type' is true if paramater `param' is set and of the
> given type; `type' may be any of: scalar, array,
> integer, association, left, right, right-blank,
> right-zero, upper, readonly, tag, export, and
> unique
You can't do this at the moment, but maybe a more flexible way would
be to create another ${(...)} flag --- looks like t is still usable
--- and make ${(t)param} print out the type of param, so you can do
[[ ${(t)param} = (array|association)* ]], and things like that. It's
maybe a little more transparent, and the information can be used
outside conditions. It's a little more complicated in that you have
to have a list like "array left unique", or whatever, but if the basic
type always comes first maybe it's obvious enough. It could return a
blank for unset. Of course [[ ${(t)param} = *export* ]] is less
efficient than [[ -v param export ]], but I don't think that's a major
worry. It should be reasonably easy --- the question is always quite
how to insert any new code into paramsubst(), it's a bit like deciding
where to put a needle in a haystack.
I worry a little, too, (though it maybe groundless) that overloading
conditions in the basic shell will cause unexpected results with
existing tests that ought to work, e.g. things like [[ -v = -v ]] ---
I don't mean that one doesn't actually work, I mean there are all
sorts of possibilities along those lines that can be quite complicated
to get right. Some (many) versions ago I remember having a headache
about sh-compatibility in test, e.g. what should `test -n' mean, and
so on.
--
Peter Stephenson <pws@xxxxxxxxxxxxxxxxx> Tel: +39 050 844536
WWW: http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy
Messages sorted by:
Reverse Date,
Date,
Thread,
Author