Another fun related one: If your username is Tyler and you run shutdown, instead of the usual message it will say "Oh, good morning Mr. Tyler, going down?"
Discovered this in college when I was shoulder surfing a coworker who always used the username Tyler. When he typed shutdown I called it out, and he said, "wait, it doesn't do that for you? I always assumed it said that for everyone and just replaced the username!".
(For those of you too young to know, it's a reference to an Aerosmith song)
Personally I think ubiquitous software is even more important to have Easter eggs, because they're the most widely distributed, and we want as much joy as we could possibly have, before you know.
No, proper easter eggs don't introduce security issues, they're benign almost by definition. I think what made them disappear was the introduction of all the suit-wearing people who decide what the programmers are supposed to program, with no room for autonomous work within that.
Proper code doesn't either, and yet there they are! The point is they added another attack surface, however small, and another code path that should be tested.
When people started to care about 100% test coverage, they started to disappear.
> The point is they added another attack surface, however small, and another code path that should be tested.
I dunno, "attack surface" to me means "facilitate opening/vulnerability somehow" and none of the easter egg code I've seen has done that. You have any concrete examples where a easter egg made possible a security vulnerability that wouldn't be possible otherwise?
But yes, another code path created by easter eggs that wasn't tested I've seen countless of times, but never been an issue, but maybe our easter eggs always been too small in scope for that.
Or they were removed for other reasons than security.
In Star Trek: 25th Anniversary, we had a hidden animation of Captain Kirk's toupee jumping off his head and running out of the room. It was caught before release and they made us take it out since no one wanted to piss off William Shatner.
It should make you wonder instead about the appropriateness of testing over man(1) output, I suppose unless you're actually generating the format for use as man(1) input, in which case congratulations on your functional tests doing their job!
One very important section number is 5 - it's for file formats. So if you forget the crontab format, you need to invoke `man 5 crontab` to read about it.
In fact, the only reference to crontab(5) is in the SEE ALSO section (on my version anyway), but that doesn't say why you might want to see crontab(5), just that it exists. That is spectacularly useless
Depends. If one is aware of the meaning of section numbers, that "(5)" is very obviously suggesting that there is a file format named "crontab" which is documented. It's also pretty reasonable to suppose that the command and the file format of the same name are related.
A novice might miss the convention and the connection. Man pages are not quite novice material.
Maybe they could update man files so that it lists crontab(file format) instead of crontab(5)? Whenever I've seen numbered man pages in the past, I thought it was just a page number in the manual for the program
Hell, you don't even have to have a handle on what the section numbers mean for these things to be useful. The appearance of something in a "SEE ALSO" section indicates that the manual page author thought that that thing was both related to the thing being documented and worth reading if the current man page didn't answer all of your questions.
I can't count the number of times that following the trail laid out by 'SEE ALSO' sections a step or three has lead me to the exact thing that I never knew I needed to be using. Chasing those sections down is almost always well worth the three to ten minutes spent.
And, like, if one is expecting a man page to cover in detail everything even vaguely related to what it documents, and one doesn't feel one has ten minutes to spend reading things that people thought were important to bring to your attention... well, I guess one could go ask an LLM to slop out some related words. That'll probably take less than ten minutes, though correctness is not at all guaranteed.
That is incredibly stupid. A documentation system designed by someone who doesn't understand how people use documentation.
If man was designed by someone with any taste at all it would at least give you a menu to select (1) crontab command, (5) crontab file format. Maybe we need a rewrite in Rust to fix that.
And since man pages could take minutes to print out, if you needed one you'd tear that section of paper off and keep it in a binder for future (and faster) reference.
Programs these old are controlled by people who are very strongly opposed to change, even if it improves things. They like living in the 80s.
I absolutely guarantee if you propose this change the the GNU neckbeards who control man they will come up with some bullshit technical reason why it can't be done.
And maybe we need some versions: man version 1, man version 2 and so on. And of course, in the style of GTK, each one incompatible with all the others. Progress. /s
Incidentally, man --help on my machine shows "-k, --apropos equivalent to apropos", which isn't very useful. I know the two are equivalent, because they're on the same line of switches, what does it actually do?
With some further man digging, apropos is actually a separate program that looks through man page names/descriptions for the argument. Unless you run it with no arguments, in which case it just outputs "apropos what?" Instead of an actual error message like "No search term provided" or something
> Incidentally, man --help on my machine shows "-k, --apropos equivalent to apropos", which isn't very useful.
That's your hint to execute either 'man apropos' or 'man man'. Both tell you in detail what the flag and utility do.
You seem likely to be very disappointed in the '-h'/'-H' output of utilities from the BSD tradition. The output is often a list of all of the (almost always exclusively short) options presented as a sea of characters... and nothing else.
I mean, most of the -h/--help texts I've read are generally pretty good. Obviously not a full documentation for the program, but they tell you what the switches do. I wish there was a consensus on whether to use -h or --help though
My favorite piece of man trivia is from the source of the tunefs BSD man page, which contains:
.\" Take this out and a Unix Daemon will dog your steps from now until
.\" the time_t's wrap around.
.Pp
You can tune a file system, but you cannot tune a fish.
There was also the record You Can Tune a Piano, but You Can't Tuna Fish by REO Speedwagon, I had assumed that's what the tunefs man page was referencing as that was a best-selling record at around the time Unix was being developed.
Interestingly, the section doesn't actually have to start with a number. TCL man pages use the 'n' section and 'man' resolves them just fine despite the ambiguity. Conversely, manpage names can also start with numbers, although this is rare (I found only one such example: man 30-systemd-environment-d-generator)
may be a better version of what you propose, depending on what you're looking for. On my system, this also gives me entries from sections like '3x' and '3ossl' and '3bsd'.
Cool. And GNU "info" is a hyperlinked doc viewer system. Some GNU and other projects promote info doc as more authoritative than man pages. Man pages are expanded cheat sheets.
For in-depth doc, I do appreciate docset-based indexed search apps like Dash that can download and update comprehensive doc locally with greater performance and less internet dependency than internet only. There's even vim and nvim plugins to bring that to them too without leaving the terminal.
Note that this is contrary to the convention used in the Erlang community, where the number is used to disambiguate function definitions with different parameter counts, e.g. in https://www.erlang.org/docs/18/man/supervisor.html we see definitions of `start_link/2` and `start_link/3`.
It is a stylistic convention to always add this number to any reference to a function, even if there is only one definition.
Remarkable that no one yet here, including the article author, reports the true origin of these section numbers: they identified (depending on section size, one or a group of) physical binders in the series published by AT&T to document System V UNIX, and when you got an update to your system software, it came with a package of new manual pages which you would physically install in the binders to replace the now-superseded older versions. Everything you hate about man pages is in consequence of that origin, and of the corollary that the online version was never designed to be authoritative.
I have one of those physical binders, a volume of Section 3 for an AT&T 3B2, in the software section of my library downstairs. A beautiful artifact in every respect, of the level of quality you would imagine in the manual for a machine that cost $15,000 in the 80s.
That may "answer" a specific question. And all llms can do as they include manpages in training data (and any Agentic thing can search) however the value in reading documentation is that one can find different angles by learning about different options, which allow tontackle problems from a different perspective. The answer to a question is constrained by assumptions which are part of the question.
If you like man trivia (and why else would you be reading this?) you could check out the top comment at https://unix.stackexchange.com/questions/405783/why-does-man...
(discussed at https://news.ycombinator.com/item?id=27994194)
Another fun related one: If your username is Tyler and you run shutdown, instead of the usual message it will say "Oh, good morning Mr. Tyler, going down?"
Discovered this in college when I was shoulder surfing a coworker who always used the username Tyler. When he typed shutdown I called it out, and he said, "wait, it doesn't do that for you? I always assumed it said that for everyone and just replaced the username!".
(For those of you too young to know, it's a reference to an Aerosmith song)
This was removed years ago from sysvinit, for political reasons.
"The developer of the man-db, Colin Watson, decided that there was enough fun and the story won't get forgotten"
Haha! Adequate amount of fun was provided, please resume regular man activities.
Reading this makes me wonder if Easter eggs are ever appropriate for something as ubiquitous as man.
Personally I think ubiquitous software is even more important to have Easter eggs, because they're the most widely distributed, and we want as much joy as we could possibly have, before you know.
Easter eggs are always appropriate but it is imperative (and important) to understand how they could affect anything and everything.
Which means you need to usually make it explicit to call them (man --abba or something) than something that "surprises" the user.
Almost everything had an easter egg in it back in the day. When computing was more fun and less serious.
They fell out of favor when people realized they were a security issue, because it was a code path that rarely got tested.
No, proper easter eggs don't introduce security issues, they're benign almost by definition. I think what made them disappear was the introduction of all the suit-wearing people who decide what the programmers are supposed to program, with no room for autonomous work within that.
> proper easter eggs don't introduce security issues
Proper code doesn't either, and yet there they are! The point is they added another attack surface, however small, and another code path that should be tested.
When people started to care about 100% test coverage, they started to disappear.
> The point is they added another attack surface, however small, and another code path that should be tested.
I dunno, "attack surface" to me means "facilitate opening/vulnerability somehow" and none of the easter egg code I've seen has done that. You have any concrete examples where a easter egg made possible a security vulnerability that wouldn't be possible otherwise?
But yes, another code path created by easter eggs that wasn't tested I've seen countless of times, but never been an issue, but maybe our easter eggs always been too small in scope for that.
The most famous is the Xbox hack that was only possible because of an Easter Egg:
https://security.stackexchange.com/questions/144202/are-ther...
Microsoft code. The "hacker" went for the lower hanging fruit.
Or they were removed for other reasons than security.
In Star Trek: 25th Anniversary, we had a hidden animation of Captain Kirk's toupee jumping off his head and running out of the room. It was caught before release and they made us take it out since no one wanted to piss off William Shatner.
It should make you wonder instead about the appropriateness of testing over man(1) output, I suppose unless you're actually generating the format for use as man(1) input, in which case congratulations on your functional tests doing their job!
A great innovation over simple AB testing
> (... less common section numbers)
One very important section number is 5 - it's for file formats. So if you forget the crontab format, you need to invoke `man 5 crontab` to read about it.
... because if you do `man crontab` you get section 1, which does not document the crontab fields.
In fact, the only reference to crontab(5) is in the SEE ALSO section (on my version anyway), but that doesn't say why you might want to see crontab(5), just that it exists. That is spectacularly useless
> That is spectacularly useless
Depends. If one is aware of the meaning of section numbers, that "(5)" is very obviously suggesting that there is a file format named "crontab" which is documented. It's also pretty reasonable to suppose that the command and the file format of the same name are related.
A novice might miss the convention and the connection. Man pages are not quite novice material.
Maybe they could update man files so that it lists crontab(file format) instead of crontab(5)? Whenever I've seen numbered man pages in the past, I thought it was just a page number in the manual for the program
Hell, you don't even have to have a handle on what the section numbers mean for these things to be useful. The appearance of something in a "SEE ALSO" section indicates that the manual page author thought that that thing was both related to the thing being documented and worth reading if the current man page didn't answer all of your questions.
I can't count the number of times that following the trail laid out by 'SEE ALSO' sections a step or three has lead me to the exact thing that I never knew I needed to be using. Chasing those sections down is almost always well worth the three to ten minutes spent.
And, like, if one is expecting a man page to cover in detail everything even vaguely related to what it documents, and one doesn't feel one has ten minutes to spend reading things that people thought were important to bring to your attention... well, I guess one could go ask an LLM to slop out some related words. That'll probably take less than ten minutes, though correctness is not at all guaranteed.
That is incredibly stupid. A documentation system designed by someone who doesn't understand how people use documentation.
If man was designed by someone with any taste at all it would at least give you a menu to select (1) crontab command, (5) crontab file format. Maybe we need a rewrite in Rust to fix that.
There are a multitude of manpagers and viewers and frontends. It's one of those things you can write yourself very easily.
Any that have this feature? I did try batman but it only replaces the pager; not the man frontend which is where this change would need to happen.
>If man was designed by someone with any taste at all
man was designed at a time you likely can't conceive of.
Can you even imagine designing something that's being actively used and talked about a HALF CENTURY later?
> If man was designed by someone with any taste at all it would at least give you a menu [...]
My goodness. Man was written on a paper teletype.
And since man pages could take minutes to print out, if you needed one you'd tear that section of paper off and keep it in a binder for future (and faster) reference.
So? That didn't stop `man -a`.
I hope this was just some over the top sarcasm.
No of course not. Why do you hope that?
Or a minor alteration to an existing program to support a good suggestion.
Why is it that the Rust community thinks that the solution to every flaw in an application is a rewrite in Rust?
It might be more helpful to write a Rust-based snark detector first.
Could be, but I don't think so in this case given a cursory review of the parent poster's history.
Programs these old are controlled by people who are very strongly opposed to change, even if it improves things. They like living in the 80s.
I absolutely guarantee if you propose this change the the GNU neckbeards who control man they will come up with some bullshit technical reason why it can't be done.
> even if it improves things.
odds are, it doesn't.
Exactly the sort of response I would expect to this very clear improvement.
It does that, depending on implementation.
It seems it has been done already a while ago without waiting for the rust community to do their usual churn.
https://imgur.com/a/kEkmRxx (link shows a screenshot of khelpcenter showing the different manpages available for crontab)
Really? I can't see your image (thanks UK government) but if I type `man crontab` in a recent Ubuntu it just shows crontab(1).
He said "khelpcenter", not "man".
Ok well we were discussing man, not khelpcenter, so that seems irrelevant...
We were discussing replacing man, so a replacement that does as requested is very relevant.
> Maybe we need a rewrite in Rust to fix that.
And maybe we need some versions: man version 1, man version 2 and so on. And of course, in the style of GTK, each one incompatible with all the others. Progress. /s
man -k crontab is the real trick here. shows both sections so you don't have to already know the number exists.
It only shows a description though.
Incidentally, man --help on my machine shows "-k, --apropos equivalent to apropos", which isn't very useful. I know the two are equivalent, because they're on the same line of switches, what does it actually do?
With some further man digging, apropos is actually a separate program that looks through man page names/descriptions for the argument. Unless you run it with no arguments, in which case it just outputs "apropos what?" Instead of an actual error message like "No search term provided" or something
> Incidentally, man --help on my machine shows "-k, --apropos equivalent to apropos", which isn't very useful.
That's your hint to execute either 'man apropos' or 'man man'. Both tell you in detail what the flag and utility do.
You seem likely to be very disappointed in the '-h'/'-H' output of utilities from the BSD tradition. The output is often a list of all of the (almost always exclusively short) options presented as a sea of characters... and nothing else.
I mean, most of the -h/--help texts I've read are generally pretty good. Obviously not a full documentation for the program, but they tell you what the switches do. I wish there was a consensus on whether to use -h or --help though
My favorite piece of man trivia is from the source of the tunefs BSD man page, which contains:
https://github.com/freebsd/freebsd-src/blob/main/sbin/tunefs...You can tune a fish, it's that the command for that is fish_config instead.
I guess the joke is you can scale a file system or a fish, but can only tune a file system?
Tuna is a type of fish so the joke is that they sound the same.
There was also the record You Can Tune a Piano, but You Can't Tuna Fish by REO Speedwagon, I had assumed that's what the tunefs man page was referencing as that was a best-selling record at around the time Unix was being developed.
Yes. It had been a popular joke in the US, I believe about a generation before. (Probably the joke came in around the same time as canned tuna.)
I looked up what the numbers mean a couple of times, but always forget it immediately
Section meaning varies somewhat widely by *nix flavor.
Interestingly, the section doesn't actually have to start with a number. TCL man pages use the 'n' section and 'man' resolves them just fine despite the ambiguity. Conversely, manpage names can also start with numbers, although this is rare (I found only one such example: man 30-systemd-environment-d-generator)
The POSIX standard manual pages for the utilities can be found here:
https://pubs.opengroup.org/onlinepubs/9799919799/idx/xcu.htm...
These would all be in section 1, if I am correct.
Thousands of keystrokes saved by not having to type “man syscall”… and millions of hours lost by confused folks like OP (and myself)
Luckily hours lost by the incompetent don't amount to much.
Needless obscurity is not a virtue
For me man(3) is the most interesting of them all.
Run `apropos . | grep "(3)"`; you'll be surprised how many libraries come with man pages for their functions (e.g; curl).
Now I wonder if there are any IDEs that can automatically dial into these man pages and pull up documentation for functions?
There's guaranteed to be some sort of context-sensitive man plugin for vim &| nvim for shell scripts.
Also, have you ever seen the DOS Borland IDE context sensitive help UX?
I think for Vim, it’s “K”. But for emacs, you only need to use “m-x man” and have a nice viewer.
Cool. And GNU "info" is a hyperlinked doc viewer system. Some GNU and other projects promote info doc as more authoritative than man pages. Man pages are expanded cheat sheets.
For in-depth doc, I do appreciate docset-based indexed search apps like Dash that can download and update comprehensive doc locally with greater performance and less internet dependency than internet only. There's even vim and nvim plugins to bring that to them too without leaving the terminal.
Note that this is contrary to the convention used in the Erlang community, where the number is used to disambiguate function definitions with different parameter counts, e.g. in https://www.erlang.org/docs/18/man/supervisor.html we see definitions of `start_link/2` and `start_link/3`.
It is a stylistic convention to always add this number to any reference to a function, even if there is only one definition.
Remarkable that no one yet here, including the article author, reports the true origin of these section numbers: they identified (depending on section size, one or a group of) physical binders in the series published by AT&T to document System V UNIX, and when you got an update to your system software, it came with a package of new manual pages which you would physically install in the binders to replace the now-superseded older versions. Everything you hate about man pages is in consequence of that origin, and of the corollary that the online version was never designed to be authoritative.
I have one of those physical binders, a volume of Section 3 for an AT&T 3B2, in the software section of my library downstairs. A beautiful artifact in every respect, of the level of quality you would imagine in the manual for a machine that cost $15,000 in the 80s.
Step 1: Read `man man`
Step 2: Feel the urge to write an article about that
I admire people who do that.
Writing down what you learn cements knowledge, and sharing what you write might help someone else.
Ideally, read or write while listening to https://en.wikipedia.org/wiki/Man_Man
Is there a man man man article that will explain how to read man man?
The full documentation for man is maintained as a Texinfo manual. If the info program is properly installed at your site, the command
Ah that crap is/was so rage inducing!I'm feeling old now.
Confession. I think I haven't read manpages since stackoverflow and certainly not since LLMs.
Perhaps the modern version of "man" should be a program you can talk to.
That may "answer" a specific question. And all llms can do as they include manpages in training data (and any Agentic thing can search) however the value in reading documentation is that one can find different angles by learning about different options, which allow tontackle problems from a different perspective. The answer to a question is constrained by assumptions which are part of the question.
My experience with LLMs is that they often give me different angles that I didn't think of.
Please no. I want to read the manual without having to talk to anything.
It's called Claude. Or Gemini-cli. Or any other agent capable of running man.
"Hey <agent>, use `man` to help answer these questions about grep"
How do you think llms reply to you?
i have made llms read manpages, it is great lol