Syntax patch for 'find' syntax issues.

Project:	JNode Core
Component:	Code
Category:	task
Priority:	normal
Assigned:	Unassigned
Status:	closed

The Argument flags code has been extended to support subclass-specific flags and mapping strings to flags.
The accept and complete methods now take a 'flags' argument that is OR'ed with the Argument's declared flags.
The constructors for ArgumentSyntax and related syntax types now take a 'flags' parameter (String). This can be used in an XML syntax descriptor to add more flags to those specified by the command class; e.g. " ... argLabel="foo" flags="EXISTS,ALLOW_DODGY_NAMES".
A new flag has been defined for FileArgument to implement a "file names don't start with '-'" check. In fact, this is now the default: the flag disables the check.

The net result is that the current 'find' command syntax will now report "find . -name foo" as an error, saying that "-name" is an "unexpected or unrecognised option".

Please try this patch out and let me know if you think it improves things.

Attachment	Size
syntax-patch.txt	57.6 KB

#1

Submitted by Stephen Crawley on Sat, 04/11/2009 - 04:32.

This comment includes a new version of the patch, extended to do the following:

Argument subclass-specific flags can now be non-overridable.
FileArgument has a new non-overrideable flag which says that "-" should be treated as a special case. This similar to Cluster's feature request in issue #2958, but it doesn't "break" the semantics of the EXISTING flag. (Well it does ... but only at the explicit request of a command class.)

Please give this patch a try ASAP. If nobody says it is a bad idea, I'll commit it tomorrow.

Attachment	Size
syntax-patch.txt	60.25 KB

#2

Submitted by cluster on Sat, 04/11/2009 - 09:05.

I like it. Im curious though, what did you have in mind when you added the flags attribute to option and optional?

I'll mark the other issue as fixed, as this satisfies that issue.

#3

Submitted by Stephen Crawley on Sat, 04/11/2009 - 13:30.

I'm curious though, what did you have in mind when you added the flags attribute to option and optional?

The primary reason was that they both use MuArgument or MuPreset which (now) take a 'flags' word in their respective constructors. (Not a good reason).

I'll take another look to see if the attribute is really justified.

Update:. It is OptionSyntax and VerbSyntax that get the flags word in their constructor in addition to ArgumentSyntax. In both cases, the syntax binds an argument. In the case of OptionSyntax, the argument could easily be any Argument type and hence could require extra flags. In the case of VerbSyntax, it is not clear that extra flags would be any use, but it does no harm.