From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRLvt-0000vo-2N for qemu-devel@nongnu.org; Thu, 16 Jul 2009 04:03:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRLvo-0000qf-5P for qemu-devel@nongnu.org; Thu, 16 Jul 2009 04:03:12 -0400 Received: from [199.232.76.173] (port=33145 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRLvn-0000qK-UU for qemu-devel@nongnu.org; Thu, 16 Jul 2009 04:03:08 -0400 Received: from mx20.gnu.org ([199.232.41.8]:29261) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MRLvn-00079z-9R for qemu-devel@nongnu.org; Thu, 16 Jul 2009 04:03:07 -0400 Received: from mx2.redhat.com ([66.187.237.31]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MRLvm-0006SN-28 for qemu-devel@nongnu.org; Thu, 16 Jul 2009 04:03:06 -0400 Message-ID: <4A5EDE71.6050603@redhat.com> Date: Thu, 16 Jul 2009 10:01:53 +0200 From: Kevin Wolf MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] rev3: support colon in filenames References: <1245862739.6278.7.camel@localhost> <1245866233.6278.17.camel@localhost> <4A434009.5010009@redhat.com> <1245998284.6278.99.camel@localhost> <4A447C8D.5000104@kevin-wolf.de> <1246063310.6278.115.camel@localhost> <1246511321.6429.31.camel@localhost> <4A4C754D.10109@redhat.com> <4A4CAD86.9020607@us.ibm.com> <4A4CB39F.5070506@redhat.com> <20090715181405.GB3056@shareable.org> In-Reply-To: <20090715181405.GB3056@shareable.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Anthony Liguori , linuxram@us.ibm.com, qemu-devel@nongnu.org, kvm-devel Jamie Lokier schrieb: > Kevin Wolf wrote: >> Can we at least allow \, instead of ,, in parameter parsing, so that the >> backslash has the practical benefit of being a single universal escape >> character? > > Is there a good reason why we cannot simply use \ to escape > _any_ character, in every context where a user-supplied > string/name/path/file is used? > > I'm thinking of consistency here. Instead of special cases for > filenames, why not a standard scheme for all the places in command > lines _and_ the monitor where a name/path/file is needed? I absolutely agree with your intention here (maybe except Windows, haven't thought about that a lot). But from an implementation POV, this would need a major rework of the parsing code. The problem is that to do this universally you need to have one central place where everything is parsed. We currently don't have that. We have the command line parser that needs comma and equals for its parsing. We have the block code that needs the colon for protocols. We have block drivers that again separate options by colons. And so on. So currently we can't handle backslashes when parsing command line options. They would be missing in the block code for escaping colons. We can't handle all colons in the generic block code, the stripped backslashes would be missing in vvfat and nbd. Once we have decided what the solution should look like (including Windows and other problems), it might be worth the effort. But I can promise that it's going to be much more than just one patch. Kevin