From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] rev3: support colon in filenames Date: Wed, 15 Jul 2009 23:00:12 +0100 Message-ID: <20090715220012.GP3056@shareable.org> References: <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> <4A5E4206.20602@web.de> <20090715213635.GN3056@shareable.org> <4A5E4D33.9070901@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Kevin Wolf , Anthony Liguori , linuxram@us.ibm.com, qemu-devel@nongnu.org, kvm-devel To: Jan Kiszka Return-path: Received: from mail2.shareable.org ([80.68.89.115]:45106 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751286AbZGOWAT (ORCPT ); Wed, 15 Jul 2009 18:00:19 -0400 Content-Disposition: inline In-Reply-To: <4A5E4D33.9070901@web.de> Sender: kvm-owner@vger.kernel.org List-ID: Jan Kiszka wrote: > Jamie Lokier wrote: > > Jan Kiszka wrote: > >>> Now, I see one significant hurdle with that: it's quite inconvenient > >>> for Windows users, typing paths like c:\path\to\dir\file, if those > >>> backslashes are stipped. > >> We could exclude Windows from this (I think to remember that filenames > >> are more restricted there anyway) or define a different, Windows-only > >> escape character. > > > > I think both of those are bad ideas, because the same management > > scripts can run on Windows, and for consistency it's not just file > > names. Even Windows has block devices and network devices :-) > > I'm not sure if there is actually so much portability/reusability > between Windows and the rest of the universe, but I'm surely not an > expert in this. In my experience, shell scripts and Perl scripts tend to work either with no changes, or very small changes. > > Fortunately "where is not ASCII alphanumeric" solves the > > practical cases where the user types an ordinary pathname. > > > > Or the user can type forward slashes just like they do in unix. > > We would still have to deal with the fact that so far '\' had no special > meaning on Windows - except that is was the well-known path separator. > So redefining its meaning would break a bit... The point is that paths tend to have alphanumeric characters at the start of each component, so it doesn't matter in most cases that it's redefined. People won't notice because c:\path\to\file will continue to work, whether it's by itself or part of a multi-option option. Exceptions are \\host\path and \\.\device, where the error will be so obvious they'll learn quickly. We could find a more complex scheme where \\ is unaffected, but complex is not good and will be wrongly implemented by other programs. Whereas \ is very common, well known and easy to get right, even when people guess how it's done, like they do when working out how to quote paths for rsync and ssh. Oh, I'm suddenly thinking that "." should be included in "alphanumeric" :-) -- Jamie