Pathnames

Files on Unix systems all live in a single tree. Hard drives, networked filesystems and imaginary files invented by the kernel are all mounted onto the same tree.

There are two types of file path: absolute paths (which start with a slash) and relative paths (which don't). And there's one type of separator in paths, the forward slash.

Microsoft Windows is... different.

Dealing with the last issue first, the busybox-w32 README says:

• Use forward slashes in paths: Windows doesn't mind and the shell will be happier.

On the other hand, the Unix shell uses the backslash as an escape character, which makes using them in paths inconvenient. You either need to use double backslashes or put your path in single quotes so the backslash isn't treated as special. Using forward slashes is much simpler.

• Simpler for you, not necessarily for me. A constant stream of issues has been raised about why particular commands output pathnames with backslashes. Some of them have been fixed.
• Here's a trick you might find useful. It's possible to drag a filename from the Windows File Explorer into a command prompt window. Of course, the pathname uses backslash separators. But wait, the busybox-w32 shell editing command Ctrl+Z turns all backslashes on the current line into forward slashes. Magic!

Drive letters (e.g. C:)

represent hard disks and removable media like floppy disks (ask your grandparents) and USB sticks.

Shares (e.g. //HOST/Share)

represent networked filesystems. Paths of this form are known as UNC paths (where UNC stands for Universal Naming Convention).

With this knowledge we can define an absolute path in Windows: it's one that starts with a root specifier (drive or share) followed by a slash. Thus the following are absolute paths:

   C:/Users/rmy
   C:/Windows/System32
   //NAS/Media/thing.mp4

Before looking at relative paths in Windows there's one other concept we need to consider: the current working directory.

• The shell in Unix (indeed, any process) maintains an idea of its current working directory. This is an absolute path which refers to a directory. It's the place 'relative paths' are 'relative to'. It's also the reason a relative path is ambiguous. To know what a relative path refers to you need some additional context: the current directory.

  The shell builtin cd allows you to change the current working directory and pwd prints it.

• The Windows Command Prompt (cmd.exe) also has the notion of a current directory but with a couple of significant differences:
  • As on Unix it must be an absolute path, but only those starting with a drive letter are allowed. If you try to cd to a UNC path you'll get an error. A share can be accessed if it's mapped to a drive letter.
  • Windows maintains a current directory for each drive (including those mapped to shares) but not for shares.
• The shell in busybox-w32 makes some allowance for Windows' quirks:
  • As an extension to the behaviour of Command Prompt it does allow the current directory to be a share.
  • The pwd builtin takes an optional -a argument to print the current directory of all drives. Without -a it only prints the current directory for the current drive.

• The one that's most similar to a Unix relative path is the type that doesn't start with a root specifier or a slash (e.g. path/to/file). It's relative to the current directory of the current root.
• A form that's unique to Windows starts with a drive letter that isn't followed by a slash (e.g. C:path/to/file). This is relative to the current directory of the specified drive.
• Thirdly, there's a path that has no root specifier and starts with a single slash (e.g. /path/to/file). This is relative to the current root. On Unix it would be an absolute path.

  To avoid ambiguity busybox-w32 applies special treatment to paths of this form in certain cases:

  • Hardcoded references to Unix-style paths within busybox-w32 (e.g. /etc/profile) are treated as relative to the system drive, the one specified in the SYSTEMDRIVE environment variable. This can be overridden by setting the BB_SYSTEMROOT environment variable.
  • The shell detects attempts to run executables from paths traditionally used to store binaries on Unix (e.g. /bin/sh) and runs the corresponding applet, if it exists.
  In other cases such paths are interpreted according to Windows conventions.