Re: _chflags

["Akinori MUSHA" <knu@xxxxxxxxxxxx>]

At Thu, 02 Aug 2001 17:19:53 +0100,
Oliver Kiddle wrote:
> > 1. How can I prevent _values from sorting the values?
> 
> Er. Sven? -V doesn't work so you probably can't. Why do you want to? To
> group flags with their no variants by any chance? In the latest zsh 4.1,

Exactly.

> it might be better to use '(noarch arch)'{arch,noarch}'[archived flag]'
> which would put arch and noarch on the same line with a shared
> description.

Sounds very neat. :)

> > 2. How can I let zsh automatically add `R' when one chooses -[LHP]?
> 
> Again, I don't know/don't think it can be done. You would need to get it
> to be added as an (auto-removable) suffix which I don't think _arguments
> can handle.

On second thought it's not a smart solution.  I found a much better
way, so forget about this. (See below)

> >        '(noarch)arch[set the archived flag (super-user only)]' \
> 
> What I've done is removed `(super-user only)' from the descriptions and
> made it only complete those flags for the super-user (EUID=0). I have
> also got it to only complete files which the user owns. This follows the
> way that _chown works. Incidentally, symlinks are followed for this and
> chown so when I commit this, I'll add `req=( -$^req )' before the _files
> call in _chown. 

But how do you handle the case where one uses something like sudo?  Do
you have a plan to make sudo's compdef smart enough to fake EUID?

> About these descriptons again: I'm not too sure how useful the
> description `set the dump flag' is although that type of description is
> quite common for zsh completions. I think the chances are that someone
> using chflags can work out that `chflags opaque' sets the opaque flag
> and noopaque unsets the flag. However, I wouldn't have a clue what the
> significance of the opaque file flag is. To an extent I blame that man
> page because it doesn't explain either. So I'd be tempted (for 4.1 only)
> to change the flags to along the lines of:
> '(dump nodump)'{dump,nodump}'[backup file when dump(8) is next run]'

Noted.  However, it's the manpage's problem and the zsh compdef can
just provide short descriptions. (actually chflags(2) explains further
details)


> Note that that description for the dump flag could be completely wrong.
> In 4.1 this looks roughly like this when completed:
> 
> file flag
> dump    nodump    --  backup file when dump(8) is next run

Hmm, I can't wait for this grouping feature. :)

> The aliases for the flags could then also be added. What do you reckon?

Perhaps that's going too far.  Most users get used to the short form
and would never use longer ones.  That's the UNIX style. :>

> And, if you can check this updated function below please.

OK, aside from the EUID part, I suggest changing this part:

> _arguments -s -A "-*" \
>   '(-L -P)-H[follow symlinks on the command line (specify with -R)]' \
>   '(-H -P)-L[follow all symlinks (specify with -R)]' \
>   '(-L -H)-P[do not follow symlinks (specify with -R)]' \
>   '-R[recurse directories]' \
>   ':file flag:_values -s , "file flags" $flags[@]' \
>   '*:file:_files "$own"'

As follows:

local ftsopts

ftsopts=(
  'P[do not follow symlinks]'
  'H[follow symlinks on the command line]'
  'L[follow all symlinks]'
)

_arguments -s -A "-*" \
  '-R-:recurse directories:_values "recurse option" $ftsopts[@]' \
  ':file flag:_values -s , "file flags" $flags[@]' \
  '*:file:_files "$own"'


Thanks so much for your help! :)

-- 
                     /
                    /__  __            Akinori.org / MUSHA.org
                   / )  )  ) )  /     FreeBSD.org / Ruby-lang.org
Akinori MUSHA aka / (_ /  ( (__(  @ iDaemons.org / and.or.jp

"Freeze this moment a little bit longer, make each impression
  a little bit stronger..  Experience slips away -- Time stand still"