You should script defensively, for when this is run on Windows or elsewhere [maybe Android] that will break this assumption.
Newlines can also be part of a filename. For extreme rigor, use find -print0 and xargs -0.
I have covered some of this here:
https://www.linuxjournal.com/content/parallel-shells-xargs-u...
(Somebody took me to the Hacker News front page for this, and nobody said that I made a mistake.)
I think you are missing the point. I wouldn't run a shellscript on Windows or any other place than the terminal I entered it into. It's an expression of something I want to do at that particular time in that particular directory.
The entire point of my post is that if I wished to write something portable and robust, I wouldn't use bash in the first place. That's not what bash is good at. But quick one-offs, holy crap is it good at that.
The most straightforward POSIX shell on Windows is the Busybox port, which uses the Almquist shell (ash) with many bashisms reintroduced.
This is said every time Bash scripting is mentioned. Why people can't get into the habit of quoting all variables in Bash is beyond me and the mention of white space makes sense; but how often, if ever, have you encountered a file name that contained a newline?
Most of the Unix tools are line oriented by default anyway and are frequently used to manipulate lists of file names and paths.
All else should be quoted, and newlines can happen, primarily from abuse. Do not trust user input!
Calling fopen() on a file with every ASCII character will work on POSIX, as long as it does not contain a null or forward slash (/). Coding defensively means that this does not crash your processing.
I was objecting to the knee jerk inclusion of warnings against file names including newlines. Has anyone encountered one in the wild that was not itself an error?