From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16414 invoked by alias); 6 Feb 2006 04:20:04 -0000 Received: (qmail 16307 invoked by uid 22791); 6 Feb 2006 04:20:02 -0000 X-Spam-Check-By: sourceware.org Received: from romy.inter.net.il (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 06 Feb 2006 04:20:02 +0000 Received: from HOME-C4E4A596F7 (IGLD-80-230-34-44.inter.net.il [80.230.34.44]) by romy.inter.net.il (MOS 3.7.3-GA) with ESMTP id DMQ40547 (AUTH halo1); Mon, 6 Feb 2006 06:19:57 +0200 (IST) Date: Mon, 06 Feb 2006 04:20:00 -0000 Message-Id: From: Eli Zaretskii To: gdb-patches@sourceware.org In-reply-to: <20060206024110.GB9872@nevyn.them.org> (message from Daniel Jacobowitz on Sun, 5 Feb 2006 21:41:10 -0500) Subject: Re: RFA: Support Windows extended error numbers in safe_strerror Reply-to: Eli Zaretskii References: <200602041435.k14EZ6NK016329@elgar.sibelius.xs4all.nl> <20060205001503.GB8728@trixie.casa.cgf.cx> <20060205193440.GB4718@trixie.casa.cgf.cx> <20060205202222.GB5574@nevyn.them.org> <20060205215036.GE4718@trixie.casa.cgf.cx> <20060205215659.GA7232@nevyn.them.org> <20060206024110.GB9872@nevyn.them.org> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-02/txt/msg00119.txt.bz2 > Date: Sun, 5 Feb 2006 21:41:10 -0500 > From: Daniel Jacobowitz > > > I don't see why this is confusing at all. The point is that the user > > should type the command arguments as if she were typing at the shell's > > prompt, and feel exactly the same. So I don't see why we need to > > worry about quoting--just passing the args verbatim to the shell > > should do the trick. Or am I missing something? > > This way you can't write documentation for GDB that says how the > arguments to "run" behave - you have to reference another program, > and we're not even sure which program it is half the time. I don't think it's such a grave problem. Saying it behaves "like your shell" should be good enough. Many programs have commands that invoke an inferior shell, and they all bump into this issue. We just happen to have 2 such commands instead of one. > I'd rather be able to have a chapter in the manual saying "this is how > you use globbing, if you want to", and "this is how you escape > arguments", and "this is how you redirect stderr to a file, if your > platform supports that". That'd be okay, too, but it will require to write a shell-compatible command-line parser.