3 ms·

There was an article some time ago (also on HN) about a Linux command line tool which had an easter egg on a particular date/time - it's output was slightly dif

by 21 8y ago

There was an article some time ago (also on HN) about a Linux command line tool which had an easter egg on a particular date/time - it's output was slightly different, and this broke some build scripts in another project, and as you can imagine, it was hard to pin down. Then the easter egg was removed and people were complaining that "it's takes the fun, the human out" (as you can also see here) But what if every command line tool had an easter egg at a particular date/time? Then on every day of the year one of your tools would misbehave. Is this really what we want? What if a safety critical process gets broken because of this. A recent example: > We've noticed that some of our automatic tests fail when they run at 00:30 but work fine the rest of the day. They fail with the message "gimme gimme gimme" in stderr, which wasn't expected. Why are we getting this output? https://unix.stackexchange.com/questions/405783/why-does-man-print-gimme-gimme-gimme-at-0030 https://unix.stackexchange.com/questions/405783/why-does-man...

Fronzie 8y ago
Well, parsing strings instead of having a well-defined api is fragile, so the easter eggs won't probably the only thing breaking the scripts.
- 21 8y ago
  Except that on Linux parsing strings and piping is the way of life.
  - lima 8y ago
    People like to complain about the systemd ecosystems and I don't agree with some of their choices, but I appreciate their emphasis on D-Bus RPC instead of fragile text-based interfaces (even if it has issues on its own). This may or may not be an unpopular opinion, but I'm not particularly fond of all the string mangling going on in *NIX environments. It's great when the output format is well-defined - like many kernel interfaces - but please stop parsing "ifconfig" output!
  - ben509 8y ago
    Fortunately, if you pipe or redirect output, the filehandle won't be a terminal, so just check it with `isatty`[1]. [1]: https://linux.die.net/man/3/isatty https://linux.die.net/man/3/isatty
BugsJustFindMe 8y ago
The obvious response to this is that there are two kinds of easter eggs. The good kind doesn't do something one way a million times and then suddenly produce a different result given the same input for no good reason like your example date/time shenanigans. Unpredictable behavior is called not being dependable. Not being dependable is called untrustworthy. Software should always strive to be predictable, dependable, and trustworthy. But there have also been plenty of fun easter eggs in computing history that didn't needlessly make the software less predictable. We don't need to also throw out the baby.
- throwaway37585 8y ago
  I think it depends on the context. In video games, easter eggs are mostly fine. In utilities and tools, easter eggs are a potential source of harmful behavior and security issues.
  - wink 8y ago
    Also you can do it in a non-destructive, non-random way. Take `apt` as an example. The easter egg is running it with an undocumented flag. The "error case" is the same as mistyping a command. Sure, you could argue the return code is 0 when it should be != 0 but I'd argue a) if you're using the wrong flags it's your fault and b) if you'd hit --help by chance it would also return 0.

by 21 8y ago

Fronzie 8y ago

Well, parsing strings instead of having a well-defined api is fragile, so the easter eggs won't probably the only thing breaking the scripts.

21 8y ago
Except that on Linux parsing strings and piping is the way of life.
- lima 8y ago
  People like to complain about the systemd ecosystems and I don't agree with some of their choices, but I appreciate their emphasis on D-Bus RPC instead of fragile text-based interfaces (even if it has issues on its own). This may or may not be an unpopular opinion, but I'm not particularly fond of all the string mangling going on in *NIX environments. It's great when the output format is well-defined - like many kernel interfaces - but please stop parsing "ifconfig" output!
- ben509 8y ago
  Fortunately, if you pipe or redirect output, the filehandle won't be a terminal, so just check it with `isatty`[1]. [1]: https://linux.die.net/man/3/isatty https://linux.die.net/man/3/isatty

BugsJustFindMe 8y ago

The obvious response to this is that there are two kinds of easter eggs. The good kind doesn't do something one way a million times and then suddenly produce a different result given the same input for no good reason like your example date/time shenanigans. Unpredictable behavior is called not being dependable. Not being dependable is called untrustworthy. Software should always strive to be predictable, dependable, and trustworthy. But there have also been plenty of fun easter eggs in computing history that didn't needlessly make the software less predictable. We don't need to also throw out the baby.

throwaway37585 8y ago
I think it depends on the context. In video games, easter eggs are mostly fine. In utilities and tools, easter eggs are a potential source of harmful behavior and security issues.
- wink 8y ago
  Also you can do it in a non-destructive, non-random way. Take `apt` as an example. The easter egg is running it with an undocumented flag. The "error case" is the same as mistyping a command. Sure, you could argue the return code is 0 when it should be != 0 but I'd argue a) if you're using the wrong flags it's your fault and b) if you'd hit --help by chance it would also return 0.