_values and specifying -M to compadd

_values and specifying -M to compadd

[Danek Duvall]

I've spent a couple of hours trying to figure out how to do this, but am
stumped.  I'm working on completion for the Solaris command pfexec, one
option of which takes an argument of a fixed set of tokens, separated by
commas, where each token may optionally be prefixed by a "!".

I can do the simple

    _values -s , "descr" $tokens

where $tokens was set earlier to be ( $tokens \!$^tokens ), but that's
cheap, and it doubles the list of tokens, which isn't very nice looking.
I'd like it to just ignore a "!" when it's there, a la setopt's ignoring of
"no", but I can't figure out how to make that work with _values, which
doesn't seem to give an option to pass options (specifically -M) on to
compadd.

Is there some other reasonably simple way of doing this, or will I have to
invoke compadd directly?

Thanks,
Danek

Re: _values and specifying -M to compadd

[Peter Stephenson]

Danek Duvall wrote:
> I've spent a couple of hours trying to figure out how to do this, but am
> stumped.  I'm working on completion for the Solaris command pfexec, one
> option of which takes an argument of a fixed set of tokens, separated by
> commas, where each token may optionally be prefixed by a "!".
> 
> I can do the simple
> 
>     _values -s , "descr" $tokens
> 
> where $tokens was set earlier to be ( $tokens \!$^tokens ), but that's
> cheap, and it doubles the list of tokens, which isn't very nice looking.
> I'd like it to just ignore a "!" when it's there, a la setopt's ignoring of
> "no", but I can't figure out how to make that work with _values, which
> doesn't seem to give an option to pass options (specifically -M) on to
> compadd.
> 
> Is there some other reasonably simple way of doing this, or will I have to
> invoke compadd directly?

_values is designed to be smart about the values of key/value pairs,
whereas you need something to be smart about the keys.  (_values is
also a bit of a mess because the internals are delegated to a builtin
"compvalues" which is only documented in the C source.)

Actually, using compadd directly isn't that hairy here.  I got this to work:

  local expl

  tokens=(apple banana cucumber date elephant)

  # Ignore existing values
  compset -P '*,'
  # Ignore a leading !, maybe backslash-quoted
  compset -P '\\#!'

  # Use , as a (removable) separator
  _wanted tokens expl 'desription for tokens' compadd -qS , -a tokens

The hairy bit is the pattern that removes a !.  Since you need to
quote that with extendedglob, you'd expect things like 'apple,!banana'
and apple,\!banana to be equivalent, but actually for the first you need
to remove ! and for the second you need to remove \!.  Previous
experience suggests investigation of this would lead to madness, so
I've just worked around it.

This ought to be enough to make a start.  It would obviously get more
complicated if you need key/value pairs as well, but from your
description it sounds like you don't.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


.

Re: _values and specifying -M to compadd

[Danek Duvall]

On Mon, Sep 24, 2007 at 10:24:25AM +0100, Peter Stephenson wrote:

> _values is designed to be smart about the values of key/value pairs,
> whereas you need something to be smart about the keys.  (_values is
> also a bit of a mess because the internals are delegated to a builtin
> "compvalues" which is only documented in the C source.)

Yeah, that stymied me.  :)  I wasn't all that intent into diving into the C
source.  Though if it's well commented, I might take a look anyway.

> Actually, using compadd directly isn't that hairy here.  I got this to work:

Wonderful.  I was missing the compset bits, and while I might have
eventually stumbled on the first, I probably wouldn't have gotten the
second.

The only thing remaining is to remove already-completed tokens, which I'm
doing with a simple loop over IPREFIX:

    for t in ${(s:,:)${IPREFIX//\\#\!/}}; do
        tokens=( ${tokens:#$t} )
    done

before passing tokens on to compadd.  It looked like there wasn't any
special magic in _values that did this, but it's sufficiently poorly
commented that I wasn't sure exactly where this was happening.

You can't think of a fruit starting with "e" either, eh?  :)

Thanks!
Danek

zsocket help

[S. Cowles]

does anyone have a piece of sample code showing practical usage of 
zsockets?  i'm not having success developing functioning zsocket code 
using a current zsh cvs code pull.  i've been working from the zshall man 
page and from the partial zsocket examples from zshlovers without success. 
any help would be appreciated.  thanks.

Re: zsocket help

[Peter Stephenson]

"S. Cowles" wrote:
> does anyone have a piece of sample code showing practical usage of 
> zsockets?  i'm not having success developing functioning zsocket code 
> using a current zsh cvs code pull.  i've been working from the zshall man 
> page and from the partial zsocket examples from zshlovers without success. 
> any help would be appreciated.  thanks.

I got the following to work.

In terminal A:

  % typeset REPLY
  % zmodload zsh/net/socket
  % zsocket -l /tmp/zsocket
  % print $REPLY
  11
  % zsocket -a 11

This now blocks.  (I put the "typeset REPLY" at the start to ensure REPLY is
created as a string, as you would naturally do in a function.)

In terminal B:

  % typeset REPLY
  % zmodload zsh/net/socket
  % zsocket /tmp/zsocket
  % print $REPLY
  3

Terminal A returns at this point and I did:

  % print $REPLY
  3
  % read -u3 && print $REPLY

and in terminal B:

  % print -u3 This is a message on the socket

which produces in terminal A:

  This is a message on the socket

As far as I can see there's no way of closing the file descriptors using
zsocket, which seems an omission.  Presumably you can use "exec 3>&-"
etc. although to close a file descriptor over 9 you need to do something
like:

  % fd=11
  % exec {fd}>&-

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

Re: zsocket help

[S. Cowles]

thank you very much, peter.  and, yes, i _do_ have a purchased copy of 
your superb book.  cheers, sir.
sid


On Wed, 26 Sep 2007, Peter Stephenson wrote:

> Date: Wed, 26 Sep 2007 09:48:02 +0100
> From: Peter Stephenson <pws@csr.com>
> To: zsh-users@sunsite.dk
> Subject: Re: zsocket help
> 
> "S. Cowles" wrote:
>> does anyone have a piece of sample code showing practical usage of
>> zsockets?  i'm not having success developing functioning zsocket code
>> using a current zsh cvs code pull.  i've been working from the zshall man
>> page and from the partial zsocket examples from zshlovers without success.
>> any help would be appreciated.  thanks.
>
> I got the following to work.
>
> In terminal A:
>
>  % typeset REPLY
>  % zmodload zsh/net/socket
>  % zsocket -l /tmp/zsocket
>  % print $REPLY
>  11
>  % zsocket -a 11
>
> This now blocks.  (I put the "typeset REPLY" at the start to ensure REPLY is
> created as a string, as you would naturally do in a function.)
>
> In terminal B:
>
>  % typeset REPLY
>  % zmodload zsh/net/socket
>  % zsocket /tmp/zsocket
>  % print $REPLY
>  3
>
> Terminal A returns at this point and I did:
>
>  % print $REPLY
>  3
>  % read -u3 && print $REPLY
>
> and in terminal B:
>
>  % print -u3 This is a message on the socket
>
> which produces in terminal A:
>
>  This is a message on the socket
>
> As far as I can see there's no way of closing the file descriptors using
> zsocket, which seems an omission.  Presumably you can use "exec 3>&-"
> etc. although to close a file descriptor over 9 you need to do something
> like:
>
>  % fd=11
>  % exec {fd}>&-
>
> --
> Peter Stephenson <pws@csr.com>                  Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070
>