From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: Should _long_options be considered dangerous?
Date: Thu, 18 Mar 1999 09:04:29 +0100 (MET) [thread overview]
Message-ID: <199903180804.JAA28000@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Bart Schaefer's message of Wed, 17 Mar 1999 23:04:04 -0800 (PST)
Bart Schaefer wrote:
> I wonder if perhaps we shouldn't add some more warning text in
> Completion/Base/_long_options (and maybe even in Completion/README)
> noting that you shouldn't attempt to use _long_options from _normal
> or any other "default" completion function.
>
> Some (non-GNU) commands might actually do something unpleasant when
> run with an unrecognized --help option. I can't think of an example
> offhand, which is why the Subject is a question, but ...
Yes, I've been wondering if we should do that, too...
Bye
Sven
--- oc/README Mon Mar 15 10:08:53 1999
+++ Completion/README Thu Mar 18 09:01:05 1999
@@ -74,7 +74,10 @@
This handles options beginning with `--', as in many GNU commands.
The command must accept the --help option to list the possible options.
__long_options can also take arguments to help it decide what to
- complete as the value of the option.
+ complete as the value of the option. Note that this is potentially
+ dangerous because the command from the line will be called with the
+ --help option and hence could cause damage if used with a command
+ that does not support it.
_match_pattern
_match_test
These are used by Base/_path_files (and hence also Base/_files)
--- oc/Base/_long_options Tue Mar 16 11:49:55 1999
+++ Completion/Base/_long_options Thu Mar 18 09:03:19 1999
@@ -2,9 +2,12 @@
# This function tries to automatically complete long option names. For
# this it invokes the command from the line with the `--help' option
-# and then parses the output to find possible option names. For
-# options that get an argument after a `=', the function also tries to
-# automatically find out what should be complete as the argument.
+# and then parses the output to find possible option names, so you
+# should be careful to make sure that this function is not called for
+# a command that does not support this option.
+#
+# For options that get an argument after a `=', the function also tries
+# to automatically find out what should be complete as the argument.
# The possible completions for option-arguments can be described with
# the arguments to this function. This is done by giving pairs of
# patterns and actions as consecutive arguments. The actions specify
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~1999-03-18 8:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-03-18 8:04 Sven Wischnowsky [this message]
-- strict thread matches above, loose matches on Subject: below --
1999-03-18 7:04 Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199903180804.JAA28000@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).