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

Andrew Cagney
2002-08-01T15:05:33Z

> 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