_chflags

_chflags

[Akinori MUSHA]

Hi,

Attached is the compdef for *BSD's chflags(1) command, which changes
special file flags.  Please add it if it's okay.

The manpage is available via the web, by the following URL:

	http://www.FreeBSD.org/cgi/man.cgi?query=chflags&apropos=0&sektion=1&manpath=FreeBSD+4.3-RELEASE&format=html

I didn't add rules for the options becase I couldn't be sure if it's
worth supporting.

-- 
                     /
                    /__  __            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"

#compdef chflags

if [[ CURRENT -eq 2 || CURRENT -eq 3 && $words[CURRENT-1] = -* ]]; then
	local flags

	case $OSTYPE in
	  freebsd*)
		flags=(arch opaque nodump sappnd schg sunlnk uappnd uchg uunlnk)
		compadd $flags ${flags/#/no}
	  ;;
	  netbsd*|openbsd*)	  
		flags=(arch opaque nodump sappnd schg uappnd uchg)
		compadd $flags ${flags/#/no}
	  ;;
	esac
else
	_files
fi

Re: _chflags

[Oliver Kiddle]

Akinori MUSHA wrote:

> Attached is the compdef for *BSD's chflags(1) command, which changes
> special file flags.  Please add it if it's okay.

I'll add that (and the _sysctl change).

Is the nodump flag defintely turned off with nonodump then (as opposed
to just dump)?

According to the man page you referenced, the flags are specified as a
comma separated list so I would suggest you replace the flags= and
compadd lines with something like:

_values -s , 'file flag'
{no,}{arch,opaque,nodump,sappnd,schg,sunlnk,uappnd,uchg,uunlnk}

but if descriptions for the flags might be useful, you could use things
like:
'(noarch)arch[set archived]' to _values.
It would be nice to use _arguments for the options. Are the options
different on net/openbsd or different versions of FreeBSD? Do they all
use the comma separated list of flags?

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

Re: _chflags

[Akinori MUSHA]

At Thu, 02 Aug 2001 13:21:01 +0100,
Oliver Kiddle wrote:
> I'll add that (and the _sysctl change).
> 
> Is the nodump flag defintely turned off with nonodump then (as opposed
> to just dump)?
> 
> According to the man page you referenced, the flags are specified as a
> comma separated list so I would suggest you replace the flags= and
> compadd lines with something like:
> 
> _values -s , 'file flag'
> {no,}{arch,opaque,nodump,sappnd,schg,sunlnk,uappnd,uchg,uunlnk}
> 
> but if descriptions for the flags might be useful, you could use things
> like:
> '(noarch)arch[set archived]' to _values.
> It would be nice to use _arguments for the options. Are the options
> different on net/openbsd or different versions of FreeBSD? Do they all
> use the comma separated list of flags?

Ah, OK, I'm getting the hang of it.  Every point you addressed above
is correct.  Now what about the attached one? :)

And I have a couple of questions:

