> So I propose this as a universal quoting scheme:
>
> \ where 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 horri
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
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/script
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
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 cha
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
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:
> 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
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 again
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 rememb
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
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 anyw
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 \ to escape
> _any_ character, in every co
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
str
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 allo
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 t
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
> fil
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 ei
18 matches
Mail list logo
