Re: PATCH: suggestion for new condition

Re: PATCH: suggestion for new condition

[Sven Wischnowsky]

Bart Schaefer wrote (in private mail):

> On Jan 28,  9:00am, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: suggestion for new condition
> }
> } Bart Schaefer wrote:
> } 
> } > OK, cool, now dumb question number two:  Why does ${(t)param} ignore the
> } > setting of the `nounset' option?
> } 
> } I don't understand this question. How should we use the setting of
> } nounset?
> 
> For any of the previously existing variable flags x, ${(x)notset} gives an
> error when `setopt nounset'.  However:
> 
> } I wanted it to be slightly modeled after `$+param' which also 
> } seems to ignore nounset.
> 
> That's a valid answer to the question "why?" but leads to the next question
> "is that how it _should_ work?"
> 
> The only reason to use $+param is to test whether param is set, so it
> would be silly for it to ever generate an error.  The main reason for
> using ${(t)param}, though, is to find out the type of the param.
> 
> You can always ask whether a parameter exists or not.  But if the param
> doesn't exist, its type is not merely empty; it's undefined, just as its
> value is undefined.  I think the reason for `nounset' is to make "not
> defined" different from "empty" (albeit in a rather brutal fashion), so
> I think the `nounset' test should apply.  Consistency, and all that.

Ok, I'm convinced.

Bye
 Sven

--- os/subst.c	Wed Jan 27 13:53:56 1999
+++ Src/subst.c	Thu Jan 28 10:17:08 1999
@@ -1017,11 +1017,11 @@
 		    val = dyncat(val, "-export");
 		if (f & PM_UNIQUE)
 		    val = dyncat(val, "-unique");
+		vunset = 0;
 	    } else
 		val = dupstring("");
 
 	    v = NULL;
-	    vunset = 0;
 	    isarr = 0;
 	}
     }

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: suggestion for new condition

[Bart Schaefer]

On Jan 27,  8:51am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: suggestion for new condition
}
} > } The patch below implements the `(t)' flag. `${(t)param}' will expand
} > } to a string describing the type of parameter. When param is unset, it
} > } will expand to `-'
} > 
} > Why?  Why not have it expand to nothing?  In any case "-" is a bad choice,
} > because in certain contexts it could be misinterpreted as an option.
} 
} Blink. Yes, you are right, I was just thinking about Peter's mail and
} didn't like to use a space. Of course, an empty string is the better
} solution.

OK, cool, now dumb question number two:  Why does ${(t)param} ignore the
setting of the `nounset' option?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: suggestion for new condition

[Sven Wischnowsky]

Bart Schaefer wrote:

