research multiline command syntax across shells

[mcandre]

The POSIX sh family supports escaped newline (\\\n) syntax for multiline commands.

Unknown support for this syntax in other shells:

• (t)csh
• PowerShell
• Command Prompt
• fish
• ion
• rc

If this syntax turns out to not be very portable, then we would want to reject it, in order to encourage more portable makefiles.

[mcandre]

So multiline rule commands require a POSIX-y shell interpreter.

fish uses backslash.

Unclear how (t)csh multilines behave.

Unclear how ion and rc multilines behave.

PowerShell, for example, uses space backtick, instead of optional space backslash.

Command Prompt uses caret.

What's amazing is that some Windows distributions of make come with a POSIX compliant sh interpreter. And we're not even necessarily talking about WSL apt make. For example, Chocolatey make. Worth looking into other make variants, including all the little Cygwin-like distributions.

(Free)BSD is goofy. The user shell defaults to csh/tsh. But /bin/sh offers a POSIX family interpreter. Unclear whether FreeBSD (b(sd))make uses a POSIX sh interpreter by default, or (t)csh.

There is an implication in the POSIX standard that commands resolve using a POSIX compliant shell interpreter. Still wary of make implementations potentially using another interpreter (cmd.exe, powershell.exe, csh, tsh, rc) by mistake.

[mcandre]

Regarding the BSD's, bmake appears to default to a POSIX compatible shell.

ksh on HP-UX, possibly sh.exe on certain Windows environments, and plain sh on everything else.

https://github.com/arichardson/bmake

[mcandre]

GNU make appears to default to sh for most UNIX-like platforms.

However, there is a lot of automagical code relating to DOS-like or OS/2 Warp-like environments, which may select a cmd.exe (command.com?) interpreter in some cases.

Need to revisit Chocolatey make's behavior in WSL, native Command Prompt, and native PowerShell.

Unclear what winget GNU make does. The gnuwin32 online documentation appears to have broken sh-utils. gnuwin32 coreutils does not feature a sh.exe or bash.exe interpreter.

[mcandre]

WSL, Command Prompt, and PowerShell, resolve the conventional GNU make packages has using SHELL equal to sh / sh.exe.

The latter two are using Chocolatey make.

[mcandre]

An early survey of the different make implementations and operating environments, appears to support POSIX sh interpretation for the bulk of make rule commands.

If we really wanted to, we could make a fuss about multiline backslashes in rule commands. For example, DOS and OS/2 Warp environments that lack access to modern, Chocolatey make may fail on rule command backslashes.

To reject multiline backslashes in rule commands, forces the user to either write a dedicated external script, or else maintain burgeoning, unwieldy long commands across too many columns.

We can treat this portability quirk as a documentation issue.