4 ms·

Seeming as newlines may appear in file names, it is a good use. Otherwise something as mundane as a bug in program A (which produces a file name with a newline)

by II2II 2y ago

Seeming as newlines may appear in file names, it is a good use. Otherwise something as mundane as a bug in program A (which produces a file name with a newline) has a potential to expose a bug in program B (which fails to interpret a file name with a newline).

tyre 2y ago
At some point it feels fine that code fails. If you’re writing shell scripts against file names that you don’t control and someone puts a new line, that’s on them. They’re asking for a bad time.
- inopinatus 2y ago
  Many shell scripts we write run as root, or as a deployment user (which is often privileged in terms of its access to business-critical code, packages, data stores, user uploads). Or they may be supplied for use as utilities by folks with other domains of expertise. We should never plan to enable the possibility of uncontrolled outcomes due to bad/hostile third-party input; moralising blame after an incident isn't a productive activity.
  - Filligree 2y ago
    Maybe the kernel should be fixed to refuse filenames with newlines in them, if there are no other use cases…
    - inopinatus 2y ago
      The option (and it would have to be an option) to do so doesn't sound like an unreasonable defense-in-depth measure, but given the myriad Unix and Unix-like variants in the world, and the possibility that your code may not be running on such a configured target system[1], we still end up having to have adequately defensive basic coding standards. Honestly, though, it's one reason I write a lot of my own scripts in zsh these days. Zsh has its own quirks, and I don't touch oh-my-zsh with a barge pole, but it's a darn sight quicker to reason about expansions in zsh code compared to bash, especially if arrays are in the mix. Unfortunately zsh is not necessarily available everywhere and certainly remains outside the base install of many *nix distros. [1] we can prove the existence of at least one such device, by construction: it's the CI/CD host on which tests run, because those tests themselves may specifically and intentionally be for safe handling of such filenames, and therefore rely on being able to instantiate them
    - SAI_Peregrinus 2y ago
      Rather, the POSIX specification should be fixed to exclude `\n` from filenames, instead of just `/` and `\0`.
deleted 2y ago
[deleted]

by II2II 2y ago

tyre 2y ago

At some point it feels fine that code fails. If you’re writing shell scripts against file names that you don’t control and someone puts a new line, that’s on them. They’re asking for a bad time.

inopinatus 2y ago
Many shell scripts we write run as root, or as a deployment user (which is often privileged in terms of its access to business-critical code, packages, data stores, user uploads). Or they may be supplied for use as utilities by folks with other domains of expertise. We should never plan to enable the possibility of uncontrolled outcomes due to bad/hostile third-party input; moralising blame after an incident isn't a productive activity.
- Filligree 2y ago
  Maybe the kernel should be fixed to refuse filenames with newlines in them, if there are no other use cases…
  - inopinatus 2y ago
    The option (and it would have to be an option) to do so doesn't sound like an unreasonable defense-in-depth measure, but given the myriad Unix and Unix-like variants in the world, and the possibility that your code may not be running on such a configured target system[1], we still end up having to have adequately defensive basic coding standards. Honestly, though, it's one reason I write a lot of my own scripts in zsh these days. Zsh has its own quirks, and I don't touch oh-my-zsh with a barge pole, but it's a darn sight quicker to reason about expansions in zsh code compared to bash, especially if arrays are in the mix. Unfortunately zsh is not necessarily available everywhere and certainly remains outside the base install of many *nix distros. [1] we can prove the existence of at least one such device, by construction: it's the CI/CD host on which tests run, because those tests themselves may specifically and intentionally be for safe handling of such filenames, and therefore rely on being able to instantiate them
  - SAI_Peregrinus 2y ago
    Rather, the POSIX specification should be fixed to exclude `\n` from filenames, instead of just `/` and `\0`.

deleted 2y ago

[deleted]