1. How can I prevent _values from sorting the values?
2. How can I let zsh automatically add `R' when one chooses -[LHP]?


Thanks,

-- 
                     /
                    /__  __            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"

#compdef chflags

(( $+functions[__chflags] )) ||
__chflags() {
  if [[ CURRENT -eq 2 || $words[CURRENT-1] = -* ]]; then
    case $OSTYPE in
     freebsd*)
      _values -s , 'file flags' \
       '(noarch)arch[set the archived flag (super-user only)]' \
       '(arch)noarch[unset the archived flag (super-user only)]' \
       '(noopaque)opaque[set the opaque flag (owner or super-user only)]' \
       '(opaque)noopaque[unset the opaque flag (owner or super-user only)]' \
       '(dump)nodump[set the nodump flag (owner or super-user only)]' \
       '(nodump)dump[unset the nodump flag (owner or super-user only)]' \
       '(nosappnd)sappnd[set the system append-only flag (super-user only)]' \
       '(sappnd)nosappnd[unset the system append-only flag (super-user only)]' \
       '(noschg)schg[set the system immutable flag (super-user only)]' \
       '(schg)noschg[unset the system immutable flag (super-user only)]' \
       '(nosunlnk)sunlnk[set the system undeletable flag (super-user only)]' \
       '(sunlnk)nosunlnk[unset the system undeletable flag (super-user only)]' \
       '(nouappnd)uappnd[set the user append-only flag (owner or super-user only)]' \
       '(uappnd)nouappnd[unset the user append-only flag (owner or super-user only)]' \
       '(nouchg)uchg[set the user immutable flag (owner or super-user only)]' \
       '(uchg)nouchg[unset the user immutable flag (owner or super-user only)]' \
       '(nouunlnk)uunlnk[set the user undeletable flag (owner or super-user only)]' \
       '(uunlnk)nouunlnk[unset the user undeletable flag (owner or super-user only)]'
     ;;
     netbsd*|openbsd*)	  
      _values -s , 'file flags' \
       '(noarch)arch[set the archived flag (super-user only)]' \
       '(arch)noarch[unset the archived flag (super-user only)]' \
       '(noopaque)opaque[set the opaque flag (owner or super-user only)]' \
       '(opaque)noopaque[unset the opaque flag (owner or super-user only)]' \
       '(dump)nodump[set the nodump flag (owner or super-user only)]' \
       '(nodump)dump[unset the nodump flag (owner or super-user only)]' \
       '(nosappnd)sappnd[set the system append-only flag (super-user only)]' \
       '(sappnd)nosappnd[unset the system append-only flag (super-user only)]' \
       '(noschg)schg[set the system immutable flag (super-user only)]' \
       '(schg)noschg[unset the system immutable flag (super-user only)]' \
       '(nouappnd)uappnd[set the user append-only flag (owner or super-user only)]' \
       '(uappnd)nouappnd[unset the user append-only flag (owner or super-user only)]' \
       '(nouchg)uchg[set the user immutable flag (owner or super-user only)]' \
       '(uchg)nouchg[unset the user immutable flag (owner or super-user only)]'
      ;;
    esac
  else
    _files
  fi
}

_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 direcotries]' \
      '*:flags and files:__chflags'

Re: _chflags

[Oliver Kiddle]

Akinori MUSHA wrote:
> 
> Ah, OK, I'm getting the hang of it.  Every point you addressed above
> is correct.  Now what about the attached one? :)

That's great.

> And I have a couple of questions:
> 
> 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,
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.

You can use styles to group no and non-no flags separately if that is
what you want to do. Can anyone else please enlighten me if there is a
style to affect the sort order?

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

> (( $+functions[__chflags] )) ||
> __chflags() {

I take it that you copied this from _kld or _bsd_pkg which is fine. I
prefer to use states with _arguments to defining separate functions
within completion functions. In the case of _chflags, neither is
actually necessary.

>   if [[ CURRENT -eq 2 || $words[CURRENT-1] = -* ]]; then

_arguments takes care of that

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

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

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

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

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

Oliver

#compdef chflags

local flags own='-g *(-u$EUID)'

flags=(
  '(noopaque)opaque[set the opaque flag]'
  '(opaque)noopaque[unset the opaque flag]'
  '(dump)nodump[set the nodump flag]'
  '(nodump)dump[unset the nodump flag]'
  '(nouappnd)uappnd[set the user append-only flag]'
  '(uappnd)nouappnd[unset the user append-only flag]'
  '(nouchg)uchg[set the user immutable flag]'
  '(uchg)nouchg[unset the user immutable flag]'
)

if (( ! EUID )); then
  flags=( $flags[@]
    '(noarch)arch[set the archived flag]'
    '(arch)noarch[unset the archived flag]'
    '(nosappnd)sappnd[set the system append-only flag]'
    '(sappnd)nosappnd[unset the system append-only flag]'
    '(noschg)schg[set the system immutable flag]'
    '(schg)noschg[unset the system immutable flag]'
  )
  unset own
fi

if [[ $OSTYPE = freebsd* ]]; then
  flags=( $flags[@]
    '(nouunlnk)uunlnk[set the user undeletable flag]'
    '(uunlnk)nouunlnk[unset the user undeletable flag]'
  )
  (( EUID )) || flags=( $flags[@]
    '(nosunlnk)sunlnk[set the system undeletable flag]'
    '(sunlnk)nosunlnk[unset the system undeletable flag]'
  )
fi

_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"'

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

Re: _chflags

[Akinori MUSHA]

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"

Re: _chflags

[Sven Wischnowsky]

Oliver Kiddle wrote:

> ...
> 
> > And I have a couple of questions:
> > 
> > 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,
> 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.
> 
> You can use styles to group no and non-no flags separately if that is
> what you want to do. Can anyone else please enlighten me if there is a
> style to affect the sort order?

Currently not.  It could be added without too much work, but I, too,
wonder why anyone would want that.  Especially with functions like this
one, where the specs are put together in steps based on OS version. 
Finding stuff in a sorted list should be a lot easier.

Hm.  Maybe we could add a set of styles like `file-sort' (for options,
values, pids, jobs, ...) if we can come up with reasonable sort criteria
for each of them.  That would then make sense (for menu completion and
selection).

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

