Name: UNIX for super-users
ISBN: 9780201142280

What Hacker News says

JdeBPJun 2018

It was simplicity, of design, implementation, use, and indeed explanation. There's only one default, the default if the --jobs option is not used; rather than there being two defaults, one for not having the option and another for having the option but not the option argument.

More generally, I try to avoid optional arguments to command options, in line with the guideline in the Single Unix Specification. (I actually picked such ideas up many years ago, before the first POSIX specification, from a book by Eric Foxley titled Unix for Super Users, where there was an appendix on command line option syntax.)

* http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_...

Of course, if the user wants to use the number of cores available, then xe can work that number out and pass it as an argument; and indeed I have done that very thing in some of the package/make scripts that I have published.

thread

JdeBPJun 2026

I have a book on my bookshelf, Eric Foxley's Unix for Super-Users. It was published in 1985, and it answers this question on page 52, the first page listed for the entry 'lost+found' in its index.

This is surely not the earliest book mention, is it? (It'll be in earlier man pages, of course.) Google Books does not give me an earlier one, although it does yield another 1985 book.

Fun fact: Foxley cautioned that lost+found must be pre-sized ahead of time, because the fsck of the time did not grow the directory to fit found files.

thread

mesrikJun 2026

Foxleys book does not actually claim reason why it need to be preallocated. I've got the book also. Index mentions fsck only page 52, where it reads:

  "52 UNIX FOR SUPER-USERS
  ...
  The filestore consistency check is performed by the command fsck (usu-
  ally stored as /etc/fsck, but sometimes in /bin), which should be used to check
  all discs used as file-systems. It defaults to the list of filestore devices given
  in the file /etc/checklist. At this stage, most of the file-systems will not be
  mounted, so will be inactive; only the root file-system will be active. The
  fsck command goes through each one in turn, reports any inconsistencies in
  them, and offers to correct them. The reply to each query is either 'y' for yes
  (correct the inconsistency), or 'n' for no (leave the file-system inconsistent).
  A parameter '-y' to the command assumes 'yes' replies to all questions, so
  that no further interaction is necessary; a parameter '-n' similarly assumes
  all 'no' answers, and therefore needs no write permission to the device. Any
  'yes' reply may involve the loss of information, such as the complete removal
  of a suspect file. Suspect files on the file-system being checked are written to
  a directory lost + found on the device if such a directory exists; this directory
  must have been created, and be sufficiently large already to hold the names
  of all the files involved. This can be ensured by first creating the directory,
  then creating a number of files in the directory, and then removing them.
  The corrected systems will be consistent, and can later be mounted as and
  when required. It may be possible to recover information from deleted files
  by looking at the lost + found directory. There should be a lost + found direc-
  tory at the head of each mountable file-system.
  When checking the root file-system, there are complications, in that it
  will be active (even though, because it is root, it will not be formally mounted
  as such, but is implicitly mounted as root during the booting process). If
  modifications are necessary, they should be completed, and the machine
  rebooted without first performing a sync (see section 4.5 below for the nor-
  mal procedure for taking a system down). This is to ensure that the disc as
  modified by fsck is not overwritten by any in-core information, which may
  have been generated from information read from the original corrupt (incon-
  sistent) version.
  ...
  "

But I've also read more detailed explanation that recollect is that unless blocks were preallocated, there was a possibility that lost+found need first allocate more blocks directory it already had, it would possibly led to losing some data that would otherwise been able to recover once fsck had advanced further from that point.

Old time UNIX systems directories were just another structured file, which a 'd' bit (like others you changed with chmod) on them, where each record was 16 bytes, which 2 first were the inode number followed by 14 bytes reserved for filename. IIRC linux also had first same limit first filesystems. You could read directory with any program, common feat was to check any odd stuff that "ls" would not show with could hexdump or "od" with some flags and print 16 bytes lines per row. That way you also could see any deleted or moved files from that directory, because directory entry was not quite long otherwise cleared but just clearing that inode reference two bytes.

A Quick look from other books that I have close me now Maurice J. Bach, The Design of Operating UNIX System (-86) contains much more about fsck and filesystem fixing issues scattered few pages in the book and what methods were used to mitigate loss of data. S.R Bourne The Unix System, no mention of fsck at all, at least by looking book automatically generated index.

It could have been some other quite old book I did read, but did not own or anything since BSD4.3-tahoe documentation I've read over the years. But sure it would be nice to read that exact reasoning again from credible sources.

edit: Oh, and you could preallocate also just by adding entries or copying some data to lost+found enough, and then remove entries. Unix traditionally have not compacted and resized directories. They only grow and can be if have been very large slow to traverse. The way to compact is creating another, moving existing data there and then swapping directories.

thread

JdeBPSep 2020

The -- mechanism in general, not specific to the cp command albeit mostly limited to programs that use getopt/popt for their argument parsing, is described all over the place. I first encountered it in a book, written by Eric Foxley, entitled UNIX for Super-Users and published in 1985.

* It's perennially asked about on Unix and Linux Stack Exchange, ranging from https://unix.stackexchange.com/q/11376/5132 almost a decade ago to https://unix.stackexchange.com/q/570729/5132 last year.

* It's in a whole bunch of duplicate questions there, including (but not limited to) https://unix.stackexchange.com/questions/linked/1519?lq=1 .

* It's in the Single Unix Specification, and has been for a long time. (https://pubs.opengroup.org/onlinepubs/7990989775/xbd/utilcon...)

* It's in the getopt(3) manual page from the Linux man-pages project. It's in the getopt(1) manual page from the util-linux project.

* It's in getopt(1) and getopt(3) in the NetBSD Manual. The same goes for the OpenBSD and FreeBSD manuals.

* It's in Blum's and Bresnehan's 2015 Linux Command Line and Shell Scripting Bible, on page 377.

* It's in Marcel Gagné's 2002 Linux System Administration: A User's Guide, on page 48.

* It's in Kirk Waingrow's 1999 UNIX Hints & Hacks.

* It was Q&A number 32 in part 2 of the Usenet comp.unix.shell FAQ document. (http://cfajohnson.com/shell/cus-faq-2.html#Q32)

Specific to the cp command, or rather to the many cp commands that you could end up using, as this is not a "bash command":

* No, the OpenBSD, FreeBSD, and NetBSD cp(1) manuals do not mention it.

* Neither does the GNU CoreUtils cp(1) manual page, as you noted. It's instead in the GNU CoreUtils doco section on "common options". The actual CoreUtils cp(1) manual doesn't mention that there even are "common options". (https://manpages.debian.org/sid/coreutils/cp.1.en.html) That's only mentioned, as an aside, in the info page. (https://gnu.org/software/coreutils/manual/html_node/cp-invoc...)

* For the cp command that is part of Rob Landley's toybox, this is covered in the introduction to the toybox(1) manual page, and there isn't really a distinct cp(1) manual page. (http://landley.net/toybox/help.html)

* No, BusyBox doesn't similarly document this for its cp command, or anywhere on busybox(1). (https://busybox.net/downloads/BusyBox.html)

* It's tangentially in several GNU CoreUtils FAQ Q&As, inasmuch as CoreUtils cp is the same as CoreUtils rm in this regard. (https://gnu.org/software/coreutils/faq/coreutils-faq.html#Ho...)

* It's tangentially in the Linux Documentation Project's Advanced Bash-Scripting Guide, again because cp is the same as rm here. (https://tldp.org/LDP/abs/html/special-chars.html#DOUBLEDASHR...)

* For an operating system where this is actually in the cp(1) manual itself, look to Solaris, and its successor Illumos, where you'll find it in the NOTES section. (https://illumos.org/man/1/cp)

* Another operating system where this is actually in the cp(1) manual itself is AIX, actually in the FLAGS table alongside all of the other flags. (https://ibm.com/support/knowledgecenter/ssw_aix_72/c_command...)

thread