Todd Zullinger <tmz@xxxxxxxxx> writes: > If a change like this is made, aren't we trading one group > of broken users for another? It would fix users of newer > systems at the expense of those on older systems, I would > suspect. Thanks for raising this. The description of POSIX "crontab" command, cf. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html talks about optional "file", but it is explicit that it has to be a real file, i.e. file The pathname of a file that contains specifications, in the format defined in the INPUT FILES section, for crontab entries. I would suspect that implementations may treat it as a sign to read the standard input, but I do not think that is what the above specifies. For example, description of "file" argument of another command, "diff", cf. https://pubs.opengroup.org/onlinepubs/9699919799/utilities/diff.html explicitly calls out that "-" stands for the standard input, i.e. diff [-c|-e|-f|-u|-C n|-U n] [-br] file1 file2 file1, file2 A pathname of a file to be compared. If either the file1 or file2 operand is '-', the standard input shall be used in its place. So, it is fairly clear that "crontab" wants a real file. Somebody's POSIX compliant "crontab" can be fed "-", attempt to read from a file with such a name, and legitimately fail. And on such a system, the proposed patch causes a regression. > In the end, cronie adjusted it's behavior, which was similar > to that of the newer vixie-cron, in 8b0241f (Partially > revert the behavior of crontab command without arguments, > 2021-03-17)¹. It now behaves as required by POSIX if stdin > is not a TTY. That seems like a reasonable compromise and > perhaps vixie-cron would be willing to do the same? It indeed is a pragmatic solution to use isatty() as a hint.
