Not sad to me. A program is expected to behave sensibly for all of its inputs, reliably producing its outputs. Larger systems depend on their sub components working properly. Imagine if grep had an Easter egg where it randomly output a joke 1 out of every 1,000,000 runs. How would you debug that deep in a bash script somewhere, as was the case for OP.
If you absolutely must write an Easter egg, put it in the “About” screen or the command line usage string or something… not in the program’s primary output.
Saying that it "is expected" is a rhetorical trick, projecting your personal notions onto the structure of the universe. You may expect that, but I don't.
To me, software is a community effort. Communities are made of people, and people have gloriously many motivations for their work. A spirit of play is one of those motivations, and I'm glad people honor it. Yes, it shouldn't cause much trouble along the way. But that's not because of some theory about what software it's for. It's because of the people.
A real-world program (a product of fallible humans, made for fallible humans, executing on hardware built by fallible humans and operating in unpredictable environment) is never bug-free or 100% reliable. There is always a chance that it will fail to behave sensibly—expecting otherwise is foolish and poor design. That holds with or without easter eggs.
Yea I don’t want to deal with some joker’s controlled chaos at 10:30PM before launch day trying to isolate a rare-repro bug that turns out was deliberately added. If that makes me a Grumpy Graybeard then I accept that name.
I wouldn’t want my home builder to insert an Easter egg that causes my windows to open randomly in the middle of the night on one day of the year because he found it “joyful.”
If output of man invoked without any arguments causes a critical bug right before the launch day, or the equivalent of your windows opening randomly in the middle of the night, you have much bigger things to worry about than that easter egg. (I doubt a true Graybeard would ever find oneself in such a circumstance.)
If bit flips become more common as transistors get smaller, that’s certainly going to throw a much less controlled wrench in the works.
It might not be critical bug. But it certainly could be failed build job. Which you then have to rerun wasting time or manually hunt down and waste time tracking where it comes from.
And something like this printing out in error could indicate that you have been compromised and you should lock down everything. Verify that you full system is clean and go through all of the logs.
This ad-hoc approach looks very suboptimal as a threat detection heuristic. Judging about your system’s security by whether there are binaries that behave in upredictable ways means a game of whack-a-mole against buggy programs (which is 100% of them, remember?), while letting real threats go by.
A way of making sure your binaries are trusted is supply chain security, which starts with not obtaining them through unvetted sources. If in that situation a known-trusted man says a funny joke at midnight, your spidey senses would not be triggered.
In other words, if there is a way for suspect binaries to get into your system, you have a bigger problem. If there is no such way, you can be sure it’s benign behaviour, a bug in the program, an Easter egg, or even a bit flip or some unlikely interaction of factors. If you are not sure whether you have eliminated all such ways, sure, it might seem like a cause for worry—however, I don’t think attackers you should really worry about would try to make themselves noticed through jokes with Western cultural references (or through any jokes for that matter, or in any way at all).
What makes you think they didn't read the submission?
Occurring with -w was a bug that happened to be located in the easter egg code. It wasn't the actual easter egg. If you hit it as intended, you do have bigger things to worry about.
So you could argue that it's bad to have extra lines of code because that's 0.01% more space for bugs to hide in, but 0.01% extra code is hardly something to launch objections over. Nothing about that is easter egg specific.
Yeah I’m sure that launch was going to go super great, grinch and co launching profit seeking clickable trash hole gets disrupted by man command bug and their feelings are really hurt because somebody did a whoopie cushion? Woops, saddest story i ever read, what a bunch of poor sobs
Expecting software to "behave sensibly" is your own faulty assumption. I write software and I've learned never to expect such thing in an environment, that almost anything can bug out, even including the CPU itself.
Oh please. 'man' is fundamentally different to 'grep' and if you can't see how you shouldn't be producing systems of any kind.
For starters the user of 'man' is an interactive unix user. Other than really unusual edge cases (eg processes which produce printed versions of the unix manual, and the test scripts of the OP in the stackexchange) there are no non-interactive or batch uses of man, it isn't used in pipelines or scripts etc.
Whereas grep is a staple of batch processes, scripts, cronjobs large and small as well as being a key tool for interactive use.
The Tarsnap website has the man pages for tarsnap utilities, for easy googling; they're generated basically by `man | sed`.
I would be very annoyed if the Tarsnap website was broken because someone decided to throw in an Easter egg and make the output occasionally inconsistent.
If anyone reading this is ever considering putting in an Easter egg like this: Please check if stdout is a terminal! If your output is going to a terminal, it's probably safe to be silly. If your output is going anywhere else, you should absolutely not play games.
If you absolutely must write an Easter egg, put it in the “About” screen or the command line usage string or something… not in the program’s primary output.