> 
> On Jan 26,  4:47pm, Sven Wischnowsky wrote:
> } Subject: Re: PATCH: suggestion for new condition
> }
> } The patch below implements the `(t)' flag. `${(t)param}' will expand
> } to a string describing the type of parameter. When param is unset, it
> } will expand to `-'
> 
> Why?  Why not have it expand to nothing?  In any case "-" is a bad choice,
> because in certain contexts it could be misinterpreted as an option.

Blink. Yes, you are right, I was just thinking about Peter's mail and
didn't like to use a space. Of course, an empty string is the better
solution.


Bye
 Sven

--- os/subst.c	Tue Jan 26 16:48:43 1999
+++ Src/subst.c	Wed Jan 27 08:39:55 1999
@@ -1018,7 +1018,7 @@
 		if (f & PM_UNIQUE)
 		    val = dyncat(val, "-unique");
 	    } else
-		val = dupstring("-");
+		val = dupstring("");
 
 	    v = NULL;
 	    vunset = 0;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH: suggestion for new condition

[Bart Schaefer]

On Jan 26,  4:47pm, Sven Wischnowsky wrote:
} Subject: Re: PATCH: suggestion for new condition
}
} The patch below implements the `(t)' flag. `${(t)param}' will expand
} to a string describing the type of parameter. When param is unset, it
} will expand to `-'

Why?  Why not have it expand to nothing?  In any case "-" is a bad choice,
because in certain contexts it could be misinterpreted as an option.

Otherwise I think ${(t)param} is a useful addition.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: suggestion for new condition

[Sven Wischnowsky]

Peter Stephenson wrote:

>
>...
> 
> 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.

The patch below implements the `(t)' flag. `${(t)param}' will expand
to a string describing the type of parameter. When param is unset, it
will expand to `-', otherwise it contains the keywords I used for the
-v condition separated by hyphens (just to avoid any trouble with
spaces).

The patch will conflict with the one for the -v condition only in
`new-completion-examples', but I think you will want to remove that
patch anyway (or haven't applied it).

Bye
 Sven

--- os/subst.c	Tue Jan 26 14:24:14 1999
+++ Src/subst.c	Tue Jan 26 16:06:54 1999
@@ -702,6 +702,7 @@
     int whichlen = 0;
     int chkset = 0;
     int vunset = 0;
+    int wantt = 0;
     int spbreak = isset(SHWORDSPLIT) && !ssub && !qt;
     char *val = NULL, **aval = NULL;
     unsigned int fwidth = 0;
@@ -902,6 +903,10 @@
 		    hvals = SCANPM_WANTVALS;
 		    break;
 
+		case 't':
+		    wantt = 1;
+		    break;
+
 		default:
 		  flagerr:
 		    zerr("error in flags", NULL, 0);
@@ -978,9 +983,47 @@
 	*s = sav;
 	v = (Value) NULL;
     } else {
-	if (!(v = fetchvalue(&s, (unset(KSHARRAYS) || inbrace) ? 1 : -1,
+	if (!(v = fetchvalue(&s, (wantt ? -1 :
+				  ((unset(KSHARRAYS) || inbrace) ? 1 : -1)),
 			     hkeys|hvals)))
 	    vunset = 1;
+
+	if (wantt) {
+	    if (v) {
+		int f = v->pm->flags;
+
+		switch (PM_TYPE(f)) {
+		case PM_SCALAR:  val = "scalar"; break;
+		case PM_ARRAY:   val = "array"; break;
+		case PM_INTEGER: val = "integer"; break;
+		case PM_HASHED:  val = "association"; break;
+		}
+		val = dupstring(val);
+		if (f & PM_LEFT)
+		    val = dyncat(val, "-left");
+		if (f & PM_RIGHT_B)
+		    val = dyncat(val, "-right_blanks");
+		if (f & PM_RIGHT_Z)
+		    val = dyncat(val, "-right_zeros");
+		if (f & PM_LOWER)
+		    val = dyncat(val, "-lower");
+		if (f & PM_UPPER)
+		    val = dyncat(val, "-upper");
+		if (f & PM_READONLY)
+		    val = dyncat(val, "-readonly");
+		if (f & PM_TAGGED)
+		    val = dyncat(val, "-tag");
+		if (f & PM_EXPORTED)
+		    val = dyncat(val, "-export");
+		if (f & PM_UNIQUE)
+		    val = dyncat(val, "-unique");
+	    } else
+		val = dupstring("-");
+
+	    v = NULL;
+	    vunset = 0;
+	    isarr = 0;
+	}
     }
     while (v || ((inbrace || (unset(KSHARRAYS) && vunset)) && isbrack(*s))) {
 	if (!v) {
--- od/Zsh/expn.yo	Mon Jan 25 14:36:26 1999
+++ Doc/Zsh/expn.yo	Tue Jan 26 16:30:36 1999
@@ -602,6 +602,46 @@
 Split the result of the expansion to lines. This is a shorthand
 for `tt(ps:\n:)'.
 )
+item(tt(t))(
+Don't work on the value of the parameter, but on a string describing
+the type of the parameter. This string consists of keywords separated
+by hyphens (`tt(-)'). The first keyword in the string describes the
+main type, it can be one of `tt(scalar)', `tt(array)', `tt(integer)',
+or `tt(association)'. The other keywords describe the type in more
+detail:
+
+startitem()
+item(`tt(left)')(
+for left justified parameters
+)
+item(`tt(right_blanks)')(
+for right justified parameters with leading blanks
+)
+item(`tt(right_zeros)')(
+for right justified parameters with leading zeros
+)
+item(`tt(lower)')(
+for parameters whose value is converted to all lower case when it is
+expanded
+)
+item(`tt(upper)')(
+for parameters whose value is converted to all upper case when it is
+expanded
+)
+item(`tt(readonly)')(
+for readonly parameters
+)
+item(`tt(tag)')(
+for tagged parameters
+)
+item(`tt(export)')(
+for exported parameters
+)
+item(`tt(unique)')(
+for arrays which keep only the first occurrence of duplicated values
+)
+enditem()
+)
 enditem()
 
 The following flags are meaningful with the tt(${)...tt(#)...tt(}),
--- om/new-completion-examples	Tue Jan 26 15:16:53 1999
+++ Misc/new-completion-examples	Tue Jan 26 16:41:13 1999
@@ -43,7 +43,7 @@
     shift
     autoload "$1"
   fi
-  if [[ ${+patcomps} == 1 ]] then
+  if (( $+patcomps )) then
     patcomps=("$patcomps[@]" "$2 $1" )
   else
     patcomps=( "$2 $1" )
@@ -78,10 +78,10 @@
   local var
 
   eval var\=\$\{\+$1\}
-  if [[ "$var" == 0 ]] then
-    "$@"
-  else
+  if (( var )); then
     eval complist \$\{${1}\[\@\]\}
+  else
+    "$@"
   fi
 }
 
@@ -323,8 +323,11 @@
 
 defcomp __subscr --subscr--
 __subscr() {
+  local t
+
+  eval t\=\$\{\(t\)$COMMAND\}
   compalso --math-- "$@"
-  # ...probably other stuff
+  [[ $t = assoc* ]] && eval complist -k \"\(\$\{\(k\)$COMMAND\}\)\"
 }
 
 # Do sub-completion for pre-command modifiers.
@@ -368,9 +371,6 @@
 defcomp __bjobs bg
 __bjobs=(-z -P '%')
 
-defcomp wait
-__wait=(-j -P '%' + -s '`ps -x | tail +2 | cut -c1-5`')
-
 defcomp __arrays shift
 __arrays=(-A)
 
@@ -536,6 +536,12 @@
     complist -P '%' -j
     complist -y killfunc -s '`ps -x 2>/dev/null | tail +2 | cut -c1-5`'
   fi
+}
+
+defcomp wait
+__wait() {
+  complist -P '%' -j
+  complist -y killfunc -s '`ps -x 2>/dev/null | tail +2 | cut -c1-5`'
 }
 
 defcomp cd

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: PATCH: suggestion for new condition

[Andrej Borsenkow]

>
> 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 ]] ---

What I think about, may be, quoting can be of some help here. That is, -v is
condition, but \-v or '-v' or "-v" should be interpreted as plain string? I
never used unquoted strings, even if it is quite legal. "str" simply looks
better :-) Others may have own preferences, though ...

