Reading the manual, and asking the machine what it is

The manual is a library, not a book

The UNIX manual is divided into numbered sections, and the same name may appear in more than one of them meaning entirely different things. That is not sloppiness; it is the whole design. A page's header prints as NAME(section) — see LS(1) and you know immediately that ls is a user command rather than a system call.

As a rough guide to where you will live: ordinary users read section 1; programmers read 2 and 3; administrators read 1, 4, 5 and 8.

Worked example: getting the right read

Ask for read with no section and you get whichever page the search order reaches first — on most Linux systems, the shell built-in documented in section 1 (or inside bash's own page):

$ man read
READ(1P)

That is not what a C programmer wanted. The read system call — the one with the signature ssize_t read(int fd, void *buf, size_t count) that you will use in Part II of this course — lives in section 2, and you have to ask for it. Here is where the variant matters, and this is worth committing to memory because the three families genuinely disagree:

• Linux (and POSIX-conforming systems generally): the section is a bare number before the name — man 2 read.
• Solaris: man -s 2 read — lower-case -s, with a space.
• PC-BSD / FreeBSD: man -S2 read — upper-case -S.

The same trap sits under passwd: man passwd gives you the command that changes a password (section 1), while man 5 passwd gives you the format of the account file /etc/passwd (section 5). If you wanted to know what the colon-separated fields mean, only the second page answers you.

When you do not know the name at all, search by keyword: man -k socket (equivalently apropos socket) lists every page whose one-line description mentions it. whatis read prints just those one-line summaries for the name, across every section it appears in — which makes it the fastest way to discover that a name is ambiguous in the first place.

Inside a page, Space scrolls, / searches and q quits. A page is laid out in a fixed order — NAME, SYNOPSIS, DESCRIPTION, then options, files, exit status, errors, examples, and SEE ALSO — and SYNOPSIS is the part you should learn to read first, because it is the command grammar from the previous lesson, written down.

Asking the machine what it is

Three different questions get confused with each other here. Keep them apart.

What hardware architecture is this? uname -m prints the machine hardware name as the running kernel reports it: x86_64 for a 64-bit x86 kernel, i686 or i386 for a 32-bit one, aarch64 for 64-bit ARM. arch is a synonym for uname -m on Linux.

Is my environment 32-bit or 64-bit? getconf LONG_BIT prints the width of a long in the current environment — literally 32 or 64, with nothing to interpret. This is the cleaner answer to the question as usually asked, because it answers about the environment you are actually running in rather than about the kernel's own build.

The distinction is real and it is where the marks are: a 32-bit userland can run on a 64-bit kernel. There, uname -m says x86_64 (the kernel is 64-bit) while getconf LONG_BIT says 32 (your programs are not). On Linux, lscpu shows both facts at once — Architecture: for the running kernel and CPU op-mode(s): 32-bit, 64-bit for what the silicon can do.

Which kernel is this? uname -r prints the kernel release and nothing else — 6.8.0-45-generic. Its neighbours print more: uname -s the kernel name (Linux), uname -v the build version string, and uname -a all of it together — name, hostname, release, version, machine. If a question asks for a command that prints the version and nothing else, -r is the answer and -a is the wrong one.

dmesg, and why it is the roundabout route

dmesg prints the kernel ring buffer — the running log of messages the kernel itself emits, starting with the banner it printed as it booted. That banner carries the release, the compiler it was built with, and the build date — but dmesg prints the whole buffer, hundreds of lines of it, so you need a way to keep only the line you want.

That is what a pipe is for, and this is the first place in the course you need one. Writing A | B runs both commands at once and connects A's standard output to B's standard input, so B reads what A wrote instead of reading a file. grep pattern prints only the lines of its input that contain pattern, and it reads standard input whenever you give it no filename — so the two compose:

$ dmesg | grep -i 'linux version'
[    0.000000] Linux version 6.8.0-45-generic (buildd@lcy02) ...

One line out of hundreds, and it carries the kernel version. That is the whole of what you need here; module 7 develops redirection and pipes properly — the descriptor table underneath them, >, <, 2>&1, and pipelines of more than two stages. Two caveats you should state whenever you offer this: the buffer is a ring, so on a machine that has been up a long time and logged heavily the boot banner may have been overwritten; and on most current distributions unprivileged dmesg is restricted (the kernel.dmesg_restrict sysctl), so you may need sudo dmesg. If you simply want the version, uname -r reads it directly and needs no privilege at all.