On 2025-08-19 12:55:42 +0200, Antonio Diaz Diaz wrote: > Paul Eggert wrote: > > On 8/13/25 07:49, Vincent Lefevre wrote: > > > $ touch "$(printf "file\e[H\e[c\n\b")" > > > $ gunzip file* > > > > Not sure it's gzip's job to sanitize file names that the user gave it. > > Pretty much every much program in the universe will output file names > > as-is, if the user tells it the file name explicitly. Why should gzip be > > an exception? > > After thinking about it, I have reached the conclusion that the command line > is an internal interface, much like memcpy. I.e., it is not directly exposed > to the outside world. The efficient way of making safe an internal interface > is to assign to the caller the responsibility to supply valid arguments.
As long as the file system allows the creation of such file names, or at least to make them visible via usual means, they must be regarded as valid. > For example, if the caller supplies to memcpy pointers to objects that > overlap, the behavior is undefined. Likewise, if the caller of gzip supplies > it with invalid file names, the behavior is undefined. (The caller of gzip > can be the user or another program). Pointers are under the control of the developer. Not the filenames, which may come from external sources. BTW, even undefined behavior in programming may be a very bad idea. It is mostly there for efficiency reasons. There are programming languages that avoid such issues. > The case of tools like 'ls' or 'mv' is different. They must accept invalid > file names because they are the means to check and rename files to give them > valid names. They should not be different, as being standard utilities. This would introduce an inconsistency in the handling of files. For admin purpose, there could be additional utilities (or the same utilities with options to make such files visible) if one considers that such files should normally be hidden. -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / Pascaline project (LIP, ENS-Lyon)