/andrej

Re: PATCH: suggestion for new condition

[Peter Stephenson]

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@ibmth.df.unipi.it>       Tel: +39 050 844536
WWW:  http://www.ifh.de/~pws/
Dipartimento di Fisica, Via Buonarroti 2, 56127 Pisa, Italy

PATCH: suggestion for new condition

[Sven Wischnowsky]

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
  `-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

Changing these names, adding single character abbreviations, and
allowing `-v' to take more than one type wouldn't be too hard to
implement, but I first wanted to know if anyone else likes it.

Except for the hunks in `new-completion-examples' the patch should
work with pws-[1-4] (or pws-[2-4]). The stuff in
`new-completion-examples' fixes a bug for the completion for `wait' I
just discovered and makes the new condition be used (e.g. for
completing keys in subscripts of associative arrays).

Bye
 Sven

*** os/cond.c	Mon Jan 25 10:22:39 1999
--- Src/cond.c	Mon Jan 25 10:27:33 1999
***************
*** 114,119 ****
--- 114,163 ----
  	return (!!strlen(c->left));
      case 'o':
  	return (optison(c->left));
+     case 'v':
+ 	{
+ 	    Param pm = (Param) paramtab->getnode(paramtab,
+ 						 (char *) c->left);
+ 
+ 	    if (c->right) {
+ 		char *tn = (char *) c->right;
+ 		int t = (pm ? pm->flags : 0);
+ 
+ 		if (!strcmp(tn, "scalar"))
+ 		    t = (PM_TYPE(t) == PM_SCALAR);
+ 		else if (!strcmp(tn, "array"))
+ 		    t = (PM_TYPE(t) == PM_ARRAY);
+ 		else if (!strcmp(tn, "integer"))
+ 		    t = (PM_TYPE(t) == PM_INTEGER);
+ 		else if (!strcmp(tn, "association"))
+ 		    t = (PM_TYPE(t) == PM_HASHED);
+ 		else if (!strcmp(tn, "left"))
+ 		    t = (t & PM_LEFT);
+ 		else if (!strcmp(tn, "right"))
+ 		    t = (t & (PM_RIGHT_B | PM_RIGHT_Z));
+ 		else if (!strcmp(tn, "right-blank"))
+ 		    t = (t & PM_RIGHT_B);
+ 		else if (!strcmp(tn, "right-zero"))
+ 		    t = (t & PM_RIGHT_Z);
+ 		else if (!strcmp(tn, "upper"))
+ 		    t = (t & PM_UPPER);
+ 		else if (!strcmp(tn, "readonly"))
+ 		    t = (t & PM_READONLY);
+ 		else if (!strcmp(tn, "tag"))
+ 		    t = (t & PM_TAGGED);
+ 		else if (!strcmp(tn, "export"))
+ 		    t = (t & PM_EXPORTED);
+ 		else if (!strcmp(tn, "unique"))
+ 		    t = (t & PM_UNIQUE);
+ 		else {
+ 		    zerr("unrecognized paramter type: `%s'", tn, 0);
+ 
+ 		    return 0;
+ 		}
+ 		return (pm ? t : 0);
+ 	    }
+ 	    return !!pm;
+ 	}
      case 'p':
  	return (S_ISFIFO(dostat(c->left)));
      case 'r':
