Package: moreutils Version: 0.65-1 Severity: normal ts(1) is documented to take a `format' argument on its command line, and no other non-option arguments. In fact, if given more arguments then it won't complain about a usage error, but then won't read its standard input, and will do more or less bizarre things with the extra arguments. On the mild end of the spectrum, sometimes it will use an argument as a filename, and take input from that file (which is pointless for a regular file):
$ echo a > t0 $ ts %F t0 2023-07-17 a $ It gets weirder if an argument contains certain characters that are not usually used in filenames: $ ls -l total 4 -rw-rw-r-- 1 zefram zefram 2 Jul 17 00:45 t0 $ ts %F '>t1' $ ls -l total 4 -rw-rw-r-- 1 zefram zefram 2 Jul 17 00:45 t0 -rw-rw-r-- 1 zefram zefram 0 Jul 17 00:49 t1 $ echo c > 't2 ' $ ts %F 't2 ' Can't open t2 : No such file or directory at /usr/bin/ts line 113. $ ts %F '|echo wibble' wibble $ The details of this behaviour arise because, after failing to check for extraneous arguments, the program uses the <> Perl operator, which magically implements a variety of interpretations of command line arguments. The range of behaviour includes writing to arbitrary files and running arbitrary commands, which are very undesirable behaviours for ts(1). However, the seriousness of the problem is limited by the fact that this behaviour only arises if the program is invoked with extraneous arguments, contrary to its documentation. It might be considered desirable for ts(1) to read input from files named on the command line. (Though pointless for regular files.) If that is the case then it would not be wrong for the program to accept the additional arguments. But in that case it would still be wrong for it to use the <> Perl operator, which is not suitable for the implementation of a read-from-list-of-files kind of command, because of the variety of behaviour described above. It would also make this a more serious bug, because the dangerous behaviour such as writing to files could be invoked by attempts to read from files. It would also be a documentation bug that the possibility of naming files on the command line was not mentioned in the man page or usage message. -zefram
