Re: loaddefs.el on Windows incomplete

[Eli Zaretskii]

> From: Ralf Angeli <address@hidden>
> Cc: address@hidden
> Date: Mon, 19 Dec 2005 12:23:37 +0100
> 
> * Eli Zaretskii (2005-12-18) writes:
> 
> > However, I cannot accept your patch as it stands.  First, you missed
> > the important WARNING in the comment just preceding the commands you
> > wanted to patch,
> 
> Oh great, then I'll probably have to do another upload to
> alpha.gnu.org.

Sorry, I'm confused: what upload to alpha.gnu?  What did you upload
there, and how is this discussion relevant to whatever you uploaded?

> > and thus your modified command lines will break with
> > make 3.81 (which is about to be released) and later, due to the
> > incompatible change in its behavior regarding backslash-newline
> > sequences.
> 
> You mean the changes you described in the patch to make.texi in
> <URL:http://lists.gnu.org/archive/html/help-make/2005-12/msg00031.html>?

Yes.

> In what way is this a problem.  For example it does not make a
> difference if I pass
> 
> emacs -eval "(message \
> \"foo\")"
> 
> or
> 
> emacs -eval "(message \"foo\")"
> 
> to the Bash 3.1.0 on my Debian system directly from a terminal.

Inside double quotes, it indeed will not make any difference, because
the shell removes the backslashes inside double quotes.  But in single
quotes, the shell will not remove the backslashes, so they will wind
up inside the Emacs Lisp reader, and will utterly confuse it.  Note
that, when the shell is sh.exe, lisp/makefile.w32-in uses single
quotes to quote the --eval argument in the command you wanted to
patch.

> Is this relevant for Windows systems only?

No, it is relevant to GNU Make on any platform which uses a Posix
shell (and thus on Windows when the shell is sh.exe).

However, in this specific case it is relevant only to Windows, since
makefile.w32-in is used only by the MS-Windows build.

> Does it mean that portable Makefile files all have to put their
> `emacs -eval ...' stuff into a single line?

Not just `emacs --eval ...' stuff, but _any_ command parts that are
quoted with single quotes cannot be split across multiple lines with
backslash-newline sequences.

> I am not sure about the conditions because the comment
> in lisp/makefile.w32-in mentions $(ARGQUOTE)

$(ARGQUOTE) expands to different kinds of quotes depending on the
shell in use (see nt/nmake.defs and nt/gmake.defs); the problem
happens when it expands to ', a single quote.  I didn't want to
mention a single quote literally because it does not appear in the
commands in question, so the reader might be left wandering what quote
I was talking about.

> and the patch in the email references above is mangled and reads
> 
> [...]However, note that
> +backslash-newline sequences inside command-line arguments quoted with
> address@hidden'...'} are not removed by the shell.[...]

Talk about stupid software!  The original patch I sent says this:

    +sequences, per shell quoting rules.  However, note that
    +backslash-newline sequences inside command-line arguments quoted with
    address@hidden'...'} are not removed by the shell.  Also, the MS-DOS and
    +MS-Windows ports of @code{make} @strong{do} remove backslash-newline
    +sequences when the shell to be used is not a Unix-style shell.

The mailing list software probably thought that "@code" is an email
address, and tried to conceal it.