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

[david carlton <carlton@math.stanford.edu>]

On Thu, 01 Aug 2002 11:05:28 -0400, Andrew Cagney
<ac131313@ges.redhat.com> said:

[ In response to my comment that the 'print -x EXPRESSION' syntax
didn't break many cases and those case could be fixed with adding
parentheses. ]

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

Yes, that's true.  But keeping things simple has several implications
here:

1) Option syntax should be uniform between programs.
2) Option syntax should be uniform within a single program.
3) Option syntax should be chosen so as to make it clear when
   something is an option and when something isn't.

Point 1) suggests that option syntax should start with -.  (Or perhaps
with - in a Unix environment and / in other appropriate environments.)
Point 2) suggests that all options should start the same way.  Point
3) suggests that option syntax shouldn't start with -.  (Incidentally,
are there programming languages in which / can be a unary operator?
Not that I'm suggesting we should seriously worry about that, I'm just
curious.)  But, as we've all noticed, these are incompatible.

Daniel suggests that bending 2) to the extent that GDB does is
acceptable.  I suggest that bending 3) might be acceptable, or at any
rate isn't clearly less acceptable than bending 2).  I'm not sure
which one you want to bend, or if you see another way out of this
problem; you seem strongly against bending 2) or 3), but I doubt that
bending 1) would make too many people happy either.

> 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.)

Indeed.  And I claim that programs that need to use the print command
in a robust way could simply do
  print (EXPRESSION)
rather than
  print EXPRESSION

As you say, this adds another special case to consider; I agree that
this is unfortunate, and would be avoided in a perfect world.

> 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.

I'm admittedly not an expert about how GDB parses expressions, but I
don't really see the relevance here.  I'm not claiming that adding
parentheses will solve other existing problems with the GDB parser;
but are there really situations where GDB would parse EXPRESSION
correctly but (EXPRESSION) incorrectly?  (Here, by EXPRESSION I mean
"expression in the language that we're debugging", of course.)  I
can't reproduce the problem you mention above:

(gdb) p "foo bar"
$2 = "foo bar"
(gdb) p ("foo bar")
$3 = "foo bar"
(gdb) p ("foo bar"[4])
$4 = 98 'b'

but I would imagine that, if there are situations where GDB handles
("foo bar") incorrectly, it would also handle "foo bar" incorrectly.

Of course, this is all a bit academic now: it seems that people agree
that, for commands that take filenames, using - to start options is
reasonable, which answers the immediate question that started the
thread.

David Carlton
carlton@math.stanford.edu