5 ms·
> If you take a filename in C, and then have to display it somewhere, you're facing the same problem If you have such problem, it is often better to ignore it
by zajio1am 6y ago
> If you take a filename in C, and then have to display it somewhere, you're facing the same problem
If you have such problem, it is often better to ignore it and pass data around without any conversion (to force data to be valid utf-8). For example, if i have ls-like tool, who just read filenames and display it, then it will work even with non-utf-8 filenames when used like:
for A in $(ls-like) ; do ...
But if the ls-like too tries to be smart to interpret data when they are displayed to stdout then it will break them.
- estebank 6y agoDoing that is how you end up with binary data being interpreted as escape sequences, either mangling the screen or, when unlucky, putting your shell in a seemingly unresponsive state. https://unix.stackexchange.com/questions/79684/fix-terminal-after-displaying-a-binary-file https://unix.stackexchange.com/questions/79684/fix-terminal-...
- int_19h 6y agoIf you're merely passing the data, sure. But the scenario I described was specifically displaying data. For the terminal, your approach would only work if the expected encoding of the filename is the same as the output encoding of the terminal - which is not always the case. But then there's also GUI etc. Ultimately, some bit of code (e.g. the terminal emulator) will still need to interpret that filename as a string in order to display it as one - and if it's not really a string, it won't be able to do that properly. Filenames are part of the UX - the filesystem a user-facing artifact, not an implementation detail - so they have to be constrained in such ways that make sense for humans, even if arrays of octets would do just fine as unique IDs.