Re: PATCH: Re: sudo completion problem

Re: PATCH: Re: sudo completion problem

[Sven Wischnowsky]

Zefram wrote:

> ...
> 
> If we can determine that a particular command is processing options in
> this way, it would be nice to complet options accordingly.  However,
> by default options should only be completed before the first non-option
> argument.  In either case, options should never be completed after a "--".

I don't buy this. There *may* be commands or shell functions which
take `--' to, e.g.,  separate different sets of options and arguments.

_arguments is intended to be general enough to generate sensible
completions even for user-written shell functions, after all.

Please lets not make _arguments treat any string from the line special 
like this. Lets add it to:

> I envision _arguments first of all deciding whether the command allows
> options everywhere or not.  This should be under the control of the
> caller, via options to _arguments; possible values are "everywhere",
> "only before first argument", "autodetect GNU getopt" (if possible).

So wo would have these plus these combined with `and no options after --'.

Ok?

> _arguments must also check for a "--" argument, and not do option
> completion (regardless of option style) if the cursor is after the "--".
> All of this then lets it decide whether to complete options or not;
> non-option arguments are always a possibility, though we might want to
> be clever about handling arguments that start with "-".

No patch yet, but adding an option to comparguments (the builtin) for
the second (i.e. "only before first argument" the first would still be
the default, _arguments could use a different default, I don't care
that much about it for now) should be easy. And another option for the 
"no options after `--'" would be easy, too.

But before I start writing it: should the default for _arguments be
changed? And would someone be willing to check all uses of _arguments
and add the option to the calls that need them? Oh, and does anyone
have an idea how to test for GNU-getopts. Reliably?

Bye
 Sven


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

Re: optional argument?

[Sven Wischnowsky]

Tanaka Akira wrote:

