8 ms·

They did the right thing for this: make the tools fail on file creation, but not on existing files. I guess it's still advisable to rename those files, I don't

by jraph 2y ago

They did the right thing for this: make the tools fail on file creation, but not on existing files. 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.

ykonstant 2y ago
If your file system allows them, be careful with symlinks though!
- jraph 2y ago
  Why, specifically? 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.
  - ykonstant 2y ago
    Oh, nothing specific to newlines. Just, when you rename files to fix newlines, you need to check if they break symlinks pointing to them. 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!
    - jraph 2y ago
      Ah, right, indeed :-)
nneonneo 2y ago
No, they did not do the right thing: > 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.
- jraph 2y ago
  > 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 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)
- deleted 2y ago
  [deleted]

by jraph 2y ago

ykonstant 2y ago

If your file system allows them, be careful with symlinks though!

jraph 2y ago
Why, specifically? 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.
- ykonstant 2y ago
  Oh, nothing specific to newlines. Just, when you rename files to fix newlines, you need to check if they break symlinks pointing to them. 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!
  - jraph 2y ago
    Ah, right, indeed :-)

nneonneo 2y ago

No, they did not do the right thing: > 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.

jraph 2y ago
> 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 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)
deleted 2y ago
[deleted]