Best Practices and Personal Tech Notes
by Jeffrey S. Jonas

• "du -a | grep filename" to find files, with full pathname
• "locate" instead of "find" (only if ALL the files existed before the most recent database rebuild)

1. my .bashrc
2. hard vs. soft (symbolic) links
3. file permission bits
4. essential & required reading
5. other rants
6. Silly Linux trinkets

1. "ls -i" to find the file’s i-number (the internal number that really describes the file)
2. "df ." (or file’s pathname) to find the filesystem containing the file (the last field)
3. "find <filesys> -inum <i-number> -print"
   Note: not all names may be found because you may not have permission to reach all the directories.

1. Many utilities are confused by symbolic links and default to NOT following symbolic links (such as creating backups or TAR files).
2. Unlike hard links, there’s no way to backtrack soft links since they can be ANYWHERE, even on remote systems that are offline.
3. They can point to non-existant files.
4. There’s little to no checking on their creation, allowing directory loops.

1. All the names work the same (no confusion about follow/no-follow symlinks)
2. All file names are equally valid (delete one name and the file remains so long as ANY name links to the file)
3. The link count (in ls or stat) always shows the number of names to the file
4. All the names can be found by search: find(1) or ncheck(1)
5. Only allowed on leaf-nodes (NON-directories) so the file system tree structure is guaranteed

1. Limited to files within the file system
2. Not supported by all file system types (such as FAT)

1. Works for all file types (regular file, directory, special file), even across mount points
2. May work in file system dependent ways (allowing new features such as conditional symbolic links)

1. Works for all file types (may create loops or invalid tree structures)
2. May work in file system dependent ways that are inconsistent or unexpected
3. May point to non-existant files (because they were deleted, or not mounted anymore)
4. May work differently whether it’s full or relative pathname
5. Not all utilities understand symbolic links (will usually follow them, unaware of possible consequences)

• hard links
• symbolic links including conditional/variable symbolic links such as AIX's hidden directory

S_ISUID 04000 set user ID on execution
S_ISGID 02000 set group ID on execution
S_ISVTX 01000 sticky bit
S_IRUSR 00400 read by owner
S_IWUSR 00200 write by owner
S_IXUSR 00100 execute/search by owner
S_IRGRP 00040 read by group
S_IWGRP 00020 write by group
S_IXGRP 00010 execute/search by group
S_IROTH 00004 read by others
S_IWOTH 00002 write by others
S_IXOTH 00001 execute/search by others

-   Regular file
b   Block special file
c   Character special file
d   Directory
l   Symbolic link
p   FIFO (p is for pipe)
s   Socket
w   Whiteout (relates to stacking file systems such as translucent file system)

• read allows listing the directory (ls, find, du, open/getdents, shell filename expansion).
  Directories with executable permission but NOT read permission
  allows filename access IF YOU KNOW THE FILE NAME since listing/reading the directory is forbidden.
• write allows modifying directory entries (create, delete, move, rename files in that directory)
• execute allows searching the directory (using it as part of pathname)
• sticky bit restricts file deletion to the file’s owner or directory owner
  (useful for shared directories such as /tmp, preventing people from deleting each others’ files).
  This explains sticky directory nicely.
• set group ID: citing wikipedia: setgid on directories: setting the setgid permission on a directory (chmod g+s)
  causes new files and subdirectories created within it to inherit its groupID,
  rather than the primary groupID of the user who created the file.
  This is not supported for all OS and file system types.
  
• setuser ID works similarly for certain system implementations, see wikipedia: setgid on directories.

• read allows read()
• write allows write() (file writing, modification or appending)
• set group ID sets manditory file locking enforcement
  (write(2) will block, or fail with EAGAIN if O_NONBLOCK is enabled,
  whereas advisory file locking depends on all processes to properly use flock() or fcntl() for file locking).
• execute has no meaning in this context
• set user ID has no meaning in this context
• sticky bit has no meaning in this context

• execute is required to access the file
• set user ID sets the process’ effective UID to the file’s UID (instead of inheriting it from the exec’s environment)
• set group ID similarly sets the process’ effecive GID to the file’s GID
• sticky bit used to mean “keep in swap” in old swapping systems.
  That allowed faster loading of frequently used binaries (such as the editor).
  According to wikipedia a few systems still support it, but not Linux
• read is not required (but debuggers may require it)
• write has no effect where the virtual-memory-system makes code read-only instead of COW (copy-on-write)
  (a clue: some systems allow deleting a file while executing, others don’t.)
  This may be needed for debugging live code.

• File mode handling depends on the the OS (operating system, sometimes version specific),
  the file system type (ext, resier) and the way it’s implemented on the OS.
• mount(2) options override many properties,
  such as read-only, no-set-UID, no special devices, enforce manditory file locking.
• File permissions are often supplemented by other facilities such as ACL: Access Control Lists, SELinux, tripwire, etc.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.

Anybody who has ever complained that “they don’t make things like they used to” will immediately connect with this book. Norman’s thesis is that when designers fail to understand the processes by which devices work, they create unworkable technology. Director of the Institute for Cognitive Sciences at University of California, San Diego, the author examines the psychological processes needed in operating and comprehending devices. Examples include doors you don’t know whether to push or pull and VCRs you can’t figure out how to program. Written in a readable, anecdotal, sometimes breezy style, the book’s scholarly sophistication is almost transparent.

Why did Bob Pease declare himself the Czar of Bandgaps??
Because a lot of people were repeating old mistakes in their new bandgap reference circuits. Pease has been able to cut down the repetition of old errors. From here on in, engineers have to make NEW errors. When we have the COLUMN on CZARS up on the web, we’ll link it up to this page.