Bruno Haible via "GNU gzip discussion and bug reports." <[email protected]> writes:
> What's a normal user's reaction to such output? > > - Some users might think their file system is broken. Then they might > check with "ls". Or they might delete the file and download it again. > Or they might fiddle with backups. Etc. > > - Other users might recognize that these are octal escape sequences. > And immediately wonder why 'gzip' behaves like a program from the > 1970ies or 1980ies by > - treating non-ASCII characters as invalid (many programs did so > in the 1980ies), and > - using octal escape sequence, where the world switched to hexadecimal > escape sequences for the most part, a long long time ago. > > Is it good if 'gzip' gives the impression of being *that* old? > > What is the purpose of 'quotearg' in the first place? As far as I understand > it, it is to avoid outputting terminal escape sequences that originate from > file names (or command-line arguments) and that would possibly fake some > output in the terminal. > > But if the user is in a UTF-8 locale — which is frequent nowadays —, UTF-8 > encoded characters are *not* dangerous escape sequences that must be > backslash-escaped. > > So, the entire idea of using quotearg in the "C" locale is not useful. > > I really mean that: It's a show-stopper. You can't make a release with > a diagnostics behaviour like that. > > > What are the possible fixes for the problem? > > A) tryA.diff (attached) leads to > > $ ./gzip -d ~/Téléchargements/Jörg.png > gzip: /home/bruno/Téléchargements/Jörg.png: unknown suffix -- ignored > > It adds quotes if the file name contains spaces. > But maybe this is less that what one wants: It does not protect against > dangerous escape sequences. > > B) tryB.diff (attached) leads to > > $ ./gzip -d ~/Téléchargements/Jörg.png > gzip: /home/bruno/Téléchargements/Jörg.png: unknown suffix -- ignored > $ ./gzip -d ~/Téléchargements/B* > gzip: '/home/bruno/Téléchargements/Böse Bübchen': unknown suffix -- ignored > $ ./gzip -d ~/Téléchargements/f* > gzip: '/home/bruno/Téléchargements/foo\003bar': unknown suffix -- ignored > > This is reasonable behaviour: It uses the current locale to know which > characters it can output literally, and it uses backslash-escape sequences > in the (rare, but dangerous) case that a file name contains dangerous > escape sequences. > > I would suggest to adopt tryB.diff. > > Note that tryB.diff does not make use of the Gnulib module 'setlocale'. > You would need that module for decent behaviour on native Windows; > I understand that native Windows is of secondary importance for 'gzip'. I agree with you that we should use the locale that the user sets. The motivation is LLMs flagging every single unescaped string as a "security vulnerability". There is some merit to that argument in things like 'tar -t', which take input not controlled by the user. However, for printing arguments given by the user, the "security" argument feels like an attempt to waste peoples time. Collin
