From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18645 invoked by alias); 1 Aug 2002 15:05:33 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 18626 invoked from network); 1 Aug 2002 15:05:28 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 1 Aug 2002 15:05:28 -0000 Received: from ges.redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id CA3B43D88; Thu, 1 Aug 2002 11:05:28 -0400 (EDT) Message-ID: <3D494E38.3080106@ges.redhat.com> Date: Thu, 01 Aug 2002 08:05:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020708 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz , david carlton Cc: Tom Tromey , gdb-patches@sources.redhat.com Subject: Re: RFA: >, >>, and "tee" operators References: <87d6te8a6o.fsf@fleche.redhat.com> <20020723202051.GA5427@nevyn.them.org> <3D3F5BDF.2050209@ges.redhat.com> <20020725031026.GA20117@nevyn.them.org> <3D401D50.4030009@ges.redhat.com> <20020725161749.GA10862@nevyn.them.org> <3D40371D.6070603@ges.redhat.com> <20020730191825.GA17620@nevyn.them.org> <3D4758A5.8050605@ges.redhat.com> <15688.4371.193070.843000@jackfruit.Stanford.EDU> <20020731163628.GA5436@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00000.txt.bz2 > 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