Whatever the first implementation does ends up being a suicide pact by default.
I agree. The behavior of rm and cat and cp and mv and dd and many other utilities don’t necessarily have the interface I would prefer, but they are too widely used for it to be helpful to radically change them. It’s somewhat unfortunate that these names are already reserved, but I don’t think it’s necessary to change them.
Because of this, I’m not afraid to use names like “getRequest” or “result”, especially if they were generated with an automatic refactoring, and I’m not upset when I see similarly generic names being used with source code I’m changing, since I know that the second name for something that’s similar to an existing thing will have to actually be descriptive, but the first name is likely to not be.
I can imagine that someone would find a program like this to be useful, and depends on the presently common behavior of zcat, so I expect this is an important part of a system used by a corporation I interact with (and probably many more than I’d expect):
if
zcat ./file.txt.gz >/dev/null
then
process_file ./file.txt.gz
elseprintf'%s\n'"There was a decimal exit status of ${?}"fi
I agree. The behavior of
rmandcatandcpandmvandddand many other utilities don’t necessarily have the interface I would prefer, but they are too widely used for it to be helpful to radically change them. It’s somewhat unfortunate that these names are already reserved, but I don’t think it’s necessary to change them.In the same way, I don’t have a problem with packages having generic names but not actually being useful: I’ve read that the
requestsandurllib3packages for Python aren’t being maintained very well, but I don’t mind that as long as I can accomplish things while following best practices.Because of this, I’m not afraid to use names like “getRequest” or “result”, especially if they were generated with an automatic refactoring, and I’m not upset when I see similarly generic names being used with source code I’m changing, since I know that the second name for something that’s similar to an existing thing will have to actually be descriptive, but the first name is likely to not be.
I have another example of how I’d apply these thoughts: the process for developing v2+ modules for the Go programming language strikes me as inelegant, so I would probably prefer to just create an entirely new repository rather than try to attempt that.
Well in this particular case, zcat failing with error on uncompressed text isn’t a behaviour worth preserving.
It should do the expected zcat behaviour, which is just print the text.
I have a hard time imagining a scenario where you call zcat and would prefer an error rather than a useable output
I already expressed that quickly getting an exit status that isn’t 0 after an issue is encountered is probably useful.
I can imagine that someone would find a program like this to be useful, and depends on the presently common behavior of
zcat, so I expect this is an important part of a system used by a corporation I interact with (and probably many more than I’d expect):if zcat ./file.txt.gz >/dev/null then process_file ./file.txt.gz else printf '%s\n' "There was a decimal exit status of ${?}" fiA failure to understand whether something is useful is not a good reason to change it.