2

On Stack Overflow a comment to Can PowerShell Core handle ps1 files with CRLF line endings in Linux environments? asserted that executable files that use a shebang must use only the LF line ending, based on a quote from an O'Reilly book. And anecdotal evidence here at shebang line not working with cr-lf seems to bear that out.

But is that an official *nix requirement, or only the behavior on one platform? Is it documented somewhere? And surely isn't there a way around it (e.g. by adding an extra # before the line ending)?

The implication of this is that PowerShell scripts would be restricted to LF line endings if they were intended to be used cross-platform (as is now possible with the latest PowerShell). See Would it be best for PowerShell scripts to also have a shebang? here, as well as How can I use a shebang in a PowerShell script? on Stack Overflow.

Garret Wilson
  • 441

2 Answers2

1

POSIXly, the line feed is the only newline character.

Then again, hashbang lines aren't specified by POSIX, and there's variation even between different POSIXy and Unixy systems in their implementation, so some system that aims for Windows compatibility might well process them specially. (I haven't tried in ages, but I have the impression that Cygwin at least used to do some CRLF fixing. On some level, not necessarily this.)

(And then there's the Perl interpreter, which processes hashbang lines itself, in case the kernel didn't.)

In general, no, you can't rely on using an # as a comment marker to block the CR. E.g. on Linux, having a hashbang line like this

#!/bin/bash #[CR]

would just run bash with the single argument #[CR] (plus the file name), likely giving you a "file not found" error.

But it does work on some systems, like my Mac... See https://www.in-ulm.de/~mascheck/various/shebang/ for a table of the differences in hashbang processing between various systems.

ilkkachu
  • 138,973
0

POSIX Definitions (https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap03.html)

3.403 Text File

A file that contains characters organized into zero or more lines. The lines do not contain NUL characters and none can exceed {LINE_MAX} bytes in length, including the <newline> character. Although POSIX.1-2017 does not distinguish between text files and binary files (see the ISO C standard), many utilities only produce predictable or meaningful output when operating on text files. The standard utilities that have such restrictions always specify "text files" in their STDIN or INPUT FILES sections.

and

3.206 Line

A sequence of zero or more non- <newline> characters plus a terminating <newline> character.

Carriage return is not part of the line ending: it's a "non-<newline> character".

glenn jackman
  • 85,964