Re: misinterpretation of shell $'...' escape form

[Paul Smith]

On Sat, 2022-10-15 at 22:41 +0300, Poor Yorick wrote:
> on an Ubuntu 22.04 system, GNU Make 4.3, Bash 5.1.16(1)

GNU make, like all POSIX compliant makes, does not run bash.  It runs
the shell provided in the make variable (not the shell variable!)
SHELL.  That value is, by default, /bin/sh which is defined to be a
POSIX-conforming shell.  Note that the shell you ran to _invoke_ make
is irrelevant: it would be a portability disaster if make always used
whatever shell was in use when it was invoked.

On some systems, such as Red Hat (and I guess perhaps Arch but I don't
know), /bin/sh is just a link to /bin/bash and these shells are the
same thing.

On other systems, such as Debian and Ubuntu, /bin/sh is not bash but
instead dash which is a smaller, faster, POSIX-conforming shell without
all the extra features provided by bash.

The command "echo" is not well-defined by the POSIX standard when it
comes to handling special characters, and different implementations
including the built-in implementations in various shells, behave
differently when showing non-ASCII characters; not all versions of echo
or shell support the "$\n" escape sequence.

One solution is to force the shell to be bash on all systems (which
have bash installed) by adding this to your makefile:

  SHELL := /bin/bash

But a better way to go is to write your recipes using portable POSIX
operations rather than bash-specific operations: switch from echo to
using printf where the behavior is well-defined regardless of the
shell.  Probably you just want this:

  help:
        printf '$(subst $(newline),\n,$(cmd1))\n'