DU(1P)

πŸ’– DU(1P) β€” the POSIX Programmer's Manual glow-up πŸ’–

okay bestie, before we even start: this page is part of the POSIX Programmer's Manual, and the Linux version of this whole interface might be different (so go read the actual Linux man page for the tea on Linux behavior), or it might not even exist on Linux at all. just so you know. 🫢


✨ NAME ✨

du β€” estimate file space usage πŸŽ€


🌸 SYNOPSIS 🌸

du [-a|-s] [-kx] [-H|-L] [file...]

πŸ¦‹ DESCRIPTION πŸ¦‹

so by default, du writes to standard output the size of the file space allocated to β€” and the size of the file space allocated to each subdirectory of β€” the file hierarchy rooted in each of the specified files. yes, that's a whole mouthful, but it's giving "tell me how much space this whole tree is eating" energy. πŸ‘‘

by default, when a symbolic link shows up on the command line or inside the file hierarchy, du shall count the size of the symbolic link itself (not the file it points to), and it shall not follow the link into another portion of the file hierarchy. no chasing. no following. we stay in our lane. πŸ’…

the size of the file space allocated to a file of type directory is defined as the sum total of space allocated to all files in the file hierarchy rooted in that directory, plus the space allocated to the directory itself.

when du can't stat() files, or can't stat() or read directories, it shall report an error condition and the final exit status is affected. a file that occurs multiple times under one file operand and has a link count greater than 1 shall be counted and written for only one entry. it is implementation-defined whether a file with a link count no greater than 1 is counted and written just once, or counted and written for each occurrence. it is also implementation-defined whether a file that occurs under one file operand gets counted for other file operands. the directory entry that gets selected in the report is unspecified. 😭 (we don't know which one it picks, and that's just how it is.)

by default, file sizes shall be written in 512-byte units, rounded up to the next 512-byte unit. yes, 512. it's historical. we'll get to that in the RATIONALE, bestie, buckle up. 🌈


πŸ’… OPTIONS πŸ’…

du shall conform to the Base Definitions volume of POSIX.1‐2017, Section 12.2, Utility Syntax Guidelines. (slay, syntax guidelines.)

the following options shall be supported:

  • -a β€” in addition to the default output, report the size of each file not of type directory in the file hierarchy rooted in the specified file. the -a option shall not affect whether non-directories given as file operands are listed. πŸ’–
  • -H β€” if a symbolic link is specified on the command line, du shall count the size of the file or file hierarchy referenced by the link. (command line links only, bestie β€” read the next one for the full send.)
  • -k β€” write the file sizes in units of 1024 bytes, rather than the default 512-byte units. the 1024 girlies stay winning. ✨
  • -L β€” if a symbolic link is specified on the command line or encountered during the traversal of a file hierarchy, du shall count the size of the file or file hierarchy referenced by the link. she follows, okay? πŸ¦‹
  • -s β€” instead of the default output, report only the total sum for each of the specified files. just the grand total, no receipts. πŸ‘‘
  • -x β€” when evaluating file sizes, evaluate only those files that have the same device as the file specified by the file operand. stay on one device, periodt.
specifying more than one of the mutually-exclusive options -H and -L shall not be considered an error. the last option specified shall determine the behavior of the utility. (last one wins, no drama, no error message. πŸ’€)

πŸŽ€ OPERANDS πŸŽ€

