Anthony Liguori wrote:
Jan Kiszka wrote:
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...
That's the problem. You will break existing Windows
Anthony Liguori wrote:
Jamie Lokier wrote:
So instead of consistency, you like the idea of using different
quoting rules for the monitor than for command line arguments?
Your proposal breaks Windows in a catastrophic way. It's almost certain
that all existing front-ends/scripts will
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 \char to escape
_any_ character, in every
So I propose this as a universal quoting scheme:
\char where char is not ASCII alphanumeric.
No thank you. This sounds dangerously like the windows command shell quoting
rules. At first clance they appear to just work, however when you actually
try to figure out what's going on it gets
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
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
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
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
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
Jan Kiszka wrote:
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...
That's the problem. You will break existing Windows users.
I know this goes
Anthony Liguori wrote:
Jan Kiszka wrote:
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...
That's the problem. You will break existing Windows
Jamie Lokier wrote:
Anthony Liguori wrote:
Jan Kiszka wrote:
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...
That's the problem. You
Anthony Liguori wrote:
Jamie Lokier wrote:
Anthony Liguori wrote:
Jan Kiszka wrote:
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...
Jamie Lokier wrote:
So instead of consistency, you like the idea of using different
quoting rules for the monitor than for command line arguments?
Your proposal breaks Windows in a catastrophic way. It's almost certain
that all existing front-ends/scripts will stop working after such a
Ram Pai schrieb:
Problem: It is impossible to feed filenames with the character colon because
qemu interprets such names as a protocol. For example filename scsi:0, is
interpreted as a protocol by name scsi.
This patch allows user to escape colon characters. For example the above
filename
Kevin Wolf wrote:
Ram Pai schrieb:
Problem: It is impossible to feed filenames with the character colon because
qemu interprets such names as a protocol. For example filename scsi:0, is
interpreted as a protocol by name scsi.
This patch allows user to escape colon characters. For example
Anthony Liguori schrieb:
Kevin Wolf wrote:
Ram Pai schrieb:
Problem: It is impossible to feed filenames with the character colon because
qemu interprets such names as a protocol. For example filename scsi:0, is
interpreted as a protocol by name scsi.
This patch allows user to escape
Problem: It is impossible to feed filenames with the character colon because
qemu interprets such names as a protocol. For example filename scsi:0, is
interpreted as a protocol by name scsi.
This patch allows user to escape colon characters. For example the above
filename can now be expressed
18 matches
Mail list logo