*** os/parse.c	Mon Jan 25 10:22:41 1999
--- Src/parse.c	Mon Jan 25 10:27:33 1999
***************
*** 1332,1338 ****
      n->left = (void *) b;
      if (a[0] != '-' || !a[1])
  	COND_ERROR("parse error: condition expected: %s", a);
!     else if (!a[2] && strspn(a+1, "abcdefgknoprstuwxzhLONGS") == 1)
  	n->type = a[1];
      else {
  	char *d[2];
--- 1332,1338 ----
      n->left = (void *) b;
      if (a[0] != '-' || !a[1])
  	COND_ERROR("parse error: condition expected: %s", a);
!     else if (!a[2] && strspn(a+1, "abcdefgknoprstuvwxzhLONGS") == 1)
  	n->type = a[1];
      else {
  	char *d[2];
***************
*** 1393,1407 ****
  	    n->right = (void *) arrdup(d);
  	}
      } else if (a[0] == '-' && a[1]) {
! 	char *d[3];
  
! 	n->ntype = NT_SET(N_COND, NT_STR, NT_STR | NT_ARR, 0, 0);
! 	n->type = COND_MOD;
! 	n->left = (void *) a;
! 	d[0] = b;
! 	d[1] = c;
! 	d[2] = NULL;
! 	n->right = (void *) arrdup(d);
      } else
  	COND_ERROR("condition expected: %s", b);
      return n;
--- 1393,1413 ----
  	    n->right = (void *) arrdup(d);
  	}
      } else if (a[0] == '-' && a[1]) {
! 	if (a[1] == 'v' && !a[2]) {
! 	    n->ntype = NT_SET(N_COND, NT_STR, NT_STR, 0, 0);
! 	    n->type = 'v';
! 	    n->left = (void *) b;
! 	} else {
! 	    char *d[3];
  
! 	    n->ntype = NT_SET(N_COND, NT_STR, NT_STR | NT_ARR, 0, 0);
! 	    n->type = COND_MOD;
! 	    n->left = (void *) a;
! 	    d[0] = b;
! 	    d[1] = c;
! 	    d[2] = NULL;
! 	    n->right = (void *) arrdup(d);
! 	}
      } else
  	COND_ERROR("condition expected: %s", b);
      return n;
