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.
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).
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.
Therefore, I would agree with this issue being "fixed" by adding something
like the following to the gzip documentation:
It is the responsibility of the caller to check that the file names supplied
to gzip are valid. (For example, that they do not contain unprintable
characters).
Best regards,
Antonio.
