zsh-workers
 help / color / mirror / code / Atom feed
* Re: Should _long_options be considered dangerous?
@ 1999-03-18  8:04 Sven Wischnowsky
  0 siblings, 0 replies; 2+ messages in thread
From: Sven Wischnowsky @ 1999-03-18  8:04 UTC (permalink / raw)
  To: zsh-workers


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


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Should _long_options be considered dangerous?
@ 1999-03-18  7:04 Bart Schaefer
  0 siblings, 0 replies; 2+ messages in thread
From: Bart Schaefer @ 1999-03-18  7:04 UTC (permalink / raw)
  To: zsh-workers

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


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1999-03-18  8:04 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-03-18  8:04 Should _long_options be considered dangerous? Sven Wischnowsky
  -- strict thread matches above, loose matches on Subject: below --
1999-03-18  7:04 Bart Schaefer

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