I guess it's still advisable to rename those files, I don't know how things like cp, mv or rsync will behave when copying such files in the future.
I'm convinced we will need to be careful with symbolic links related to new line characters in filenames, but I'm curious of which specific aspect you had in mind.
For instance, I had project folders for my individual research projects. In order to have a central repository of resources and not have copies of multi-megabyte pdfs in each folder, I put all referenced papers in a single directory and symlinked them for each project that needed them. Later, I wanted to rename the papers to remove newlines. The symlinks complicated this process quite a bit!
> the following utilities are now either encouraged to error out if they are to create a filename that contains a newline, and/or encouraged to error out if they are *about to print a pathname that contains a newline* in a context where newlines may be used as a separator
It then proceeds to list a bunch of utilities including diff, file, find, grep, head, du, etc., none of which create files directly.
These utilities could be updated to reject newlines in file paths if they're going to print in a "newline delimited" form - but for some of these utilities, that's the only available form.
But that's already broken. This is a situation where filenames with newlines in them are indistinguishable from two filenames in outputs. So instead of producing subtly broken output, tools are encouraged (not forced) to explicitly fail with a lot of noise.
The "in a context where newlines may be used as a separator" part of this sentence is very important.
IIUC the tools are still allowed to succeed in non broken situations, for instance when a null separator is used and not a new line character. And I can't imagine the tools you listed will start breaking in situations that worked (apart from file creation - indeed this will likely start breaking, and new line characters in filename needs to be considered deprecated and things using them to be fixed).
This is strictly better IMHO (if one thinks that newlines in files are not worth the troubles given how things work in POSIX, especially the part where things are line-based and new line characters have quite some significance)
"On the number of
associative foobars
of degree blah -
Johnson and Anderson.pdf"
all the time. It is very convenient for non-technical academics to have a descriptive file name, and to be able to see it entirely in the navigator they use newlines.
While we cannot avoid that people hit the spacebar when writing a filename on a gui, this does not mean at all that the resulting filename itself need contain a plain space character. Those spaces can and should be transparently translated to non-breaking space characters at some point. Maybe by the gui itself, or more robustly by the filesystem. This would make everybody happy: gui users and naive shell script writers.
Why? This just introduces more complexity and interoperability headaches for seemingly no reason.
In order to preserve the sacrosanct simplicity of naive shell scripts. Seems like a very noble goal to me.
The only unexpexted compexity arises when you want to deal with filenames having mixed spaces and nbsps. But I'd say that people who do that had it coming.
The filesystem is way more important than /bin/sh and and any complexity added there will trickle down to all programs, not just shell scripts.
It's not worth adding hacks on the FS to patch defects in poorly written shell scripts (which are being replaced en masse with python/nodejs/even weirder yaml files/systemd units/etc... anyways)
To mishandle spaces you have to split an input w/ filenames by whitespace, which is not that common of an operation outside of a shell.
If you actually test this, you'll realize a ton of Windows programs get it wrong.
Also, in general this is a poor argument. The goal of Linux isn't to be as much like Windows as possible, because Windows sucks ass. Nobody in their right mind would use Linux if it was just Windows but, presumably, shittier. The entire appeal of Linux is that it isn't Windows, and it isn't MacOS.
Even zsh has fixed this. It's just /bin/sh and bash that are annoying.
sh-3.2$ f='Hello world'
sh-3.2$ echo $f
Hello world
sh-3.2$ for i in $f; do echo $i; done
Hello
world
sh-3.2$ f='Hello\xC2\xA0world'
sh-3.2$ echo $f
Hello world
sh-3.2$ for i in $f; do echo $i; done
Hello world sh-3.2$ f='Hello world'
sh-3.2$ echo "${f}"
Hello world
sh-3.2$ for i in "${f}"; do echo "${i}"; done
Hello world
sh-3.2$If I had it, I would use it today.
1. naming things
2. cache coherency
3. off-by-one errors
???
4. quoting pathnames
> dir c:\progra~1
So if forcing people to handle spaces was the goal, it took a long time to force it.
Edit: now I remember the most basic way: open the pdf, select and copy the title, click on rename and paste from clipboard. Works great to get the file name with the newlines exactly as they are on the title!
I just opened a folder in file explorer, clicked 'rename' and then tried the following combinations: Enter L Ctrl + Enter L Alt + Enter Win + Enter R Ctrl + Enter R Alt + Enter
None of them let me put new lines in the filename - it either did nothing, or 'closed' the rename view.
(And if they're that incompetent, why does the article imply they are worth quoting and listening to?)
Users care about "titles" or "summaries" of files, not "filesystem identifiers"; as long as the two are conflated, non-technical users will use the identifier to write titles and thus make the file easy to locate in an interactive GUI. Meta tags are not even in the cognitive horizon of most people.
And no I'm not going to copy that here for you to quip "that's not a legitimate use case". Make an effort to make a point and support it with better justification than "because I said so".
For example, it contains a directory where all file and subdirectory names are in unary, consisting only of repetitions of the newline character. A correct script should be able to enumerate, access and modify files in there without issue.
to surprise the next person or script to do "rm -rf $TMPDIR/foo"...