1. 4
      1. 3

        I had soooo much trouble installing that package.

        My brain was convinced it was “ascii enema”.

        1. 2

          Also tee(1)

          1. 1

            Caution: Don’t play with this doing anything / listing anything that is private….

            By default it squirts your terminal session into the cloud… (which, in theory, is private until you sign up and explicitly make it private)

          2. 2

            Use with the -t timings-file argument, then replay with scriptreplay.

            This can be used to drive, oh, say, as a random example, phosphor(6x), to replay console sessions as a screensaver.

            This can be actually useful for system set-up / configuration. If you’re accessing a new box over a serial interface (serial-over-IP, IPMI, ILOM, etc.), you can record the entire sequence including boot, BIOS, bootloader, and kernel boot of a new system install. You can also choose the playback speed to accelerate the replayed session.

          1. 4

            The full and empty devices, also zero. Relatively well-known. /dev/null, of course. /dev/random and /dev/urandom, and their (important!) differences.

            /bin/true and /bin/false

            In some builds, Bash’s built in virtual TCP and UDP devices. These are shell rather than filesystem entities. Debian and derived distros generally disable this in build.

            The /proc and /sys trees have simply tons of goodness. You can write your own ps clone from basic tools (shell, awk, etc.) by parsing entries, in a pinch (useful on embedded distros, many modems and routers as examples).

            Among the potentially more useful items:

            • /proc/self
            • /dev/stdin (/proc/self/fd/0
            • /dev/stdout (/proc/self/fd/1)
            • /dev/stderr (/proc/self/fd/2)

            (Also: /proc/$$, for your shell’s process.)

            /proc/net/ has useful entries (arp, dev, etc.)

            /proc/mounts is quite useful when attempting to sort out what filesystems are actually mounted, especially when root is mounted read-only. This means that /etc/mtab, if a static file, isn’t updated. (On more recent systems, that’s now a symlink to /proc/self/mounts.)

            There are several system profiling tools which are little more than wrappers around queries of /proc files.

            Too many other idiosyncracies to mention. /etc/nsswitch can be an interesting source of confusion in cases, just off the top of my head.

            1. 2

              /etc/nsswitch.conf is tricky. Especially if you’re on a system with say MUSL and you also run something that expects (via static link) /etc/nsswitch.conf to exist in order to DNS resolve. It happens sometimes to docker containers.

              1. 2

                Bash’s built in virtual TCP and UDP devices

                have played a crucial role in some of those rm -rf recovery meme posts

                1. 1

                  Nice.

                  I’ve managed recovery from not quite so hosed systems. Having, say, your initrd envrionment available (on Debian, includes the dash shell and busybox) can be quite useful. It’s often mounted, though I don’t know if that will survive an rm -rf. If mounted ro it should.

                  Figuring out how to get bits onto the box is the hard part. A serial or parallel console link is another option, assuming you can launch something that will accept bytes sent there. I’ve not gone quite that far, but did once bootstrap a potato Debian install (the last to have a bootable tarball image) by uuencoding and zmodeming packages across a serial link using minicom. First to get the parallel drivers on (56 kbps is a hell of a lot better than 9600 baud), and then PLIP (multiple connections via SSH beats a single 24x80 terminal). Educational if not always precisely useful.