Re: RFA: >, >>, and "tee" operators

[Andrew Cagney <ac131313@ges.redhat.com>]

> On Wed, Jul 31, 2002 at 09:32:19AM -0700, david carlton wrote:
> 
>> So I think that, if this syntax is changed, the fact that expressions
>> could start with unary minus signs is going to cause much less
>> grumbling from users than the fact that, once the old p/x syntax gets
>> obsoleted, they'll have to convert over to typing p -x instead.

DanielJ wrote:

> Which, for the record, I never suggested - I think p/x and log -a are
> different enough uses of options that they can still both exist without
> any real inconsistency.

``log -a'' works because it is ``log -a FILE''.  A leading ``-'' in a 
file name on VMS, DOS and UNIX is very unlikely.

Problems arise when this same syntax is applied to a command that takes 
an expression:

	command -OPTION EXPRESSION

There, as DavidC noted, there is a conflict.  I think the reason (note 
I'm guessing) the ``/'' character was chosen for print et.al. was 
because it didn't conflict with any known expression.

> Don't forget that prefix `-' and `--' are valid C operators.  You
>> can't tell the difference between the above and a valid C
>> expressions.  I think that rules `-...' out.
> 
> 
> It makes '-...' undesirable, but I don't think it rules it out.  Yes,
> there are situations where what had previously been a legitimate print
> statement now becomes either a syntax error or, worse yet, remains
> legitimate but with a different meaning.  But I doubt they are all
> _that_ common, and there is an easy workaround once you're aware of
> this problem, namely enclosing your expression in parentheses.

There is an old rule ``KISS''.  At some point there are too many 
workarounds and edge cases and they are arising too frequently.

To consider a working example, the MI uses ``-''.  The syntax is loose 
enough to allow humans to enter free form commands vis:
	-mi-command -opt optarg param
However, client programs should always generate commands using the more 
robust form:
	-mi-command -opt "optarg" -- "param"
(always include ``--'', encode all parameters as quoted strings.)

--

BTW, simply adding paren around an expression doesn't really help.  GDB 
often parses expressions and files using ``strchr(' ')''.  That means 
that things like:

	EXPRESSION: ("foo bar")
	FILE: "/a b/c"

do not get handled correctly.

Andrew