I can't think of an easy way to get this either.  But it sounds
interesting because it sounds like something that could be generalised. 
Support for `suggested' other completions.  Hm...

> > (( $+functions[__chflags] )) ||
> > __chflags() {
> 
> I take it that you copied this from _kld or _bsd_pkg which is fine. I
> prefer to use states with _arguments to defining separate functions
> within completion functions. In the case of _chflags, neither is
> actually necessary.

(Aside: for more complex things I actually sometimes prefer
sub-functions because than _arguments can be kept in control.)

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

Yes we (and foremost I) have been a bit lazy sometimes... but then I'm
quite happy that we have these descriptions at all.

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

It would be `nodump dump', wouldn't it?  I've been thinking about this
when I wrote the grouping code (and then forgot to mention it again). 
Maybe we should make the code watch out for prefixes `-no', `no', `no-'
and the like (`-enable', `-disable', `-with', `-without',...?).  The one
without the prefix (with one of the prefixes...) would then be put in
front.  We could even make it shorten the display string for the other
form(s), e.g. `dump no...   -- backup ...' or `dump  [no]   -- ...'.
Heck, we could even make it display something like `dump  [yes] [no] ...'
or anything else because display string are completely separate from
match strings.

Opinions, anyone?


Bye
  Sven


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

Re: _chflags

[Oliver Kiddle]

Akinori MUSHA wrote:
> 
> 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?

I never thought of that really because I've never use sudo. It could be done with some sort of argument or variable passed down by _sudo and checked for in any completion it would affect, such as _chown and _chflags.

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

I'm not too sure about that. Presumably -R can be preceded by the other options? In other cases where a certain option is only valid when combined with another, we haven't done anything special like this. If we should then it is a wider issue.

Oliver

_____________________________________________________________________
This message has been checked for all known viruses by the 
MessageLabs Virus Scanning Service. For further information visit
http://www.messagelabs.com/stats.asp

grouping inverses and sorting in completion lists (was _chflags)

[Oliver Kiddle]

Sven 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?

> > Can anyone else please enlighten me if there is a
> > style to affect the sort order?

> Currently not.  It could be added without too much work, but I, too,
> wonder why anyone would want that.  Especially with functions like this
> one, where the specs are put together in steps based on OS version. 
> Finding stuff in a sorted list should be a lot easier.

> Hm.  Maybe we could add a set of styles like `file-sort' (for options,

I don't think it is necessary at the style level: I've never wanted it
and here (_chflags) it was only wanted to group options with their
inverse. The only thing I have needed was to have a list sorted
correctly numerically (such as in _subscript for array indexes) and
this is better done from the functions than from a style. It might be
worth rethinking the compadd options with respect to sorting though.

> > > 2. How can I let zsh automatically add `R' when one chooses -[LHP]?

> I can't think of an easy way to get this either.  But it sounds
> interesting because it sounds like something that could be generalised. 
> Support for `suggested' other completions.  Hm...

I can't think of much to suggest here.

> > In 4.1 this looks roughly like this when completed:
> > > file flag
> > dump    nodump    --  backup file when dump(8) is next run
> 
> It would be `nodump dump', wouldn't it?  I've been thinking about this

Yes.

> when I wrote the grouping code (and then forgot to mention it again). 
> Maybe we should make the code watch out for prefixes `-no', `no', `no-'
> and the like (`-enable', `-disable', `-with', `-without',...?).  The one
> without the prefix (with one of the prefixes...) would then be put in
> front.  We could even make it shorten the display string for the other
> form(s), e.g. `dump no...   -- backup ...' or `dump  [no]   -- ...'.
> Heck, we could even make it display something like `dump  [yes] [no] ...'
> or anything else because display string are completely separate from
> match strings.

Something like that would be very good. To automatically detect
inverses might have problems in that many words start with `no' and it
would be nice to be flexible enough to allow other forms. There might
be cases where `de', `in' or `un' are used instead of `no' or maybe two
totally different words. One possibility (which would need further
refining) would be an option to _arguments which would be roughly like:
-I '/--enable\(*\)/--disable\1/'
The idea being that if this (sed like) substitution translates an
option to match one of the other options, that other option can be
taken to be its inverse.

As for how to display it, shortening the display string would be very
nice. It also makes it clearer which is the negative sense which is
helpful if the description is written in a positive form. I'm not so
sure about the [yes] [no] idea. Here are some possibilities it would
ideally need to deal with:

--with-gnu-ld  without  --
--disable-nls  enable   --
dump           no...    --
-g             +g       -- e.g. for typeset
--no-filename --with-filename   -h   -H   -- e.g. for grep

Of course, it would be quite possible that the two inverse options are
given different descriptions. What it could do is select one of them
(either the shortest description or the description for the option on
the left) to display. Then if the other option was selected, the
description would change.

Cases like the latter one for grep might be messy so this needs more
thought. What would currently happen if there was loads of options
with the same description.

Oliver