You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
`find -print0` is not POSIX, but supported systems include:
- GNU/Linux systems, using GNU findutils
- Other Linux-based systems using BusyBox find (e.g. Alpine Linux)
- BSD systems, including macOS (all versions, since 10)
Since this is a Bash script, and even the old versions of Bash on
macOS systems support `read -d ''` to read null-byte-delimited
input, assuming `find -print0` is supported everywhere needed, this
is highly likely to work everywhere needed. It allows filenames to
be safely read even if they contain weird characters including
newlines, as can happen accidentally (hopefully not intentionally).
It would be nicer to loop through the result of a recursive glob
(globstar, **), but Bash only supports that starting in version 4,
which no version of macOS ships (or is likely to ship).
The benefit of this approach, compared to the `find -exec` way used
before, is that the code is simpler, no longer needs to call itself
as a subprocess through find, and no longer needs a help to clarify
a mode that is not meant to be used from the outside. (It may also
be slightly faster.)
This makes some behavioral changes, in areas where the design had
been driven by the implementation rather than the other way around:
- We stop on the first failure.
- Because of that, there is no need to restate what files could not
be generated (it is at most one, and the failure should show it).
- As noted above, this script can no longer be invoked to process
an individual file (which as not a design goal), and it therefore
no longer accepts any command-line arguments (they are ignored).
This also fixes a misspelling the big first_line_ends_crlf comment.
0 commit comments