the following operand shall be supported:

  • file β€” the pathname of a file whose size is to be written. if no file is specified, the current directory shall be used. (no argument? we're measuring . then, bestie. 🏠)

🌈 STDIN 🌈

not used. she does not read from stdin, nope. πŸ™ˆ


πŸ“ INPUT FILES πŸ“

none. zero. nada. πŸ’œ


🧚 ENVIRONMENT VARIABLES 🧚

the following environment variables shall affect the execution of du:

  • LANG β€” provide a default value for the internationalization variables that are unset or null. (see the Base Definitions volume of POSIX.1‐2017, Section 8.2, Internationalization Variables for the precedence of internationalization variables used to determine the values of locale categories.)
  • LC_ALL β€” if set to a non-empty string value, override the values of all the other internationalization variables. (she overrides everything. main character energy. πŸ‘‘)
  • LC_CTYPE β€” determine the locale for the interpretation of sequences of bytes of text data as characters (for example, single-byte as opposed to multi-byte characters in arguments).
  • LC_MESSAGES β€” determine the locale that should be used to affect the format and contents of diagnostic messages written to standard error.
  • NLSPATH β€” determine the location of message catalogs for the processing of LC_MESSAGES.

πŸ’€ ASYNCHRONOUS EVENTS πŸ’€

default. that's it, that's the section. 😌


⭐ STDOUT ⭐

the output from du shall consist of the amount of space allocated to a file and the name of the file, in the following format:

"%d %s\n", <size>, <pathname>

🌸 STDERR 🌸

the standard error shall be used only for diagnostic messages. only for the "hey something went wrong" moments. πŸ’…


πŸ¦‹ OUTPUT FILES πŸ¦‹

none. 🫢


πŸŽ€ EXTENDED DESCRIPTION πŸŽ€

none. (iconic of her honestly, keeping it short.) ✨


πŸ’– EXIT STATUS πŸ’–

the following exit values shall be returned:

  1. 0 β€” successful completion. slay. 🌈
  2. >0 β€” an error occurred. 😭

πŸ‘‘ CONSEQUENCES OF ERRORS πŸ‘‘

default.

the following sections are informative. (iykyk β€” informative means it's the lore, not the law. πŸ“š)


πŸ’œ APPLICATION USAGE πŸ’œ

none. πŸ’…


πŸ“ EXAMPLES πŸ“

none. (I know. I wanted examples too. but there are none. 😭)


🌈 RATIONALE 🌈

okay this is the lore section, and it is long, so get comfy.

the use of 512-byte units is historical practice and maintains compatibility with ls and other utilities in this volume of POSIX.1‐2017. this does not mandate that the file system itself be based on 512-byte blocks. the -k option was added as a compromise measure. it was agreed by the standard developers that 512 bytes was the best default unit because of its complete historical consistency on System V (versus the mixed 512/1024-byte usage on BSD systems), and that a -k option to switch to 1024-byte units was a good compromise. users who prefer the 1024-byte quantity can easily alias du to du -k without breaking the many historical scripts relying on the 512-byte units. πŸ’…

the -b option was added to an early proposal to provide a resolution to the situation where System V and BSD systems give figures for file sizes in blocks, which is an implementation-defined concept. (in common usage, the block size is 512 bytes for System V and 1024 bytes for BSD systems.) however, -b was later deleted, since the default was eventually decided as 512-byte units. rip -b, you were briefly iconic. πŸ’€

historical file systems provided no way to obtain exact figures for the space allocation given to files. there are two known areas of inaccuracies in historical file systems: cases of indirect blocks being used by the file system, or sparse files yielding incorrectly high values. an indirect block is space used by the file system in the storage of the file, but that need not be counted in the space allocated to the file. a sparse file is one in which an lseek() call has been made to a position beyond the end of the file and data has subsequently been written at that point. a file system need not allocate all the intervening zero-filled blocks to such a file. it is up to the implementation to define exactly how accurate its methods are. 🫠

the -a and -s options were mutually-exclusive in the original version of du. the POSIX Shell and Utilities description is implied by the language in the SVID where -s is described as causing ``only the grand total'' to be reported. some systems may produce output for -sa, but a Strictly Conforming POSIX Shell and Utilities Application cannot use that combination. 🚫

the -a and -s options were adopted from the SVID except that the System V behavior of not listing non-directories explicitly given as operands, unless the -a option is specified, was considered a bug; the BSD-based behavior (report for all operands) is mandated. the default behavior of du in the SVID with regard to reporting the failure to read files (it produces no messages) was considered counter-intuitive, and thus it was specified that the POSIX Shell and Utilities default behavior shall be to produce such messages. these messages can be turned off with shell redirection to achieve the System V behavior. πŸ”₯

the -x option is historical practice on recent BSD systems. it has been adopted by this volume of POSIX.1‐2017 because there was no other historical method of limiting the du search to a single file hierarchy. this limitation of the search is necessary to make it possible to obtain file space usage information about a file system on which other file systems are mounted, without having to resort to a lengthy find and awk script. (imagine writing a whole find and awk script just for that. couldn't be us. πŸ’…)


🧚 FUTURE DIRECTIONS 🧚

a future version of this standard may require that a file that occurs multiple times shall be counted and written for only one entry, even if the occurrences are under different file operands. so like... watch this space. πŸ‘€


⭐ SEE ALSO ⭐

  • ls
  • the Base Definitions volume of POSIX.1‐2017, Chapter 8, Environment Variables, Section 12.2, Utility Syntax Guidelines
  • the System Interfaces volume of POSIX.1‐2017, fstatat()

portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. in the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. the original Standard can be obtained online at http://www.opengroup.org/unix/online.html . πŸ“š

any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. to report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html . πŸ›


and that's the whole page bestie!! πŸ’–βœ¨ this one came from IEEE/The Open Group, 2017 β€” yes, 2017, the year of the page β€” so if anyone asks, that's the source and the date, mwah. πŸŽ€πŸ¦‹πŸ’… periodt.

πŸ“¦ where this page comes from