mjhjmtu

I use a very simple makefile with TeX:

test-makefile:
 echo 'newcommandseanceseance1' > seances/seance.tex

I run it:

$ make test-makefile 
echo 'newcommandseanceseance1' > seances/seance.tex

My problem is that the file created in the folder named "seances" does not contain the two first characters it should contain:

 
ewcommandseanceseance1

The first line of it being empty.

Of course I can protect the first antislash: echo '\newcommandseanceseance1, etc. But in the real world it does not work: my real makefiles (I have posted an ECM) don't work.

What happens? How can bash/debian misunderstand the beginning of the command?

By the way:

$ bash --version
GNU bash, version 4.4.19(1)-release (x86_64-pc-linux-gnu)
 
$ cat /etc/debian_version
buster/sid
 
$ uname -a
Linux giljourdan 4.16.0-1-amd64 #1 SMP Debian 4.16.5-1 (2018-04-29) x86_64 GNU/Linux

Your echo is one of those that interprets backslash-escapes. A n means a newline, so you get exactly that. The latter backslash comes as-is, since s isn't a valid escape code.

Make runs the commands through a shell, using /bin/sh by default, and on Debian that's dash. Dash's builtin echo does process backslashes. Bash's doesn't. (And neither does the external /bin/echo on Debian, not that it matters unless you explicitly run /bin/echo).

Your best bet is to use printf explicitly, it's at least safe in that it always processes backslash-escapes. The below should always do the same thing, the \n at the start produces a real backslash and an n, the n later produces a newline to end the line.

foo:
 printf '\newcommandn' > foo

(or, if you want to avoid processing backslashes, then use printf "%s" 'newcommand')

See the question Why is printf better than echo? for more details about echo gotchas.

Your echo is POSIX compliant and expands C backslash escapes. This is most likely because /bin/sh is dash instead of bash.

There is a simple fix: add another backslash to quote the backslash:

 test-makefile:
 echo '\newcommand\seanceseance1' > seances/seance.tex

Note that the POSIX standard marks the C backslash escapes for echo an XSI extension but the author of the POSIX compliance test suite claims that it is required to be XSI compliant in order to be POSIX compliant except when you like to certify only a small system for embedded use.

Since it does not seem that the original question has been asked for a small embedded system, that system would need to implement XSI extensions in order to be compliant.

Note that bash on POSIX certified platforms like Solaris and Mac OS is compiled in a way that it comes with a compliant echo by default. So the problem that bash is nor POSIX XSI compliant by default is Linux specific.