ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject DO NOT REPLY [Bug 24231] - command-line option to signify no more options
Date Tue, 11 Nov 2003 17:44:31 GMT

command-line option to signify no more options

------- Additional Comments From  2003-11-11 17:44 -------
The usual point of -- is that it means "there are no further options past this
point in the command line". An example from the man page of the unix rm command:

To remove a file whose name starts with a ‘-’, for example ‘-foo’,  use
       one of these commands:

              rm -- -foo

              rm ./-foo

Correct me if this is not the meaning you intend, as I have misunderstood your
intent. I assume you do from this line in your patch:
+        msg.append("  -.                     signify end of options" + lSep);

So, to answer your question assuming I understand your intent and your patch
does what I think you intend (I havn't directly verified it)...

Currently targets begining with - are currently misidentified as (usually
unrecognized) options by the commandline parser. If -- was included in the
commandline before the target was specified the command line would now
understand that -targetname is a target and not an option and properly execute
it. Misidentification is the only reason targets starting with - don't execute
from the command line. They are otherwise perfectly legal targets with equal status.

Try this sometime:

<target name="-projecthelp">
  <echo message="You can't see me!"/>

With your patch I assume it would be possible to say 

ant -. -projecthelp 

and get the output:

     [echo] You can't see me!

The problem is that the -targetname "feature" is not (so far as I know) an
intentionally designed in feature with respect to "hiding internal targets", but
a coincidental side effect of command line parsing when it tries to warn the
user of typos in their options. Sadly, I just discovered that this technique of
access control was added to the documentation for the 1.5 release. IMHO Adding
'-' to the target name to prevent invoction should not have been made a
supported feature, although it now is (as of version 1.18 of using.html, and
it's subsequent release in 1.5). This practice overloads the meaning of the name
atribute, and creates a syntax within the realm of target names, which was
(until the "feature" was documented) unconstrained.

This "feature" had previously remained undocumented despite the fact that it
existed since version 1.1 of (I avoid using it myself, since I came
up with an alternate, if somewhat lenghthier, method of controling access to
targets back when 1.4.1 was the current release). Another flaw of this "feature"
is that it yeilds an error message about options rather than one indicating that
the build file writer chose not to let the user run this target directly. The
later would imply that the user should look for another target, whereas the
former looks like a mistake by the writer of the build file and seems to imply
the build should be "fixed" by changing the target name (to the newish user who
doesn't know or remember about - targets at least).

The ability to protect/hide targets from the command line user is clearly
desired by many build file authors and the "feature" is widely used. Although
the "feature" is based on an "until recently undocumented feature" it is now is
a back compatability issue. I expect that back compatability is likely to be
honored here, but even if it isn't it would be very poor form (imho) to break it
without providing an alternative. 

My patch to bug 22020 attempts to add an explicit means of specifying command
line visibility, but is being held for consideration in 1.7 because the
mechanism I propose may also be expanded or altered to allow build file writers
to specify accessibility of targets from other contexts (such as import).
Several commiters feel (I am not a commiter) that access can't be implemented
until we are comfortable with import and have a feel for how people will use it.
I have to admit that this does sound reasonable.

Resolving bug 22020 (with or without my patch) would supply an alternative
access control mechanism and thus make it possible to begin considering a minor
break in back compatability by implementing the feature you are requesting.

However, given that it is now a back compatability issue, I suspect you will
need a use case that can't be resolved with a simple work around before any
patch will be commited. I will leave it to commiters to declare this WONTFIX or
not however.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message