> In article <200004250945.LAA03283@beta.informatik.hu-berlin.de>,
>   Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> 
> > > Because an argument for `-o' is optional, `xxx' is an argument for the
> > > option or first non-option argument.  So, the word to be completed by
> > > <TAB> is first non-option argument or second non-option argument.
> > > Hence `arg1' and `arg2' should be completed.  But I think this is bit
> > > confused and not so useful.
> > 
> > Oh, did you have to say that?
> 
> I found an example.
> 
> Z(4):akr@serein% Src/zsh -f
> serein% Src/zsh -f
> serein% bindkey -e; fpath=($PWD/Completion/*(/)); autoload -U compinit; compinit -D; compdef _tst tst
> serein% zstyle ':completion:*' group-name ''
> serein% zstyle ':completion:*:messages' format %d
> serein% zstyle ':completion:*:descriptions' format %d
> serein% diff --context ChangeLog <TAB>
> original file
> ...
> new file
> ...
> 
> This is caused by optional argument for --context.  In this position,
> _diff_options should completes only new files: second file set.  In
> general, optional argument of _arguments always causes similar
> problem, I think.  So, I think it is bit confused and not so useful.

Well, in this case it is really caused by --context not accepting its
argument in a separate word.

Hm, what are we supposed to do now? Generally making it not complete
normal arguments when in a position for an optional option-argument
wouldn't solve the problem. Making it not complete optional option-
arguments in separate words could be wrong, too, for commands that can 
find out if the argument is a normal or for the option.

Hrmpf. Make `='-options complete the argument *only* after the equal
sign? Add a new specification type, say `-opt==' for options that
don't accept the argument in a separte word (should the long-option
auto-detection code use it then?)?

I think I prefer the latter. Opinions?

Bye
 Sven


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

Re: optional argument?

[Peter Stephenson]

> Hrmpf. Make `='-options complete the argument *only* after the equal
> sign? Add a new specification type, say `-opt==' for options that
> don't accept the argument in a separte word (should the long-option
> auto-detection code use it then?)?
> 
> I think I prefer the latter. Opinions?

More generally, I wonder if a good way to handle variant option syntax
might be to allow a `profile' of some sort to be passed down to arguments,
either as an option or a parameter, saying what form of options and
arguments the command in question accepts.  This keeps the rest of the
command line to arguments neater.  It can wait.  It doesn't help here if
it's really that one option that has the rogue behaviour.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: optional argument?

[Tanaka Akira]

In article <200005080944.LAA15834@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> Well, in this case it is really caused by --context not accepting its
> argument in a separate word.

Yes.  So, I used `--context=-' in _cvs for `cvs diff'.  However this
is bit annoying because `=' is not removal suffix.

> Hm, what are we supposed to do now? Generally making it not complete
> normal arguments when in a position for an optional option-argument
> wouldn't solve the problem. Making it not complete optional option-
> arguments in separate words could be wrong, too, for commands that can 
> find out if the argument is a normal or for the option.

Actual commands which has optional arguments judge whether they are
specified or not in a some criteria.  So, supporting some common
criteria is useful.

> Hrmpf. Make `='-options complete the argument *only* after the equal
> sign? Add a new specification type, say `-opt==' for options that
> don't accept the argument in a separte word (should the long-option
> auto-detection code use it then?)?

Exactly, the existence of `=' is the criteria used by getopt_long.  So
it's good.  But I vote `-opt=?' instead of `-opt=='.

Note that another common criteria is that a optional argument must be
some set of strings: `yes' or `no' for example.  At least, xset
handles optional arguments in this way.  If we can specify a pattern
addition to the current optional argument syntax, it can be handled.
However, _xset cannot use _arguments since it has more anomalies if
the optional arguments can be handled.

Apart from that, I hope a extension for _arguments.  There are 
many duplicated descriptions such as:

    ....
    '(-i)--ignore-case[case insensitive]' \
    '(--ignore-case)-i[case insensitive]' \
    '(-w)--ignore-all-space[ignore all white space]' \
    '(--ignore-all-space)-w[ignore all white space]' \
    '(-b)--ignore-space-change[ignore changes in the amount of white space]' \
    '(--ignore-space-change)-b[ignore changes in the amount of white space]' \
    '(-B)--ignore-blank-lines[ignore lines that are all blank]' \
    '(--ignore-blank-lines)-B[ignore lines that are all blank]' \
    '(-I)--ignore-matching-lines=[ignore lines that match regex]:line exclusion regex:' \
    '(--ignore-matching-lines)-I+[ignore lines that match regex]:line exclusion regex:' \
    ...

So, I really want to describe them as:

    ...
    '--ignore-case,-i[case insensitive]' \
    '--ignore-all-space,-w[ignore all white space]' \
    '--ignore-space-change,-b[ignore changes in the amount of white space]' \
    '--ignore-blank-lines,-B[ignore lines that are all blank]' \
    '--ignore-matching-lines=,-I+[ignore lines that match regex]:line exclusion regex:' \
    ...

In other words, I think it is useful that opt-spec is comma separated
list of options.  And exclusive options are automatically set up each
other if they are not prefixed as `*'.
-- 
Tanaka Akira

Re: PATCH: Re: sudo completion problem

[Tanaka Akira]

In article <200005080900.LAA13146@beta.informatik.hu-berlin.de>,
  Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

> But before I start writing it: should the default for _arguments be
> changed? And would someone be willing to check all uses of _arguments
> and add the option to the calls that need them? Oh, and does anyone
> have an idea how to test for GNU-getopts. Reliably?


0. If a completion function knows the precious command behavior, use
   the knowledge.

1. If `-s' is not specified, it's not getopt.

2. If the environment variable POSIXLY_CORRECT is set, assume
   traditional getopt.

3. If on GNU system such as Linux, assume GNU getopt.

4. If it is not cases above, assume traditional getopt.

I think this guess is not so bad.
-- 
Tanaka Akira

Assorted _arguments arguments

[Bart Schaefer]

On May 8, 11:00am, Sven Wischnowsky wrote:
} Subject: Re: PATCH: Re: sudo completion problem
}
} Zefram wrote:
} 
} > If we can determine that a particular command is processing options in
} > this way, it would be nice to complet options accordingly.  However,
} > by default options should only be completed before the first non-option
} > argument.  In either case, options should never be completed after a "--".
} 
} I don't buy this. There *may* be commands or shell functions which
} take `--' to, e.g., separate different sets of options and arguments.

As an example, consider writing a completer for the old compctl command,
following a -x option.

} _arguments is intended to be general enough to generate sensible
} completions even for user-written shell functions, after all.

I'm with Sven here.  I don't think making _arguments more specialized is
the right thing.  There should perhaps be a fairly trivial way to tell it
to stop completing options after a non-option argument, including `--' as
a non-option, but otherwise I think it may already even go too far in
treating words that begin with a `-' specially.

} But before I start writing it: should the default for _arguments be
} changed? And would someone be willing to check all uses of _arguments
} and add the option to the calls that need them?

I don't think it makes a lot of difference which way the default goes;
do whatever would require the fewest changes to _arguments and to all
the other functions that call it.

On May 8, 11:44am, Sven Wischnowsky wrote:
} Subject: Re: optional argument?
}
[Tanaka-san wrote:]
} > This is caused by optional argument for --context.  In this position,
} > _diff_options should completes only new files: second file set.  In
} > general, optional argument of _arguments always causes similar
} > problem, I think.  So, I think it is bit confused and not so useful.
} 
} Hrmpf. Make `='-options complete the argument *only* after the equal
} sign? Add a new specification type, say `-opt==' for options that
} don't accept the argument in a separte word (should the long-option
} auto-detection code use it then?)?

On May 8, 11:49pm, Tanaka Akira wrote:
} Subject: Re: optional argument?
}
} Actual commands which has optional arguments judge whether they are
} specified or not in a some criteria.  So, supporting some common
} criteria is useful.
} 
[...]
} 
} Exactly, the existence of `=' is the criteria used by getopt_long.  So
} it's good.  But I vote `-opt=?' instead of `-opt=='.

I think we should try to make the syntax consistent with `getopts' and
`zparseopts' if possible.  Maybe that _isn't_ possible do to conflicting
use of colons ... and maybe we should have thought of that before we used
colons everywhere, but ...

} Note that another common criteria is that a optional argument must be
} some set of strings: `yes' or `no' for example.  At least, xset
} handles optional arguments in this way.  If we can specify a pattern
} addition to the current optional argument syntax, it can be handled.

If there's a known set of strings that can be the optional argument, then
I think this can be handled with state changes and/or alternation and we
don't need any more patterns jammed into the opt-spec.

} Apart from that, I hope a extension for _arguments.  There are 
} many duplicated descriptions such as:
} 
}     '(-i)--ignore-case[case insensitive]' \
}     '(--ignore-case)-i[case insensitive]' \
}     '(-w)--ignore-all-space[ignore all white space]' \
}     '(--ignore-all-space)-w[ignore all white space]' \
} 
} So, I really want to describe them as:
} 
}     '--ignore-case,-i[case insensitive]' \
}     '--ignore-all-space,-w[ignore all white space]' \
} 
} In other words, I think it is useful that opt-spec is comma separated
} list of options.  And exclusive options are automatically set up each
} other if they are not prefixed as `*'.

On a similar topic, can anyone think of a way to write an exclusive-or
glob pattern?  E.g. I want to match ChangeLog if that exists, or Changes
if that exists, but neither if both exist?

Returning to the original topic, perhaps a better way to think of this
is that -i and --ignore-case are synonyms and should get the same
treatment and description.  E.g. your suggestion does not help with
a case like

_bzip2:    '(--decompress --compress -z --test -t)-d[decompress]' \
_bzip2:    '(-d --compress -z --test -t)--decompress[decompress]' \
_bzip2:    '(--compress --decompress -d --test -t)-z[compress]' \
_bzip2:    '(-z --decompress -d --test -t)--compress[compress]' \

where you have both options that have alternate names for each other and
are mutually exclusive with other options.  Much better would be, say,

	'-d(--decompress)' '-z(--compress)' '-t(--test)' \
	'(-z -t)-d[decompress]' \
	'(-d -t)-z[compress]' \
	'(-z -d)-t[test compressed file integrity]' \

It might even be able to compute this automatically from the comma-lists
in --help output, or some such.  (No, I don't really like the `-x(--xxx)'
syntax, but I haven't time to think harder about it just now.)

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

Re: Assorted _arguments arguments

[Peter Stephenson]

Bart wrote:
> On a similar topic, can anyone think of a way to write an exclusive-or
> glob pattern?  E.g. I want to match ChangeLog if that exists, or Changes
> if that exists, but neither if both exist?

I don't think this is possible.  The globbing code matches files
separately.  It would have to look at the list of files already matched to
know whether to reject both that and the new one, which is extremely
hairy.  Obviously you can do it with arrays and things.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070