[bug #16505] Line-continuation backslashes are not stripped

[anonymous]

Follow-up Comment #10, bug #16505 (project make):

Keeping the newline + discarding the backslash would be a reasonable
behavior. That would spare most inline scripts.

If precedent is desirable, however, I think the old behavior is perfectly
defensible. It's worked that way forever, various Unix systems do it
identically, and it allows a useful idiom. Sure, you can't embed newlines in
the string---but how often is this useful? And what good is it if a backslash
is forced before every one? (I can't even think offhand of what Unix tools
will ignore a backslash at the end of a line...)

Ultimately, I don't see who is being served by this enforcement of POSIX.
It's a loss of functionality, and backwards compatibility, for no
corresponding gain other than POSIX compliance. And those who really care
about compliance would be no less satisfied if it were enabled with
POSIXLY_CORRECT, as that's already the case with most other GNU tools where
the standard is relevant.

I think that's about as strong a case as I can make, so I'll leave it at that
before horse-beating ensues. Let me just finish by saying, however, that if
this is to stand, it's going to have to be disseminated much more broadly
than a NEWS file. My first reaction to this change was that it was clearly,
obviously, undeniably a bug; others will react similarly. Perhaps have
make(1) print a warning when it sees such a multi-line string, maybe only if
the command fails. But something to immediately make clear that "this is not
a regression, but a deliberate change whose purpose is to follow the Posix
specifications."

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?func=detailitem&item_id=16505>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/