[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: quotearg.c's shell_quoting_style and MinGW

From: Eli Zaretskii
Subject: Re: quotearg.c's shell_quoting_style and MinGW
Date: Sun, 06 May 2012 20:54:48 +0300

> From: Bruno Haible <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> Bcc: address@hidden
> Date: Sun, 06 May 2012 19:41:39 +0200
> Eli Zaretskii wrote:
> > The rare situation where it doesn't (described by "cmd /?")
> Rare or not - the text that you refer to mentions that the following
> characters need to be quoted as well when passing through cmd.exe:
>   &()[]{}^=;!'+,`~

Aren't these all handled by quotearg, after the changes that I sent?
If not, which ones did I miss?

> And they forgot to mention at least % which also has an interpretation.

The % character only needs quoting if you have %FOO%, _and_ FOO
happens to be defined as an environment variable.  Otherwise, it will
be preserved.

When % does need to be quoted, it cannot be in the way on which
quotearg's design is based, because "%FOO%" will still expand the

> That's why I'm saying that when passing through cmd.exe you need a
> more complex quoting.

With the exception of %, you don't.

> > A command line such as
> > 
> >   diff -r -x foo\ bar foo gaz
> > 
> > is impossible on MS-Windows
> I was assuming a Cygwin or MSYS shell with diff.exe being a native Windows
> program.

I don't see a need to support such a mix; life is too short and too
hard.  These Posix-like environments have their own versions of diff
and diff3, which use the original Posix code.  People who mix them are
asking for trouble.

> But you are splitting hairs.

Are you sure it's me who's splitting hair? ;-)

>   1) We don't want to change the default output of 'diff' on Unix.

Of course.  The change I suggested fits this requirement.

>   2) We don't want 'diff' to produce different output on Windows than on
>      Unix (modulo end-of-line convention),

I think this is fundamentally wrong: the required compatibility will;
certainly break some uses of 'diff's output.  That is a wrong way of
handling the kind of conflict between two requirements that we have
here.  Correct functionality should come before identical form, since
the latter is nothing more than convenience.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]