DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24231>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=24231 command-line option to signify no more options ------- Additional Comments From [EMAIL PROTECTED] 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!"/> </target> With your patch I assume it would be possible to say ant -. -projecthelp and get the output: -projecthelp: [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 Main.java. (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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
