3 ms·

this is a great idea thank you

SAI_Peregrinus 3y ago
`Τĥιs ñåmè įß ą váĺîδ/ POSIX paτĥ/` is one I like using. If your scripts pass shellcheck, they'll handle those two directories without issue. Every byte (octet) other than 0x00 is valid in a path. Every byte other than 0x00 or / is valid in a file name. If you can't handle that, your script isn't compatible with all valid POSIX paths. That may be acceptable (e.g. you're generating all the paths in question), but isn't always.
- teo_zero 3y ago
  I suggest you add a trailing - (hyphen) to detect scripts unable to treat filenames separately from options.
- duskwuff 3y ago
  > Every byte (octet) other than 0x00 is valid in a path. I'd counter that there are a couple of differing levels of validity: 1. Printable ASCII alphanumerics, period, hyphen, underscore. Guaranteed to be portable anywhere and completely safe. 2. Safe ASCII punctuation (space, ~, $, etc). Usable on virtually all systems, likely to cause weird behavior in poorly written shell scripts. 3. Unsafe ASCII punctuation (< > : " \ | ? *). Disallowed on Windows, also likely to cause weird behavior when allowed. 4. Invalid UTF-8 sequences. Disallowed on macOS, not representable at all on Windows (which uses UTF-16 for filenames!), and will cause havoc in some programming languages like Python which assume that the filesystem is Unicode. 5. ASCII control characters (0x01 - 0x1e). Also disallowed on Windows, and you'd have to be nuts to use them even if they are supported.
  - saurik 3y ago
    I am pretty sure (but not 100% sure) that Windows uses UCS-2 for filenames, not UTF-16, and so it is worse than that, as you can have unpaired surrogates.
    - duskwuff 3y ago
      You're entirely correct; I was oversimplifying the (fairly horrifying) situation.
  - xmcqdpt2 3y ago
    You forgot filenames like "CON" or "aux" or "NUL" which are disallowed on Windows entirely. Also having filenames that differ in capitalization only. And hard links, don't use those. And paths that are longer than whatever is the limit on NTFS (it's not very long). IMO it's better to just avoid file systems altogether if you can and put everything in a database.
  - SAI_Peregrinus 3y ago
    Windows doesn't have a POSIX shell. Windows has subsystems to provide one, but shell scripts aren't portable to Windows in its default configuration. POSIX is not the same as "portable", certainly not "universally portable". POSIX shell scripts should be written to handle the capabilities of POSIX systems. Likewise scripts for POSIX-compliant shells, like Bash scripts. Non-POSIX shells may impose whatever restrictions they like, e.g. Windows disallows the file names CON, PRN, AUX, NUL, COM0 through COM9, and LPT0 through LPT9. Those are in your category 1 but are definitely not safe on Windows.
- xmcqdpt2 3y ago
  You should throw in a few newlines in your path for good measure.

`Τĥιs ñåmè įß ą váĺîδ/ POSIX paτĥ/` is one I like using. If your scripts pass shellcheck, they'll handle those two directories without issue. Every byte (octet) other than 0x00 is valid in a path. Every byte other than 0x00 or / is valid in a file name. If you can't handle that, your script isn't compatible with all valid POSIX paths. That may be acceptable (e.g. you're generating all the paths in question), but isn't always.

teo_zero 3y ago
I suggest you add a trailing - (hyphen) to detect scripts unable to treat filenames separately from options.
duskwuff 3y ago
> Every byte (octet) other than 0x00 is valid in a path. I'd counter that there are a couple of differing levels of validity: 1. Printable ASCII alphanumerics, period, hyphen, underscore. Guaranteed to be portable anywhere and completely safe. 2. Safe ASCII punctuation (space, ~, $, etc). Usable on virtually all systems, likely to cause weird behavior in poorly written shell scripts. 3. Unsafe ASCII punctuation (< > : " \ | ? *). Disallowed on Windows, also likely to cause weird behavior when allowed. 4. Invalid UTF-8 sequences. Disallowed on macOS, not representable at all on Windows (which uses UTF-16 for filenames!), and will cause havoc in some programming languages like Python which assume that the filesystem is Unicode. 5. ASCII control characters (0x01 - 0x1e). Also disallowed on Windows, and you'd have to be nuts to use them even if they are supported.
- saurik 3y ago
  I am pretty sure (but not 100% sure) that Windows uses UCS-2 for filenames, not UTF-16, and so it is worse than that, as you can have unpaired surrogates.
  - duskwuff 3y ago
    You're entirely correct; I was oversimplifying the (fairly horrifying) situation.
- xmcqdpt2 3y ago
  You forgot filenames like "CON" or "aux" or "NUL" which are disallowed on Windows entirely. Also having filenames that differ in capitalization only. And hard links, don't use those. And paths that are longer than whatever is the limit on NTFS (it's not very long). IMO it's better to just avoid file systems altogether if you can and put everything in a database.
- SAI_Peregrinus 3y ago
  Windows doesn't have a POSIX shell. Windows has subsystems to provide one, but shell scripts aren't portable to Windows in its default configuration. POSIX is not the same as "portable", certainly not "universally portable". POSIX shell scripts should be written to handle the capabilities of POSIX systems. Likewise scripts for POSIX-compliant shells, like Bash scripts. Non-POSIX shells may impose whatever restrictions they like, e.g. Windows disallows the file names CON, PRN, AUX, NUL, COM0 through COM9, and LPT0 through LPT9. Those are in your category 1 but are definitely not safe on Windows.
xmcqdpt2 3y ago
You should throw in a few newlines in your path for good measure.