I think that providing an exit status that is not 0 when zcat is used with an uncompressed file is useful. Though my opinion is less strong regarding whether it should write more text after an error occurred, it’s probably more useful for a process to terminate quickly when an error occurred rather than risk a second error occurring and making troubleshooting harder.
I suppose that it’s not bad to change documentation to be more specific, and change a program such that it matches the new documentation and wouldn’t cause any harm if it replaced all the existing versions of the program, but makes it possible to use the program to solve more problems. That would be to “add functionality in a backward compatible manner”.
You are also free to create new programs that are not an exact replacement for existing programs, but can enable some people to stop using one or more other programs. That would not be what I describe as stagnation.
“The cat utility shall read files in sequence and shall write their contents to the standard output in the same sequence.”, so I would be very annoyed if it did something different with a certain file but not others. I wouldn’t say that the contents of a file and the contents after the file is expanded are the same.
In fact, I expect that some people use cat to process compressed files, and changing how cat acts with compressed files would probably cause them a large amount of annoyance, and would needlessly make a lot of existing documentation incorrect.
I think that providing an exit status that is not 0 when
zcatis used with an uncompressed file is useful. Though my opinion is less strong regarding whether it should write more text after an error occurred, it’s probably more useful for a process to terminate quickly when an error occurred rather than risk a second error occurring and making troubleshooting harder.I think that trying to change any existing documented features of widely used utilities will lead to us having less useful software in the future (our time is probably better spent making new programs and new documentation): https://www.jwz.org/doc/worse-is-better.html https://en.wikipedia.org/wiki/Worse_is_better
Not improving existing software leads to stagnation.
It’s certainly a good part of why so much of linux is an awkward kludgy idiosyncratic mess to use.
Whatever the first implementation does ends up being a suicide pact by default.
Another option is to change cat to auto decompress compressed files, instead of printing gibberish.
What operating system should I use with my laptop that isn’t an awkward kludgy idiosyncratic mess? I would say that Windows has plenty of kludges, like having problems with certain file names. Many versions of macOS are UNIX® Certified Products (for example, macOS version 15.0 Sequoia on Intel-based Mac computers and on Apple silicon-based Mac computers), so it’s surely not any less kludgy than Linux.
I suppose that it’s not bad to change documentation to be more specific, and change a program such that it matches the new documentation and wouldn’t cause any harm if it replaced all the existing versions of the program, but makes it possible to use the program to solve more problems. That would be to “add functionality in a backward compatible manner”.
You are also free to create new programs that are not an exact replacement for existing programs, but can enable some people to stop using one or more other programs. That would not be what I describe as stagnation.
“The cat utility shall read files in sequence and shall write their contents to the standard output in the same sequence.”, so I would be very annoyed if it did something different with a certain file but not others. I wouldn’t say that the contents of a file and the contents after the file is expanded are the same. In fact, I expect that some people use
catto process compressed files, and changing howcatacts with compressed files would probably cause them a large amount of annoyance, and would needlessly make a lot of existing documentation incorrect.