*** od/Zsh/cond.yo	Mon Jan 25 10:22:12 1999
--- Doc/Zsh/cond.yo	Mon Jan 25 10:27:45 1999
***************
*** 46,51 ****
--- 46,99 ----
  may be a single character, in which case it is a single letter option name.
  (See noderef(Specifying Options).)
  )
+ item(tt(-v) var(name) [ var(type) ])(
+ true if a parameter var(name) exists. If an optional var(type) is
+ given this conditions is true only if the parameter is of the given
+ type. Currently understood types are:
+ 
+ startitem()
+ item(tt(scalar))(
+ for scalar parameters
+ )
+ item(tt(array))(
+ for arrays
+ )
+ item(tt(integer))(
+ for integer parameters
+ )
+ item(tt(associative))(
+ for associative arrays
+ )
+ item(tt(left))(
+ for left justified parameters
+ )
+ item(tt(right))(
+ for right justified parameters
+ )
+ item(tt(right-blank))(
+ for right justified parameters with leading blanks
+ )
+ item(tt(right-zero))(
+ for right justified parameters with leading zeros
+ )
+ item(tt(upper))(
+ for parameters whose values are converted to all upper case when they
+ are expanded
+ )
+ item(tt(readonly))(
+ for readonly parameters
+ )
+ item(tt(tagg))(
+ for tagged parameters
+ )
+ item(tt(export))(
+ for exported parameters
+ )
+ item(tt(unique))(
+ for arrays which keep only the first occurrence of duplicated values
+ )
+ enditem()
+ )
  item(tt(-p) var(file))(
  true if var(file) exists and is a FIFO special file (named pipe).
  )
*** om/new-completion-examples	Mon Jan 25 11:24:35 1999
--- Misc/new-completion-examples	Mon Jan 25 11:37:00 1999
***************
*** 43,49 ****
      shift
      autoload "$1"
    fi
!   if [[ ${+patcomps} == 1 ]] then
      patcomps=("$patcomps[@]" "$2 $1" )
    else
      patcomps=( "$2 $1" )
--- 43,49 ----
      shift
      autoload "$1"
    fi
!   if [[ -v patcomps ]] then
      patcomps=("$patcomps[@]" "$2 $1" )
    else
      patcomps=( "$2 $1" )
***************
*** 75,87 ****
  # the arguments from the command line as its arguments.
  
  call-complete() {
!   local var
! 
!   eval var\=\$\{\+$1\}
!   if [[ "$var" == 0 ]] then
!     "$@"
!   else
      eval complist \$\{${1}\[\@\]\}
    fi
  }
  
--- 75,84 ----
  # the arguments from the command line as its arguments.
  
  call-complete() {
!   if [[ -v $1 ]] then
      eval complist \$\{${1}\[\@\]\}
+   else
+     "$@"
    fi
  }
  
***************
*** 324,330 ****
  defcomp __subscr --subscr--
  __subscr() {
    compalso --math-- "$@"
!   # ...probably other stuff
  }
  
  # Do sub-completion for pre-command modifiers.
--- 321,327 ----
  defcomp __subscr --subscr--
  __subscr() {
    compalso --math-- "$@"
!   [[ -v $COMMAND association ]] && eval complist -k \"\(\$\{\(k\)$COMMAND\}\)\"
  }
  
  # Do sub-completion for pre-command modifiers.
***************
*** 368,376 ****
  defcomp __bjobs bg
  __bjobs=(-z -P '%')
  
- defcomp wait
- __wait=(-j -P '%' + -s '`ps -x | tail +2 | cut -c1-5`')
- 
  defcomp __arrays shift
  __arrays=(-A)
  
--- 365,370 ----
***************
*** 536,541 ****
--- 530,541 ----
      complist -P '%' -j
      complist -y killfunc -s '`ps -x 2>/dev/null | tail +2 | cut -c1-5`'
    fi
+ }
+ 
+ defcomp wait
+ __wait() {
+     complist -P '%' -j
+     complist -y killfunc -s '`ps -x 2>/dev/null | tail +2 | cut -c1-5`'
  }
  
  defcomp cd

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de