Jamie Lokier wrote: > 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 \<char> 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? Yeah, consistency. Very good point. > > There are many examples where it would be useful if unusual characters > didn't break things, they simply worked. > > Examples: -vnc unix: path, -net port: device path, -net script path, > -net sock= path, -net group= groupname, tap and bt device names. > > \<char> 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). > > 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. > > 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. > > So I propose this as a universal quoting scheme: > > \<char> where <char> is not ASCII alphanumeric. > > Shell quoting is easy: > > qfile=`printf %s "$file" | sed 's/[^0-9a-zA-Z]/\\\\&/g'` > > qemu -drive file="$qfile",if=scsi,media=disk > > Same quoting applied when sending the monitor a command to change a > CD-ROM file or add a USB disk, for example. > To me this direction looks more promising than any other proposal so far. Jan
Attachment:
signature.asc
Description: OpenPGP digital signature
