From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MRBUx-0007qu-DH for qemu-devel@nongnu.org; Wed, 15 Jul 2009 16:54:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MRBUs-0007qR-KU for qemu-devel@nongnu.org; Wed, 15 Jul 2009 16:54:42 -0400 Received: from [199.232.76.173] (port=46498 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MRBUs-0007qO-Gh for qemu-devel@nongnu.org; Wed, 15 Jul 2009 16:54:38 -0400 Received: from fmmailgate02.web.de ([217.72.192.227]:33897) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MRBUr-0000Nq-SS for qemu-devel@nongnu.org; Wed, 15 Jul 2009 16:54:38 -0400 Message-ID: <4A5E4206.20602@web.de> Date: Wed, 15 Jul 2009 22:54:30 +0200 From: Jan Kiszka 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig968F27980582884712459D4F" Sender: jan.kiszka@web.de List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jamie Lokier Cc: Kevin Wolf , Anthony Liguori , linuxram@us.ibm.com, qemu-devel@nongnu.org, kvm-devel This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig968F27980582884712459D4F Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Jamie Lokier wrote: > Kevin Wolf wrote: >> Can we at least allow \, instead of ,, in parameter parsing, so that t= he >> backslash has the practical benefit of being a single universal escape= >> character? >=20 > 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? >=20 > 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? Yeah, consistency. Very good point. >=20 > There are many examples where it would be useful if unusual characters > didn't break things, they simply worked. >=20 > Examples: -vnc unix: path, -net port: device path, -net script path, > -net sock=3D path, -net group=3D groupname, tap and bt device names. >=20 > \ is an obvious scheme to standardise on given QEMU's unix shell > heritage. It would work equally well for command line options (which > are often comma-separated) and for monitor commands (which are often > space-separated). >=20 > It would have the nice property of being easy for management > programs/scripts to quote, without them having a special list of > characters to quote, without needing to update them if QEMU needs to > quote more characters in future for some reason. >=20 > 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. >=20 > So I propose this as a universal quoting scheme: >=20 > \ where is not ASCII alphanumeric. >=20 > Shell quoting is easy: >=20 > qfile=3D`printf %s "$file" | sed 's/[^0-9a-zA-Z]/\\\\&/g'` >=20 > qemu -drive file=3D"$qfile",if=3Dscsi,media=3Ddisk >=20 > Same quoting applied when sending the monitor a command to change a > CD-ROM file or add a USB disk, for example. >=20 To me this direction looks more promising than any other proposal so far.= Jan --------------enig968F27980582884712459D4F Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkpeQgkACgkQniDOoMHTA+lVWQCdGj4ccf1N8TlcqKQ+87G5ej/f c5wAnie4a3Q2i3GiCS7ToL2T2Zzp6Bqh =lbvy -----END PGP SIGNATURE----- --------------enig968F27980582884712459D4F--