Cygwin supports both Win32- and POSIX-style paths, where directory delimiters may be either forward or back slashes. UNC pathnames (starting with two slashes and a network name) are also supported. POSIX operating systems (such as Linux) do not have the concept of drive letters. Instead, all absolute paths begin with a slash (instead of a drive letter such as "c:") and all file systems appear as subdirectories (for example, you might buy a new disk and make it be the /disk2 directory). Because many programs written to run on UNIX systems assume the existance of a single unified POSIX file system structure, Cygwin maintains a special internal POSIX view of the Win32 file system that allows these programs to successfully run under Windows. Cygwin uses this mapping to translate from POSIX to Win32 paths as necessary. The mount utility program is used to to map Win32 drives and network shares into Cygwin's internal POSIX directory tree. This is a similar concept to the typical UNIX mount program. For those people coming from a Windows background, the mount utility is very similar to the old DOS join, in that it makes your drive letters appear as subdirectories somewhere else. The mapping is stored in the current user's Cygwin mount table in the Windows registry so that the information will be retrieved next time the user logs in. Because it is sometimes desirable to have system-wide as well as user-specific mounts, there is also a system-wide mount table that all Cygwin users inherit. The system-wide table may only be modified by a user with the appropriate privileges (Administrator privileges in Windows NT). The current user's table is located under "HKEY_CURRENT_USER/Software/Cygnus Solutions/Cygwin/mounts v<version>" where <version> is the latest registry version associated with the Cygwin library (this version is not the same as the release number). The system-wide table is located under the same subkeys under HKEY_LOCAL_SYSTEM. The user mount table takes precedence over the system-wide table if a path is mounted in both. This includes the setting of the cygdrive prefix. The mount command can set the POSIX root / to any directory in the Windows file system. In absence of such a mount, Cygwin maps / to the root of the current Windows working directory (for example, H:\ or \\computer\share). Normally Cygwin's setup.exe creates the initial mount point for the POSIX root. Whenever Cygwin generates a Win32 path from a POSIX one, it uses the longest matching prefix in the mount table. Thus, if C: is mounted as /c and also as /, then Cygwin would translate C:/foo/bar to /c/foo/bar. This translation is normally only used when trying to derive the POSIX equivalent current directory. Otherwise, the handling of MS-DOS filenames bypasses the mount table. Invoking mount without any arguments displays Cygwin's current set of mount points. In the following example, the C drive is the POSIX root and D drive is mapped to /d. Note that in this case, the root mount is a system-wide mount point that is visible to all users running Cygwin programs, whereas the /d mount is only visible to the current user. c:\> mount f:\cygwin\bin on /usr/bin type system (binmode) f:\cygwin\lib on /usr/lib type system (binmode) f:\cygwin on / type system (binmode) e:\src on /usr/src type system (binmode) c: on /cygdrive/c type user (binmode,noumount) e: on /cygdrive/e type user (binmode,noumount) You can also use the mount command to add new mount points, and the umount to delete them. See and for more information on how to use these utilities to set up your Cygwin POSIX file system. Whenever Cygwin cannot use any of the existing mounts to convert from a particular Win32 path to a POSIX one, Cygwin will automatically default to an imaginary mount point under the default POSIX path /cygdrive. For example, if Cygwin accesses Z:\foo and the Z drive is not currently in the mount table, then Z:\ would be automatically converted to /cygdrive/Z. The default prefix of /cygdrive may be changed (see the for more information). It is possible to assign some special attributes to each mount point. Automatically mounted partitions are displayed as "auto" mounts. Mounts can also be marked as either "textmode" or "binmode" -- whether text files are read in the same manner as binary files by default or not (see for more information on text and binary modes. The cygpath program provides the ability to translate between Win32 and POSIX pathnames in shell scripts. See for the details. The HOME, PATH, and LD_LIBRARY_PATH environment variables are automatically converted from Win32 format to POSIX format (e.g. from c:\cygwin\bin to /bin, if there was a mount from that Win32 path to that POSIX path) when a Cygwin process first starts. Symbolic links can also be used to map Win32 pathnames to POSIX. For example, the command ln -s //pollux/home/joe/data /data would have about the same effect as creating a mount point from //pollux/home/joe/data to /data using mount, except that symbolic links cannot set the default file access mode. Other differences are that the mapping is distributed throughout the file system and proceeds by iteratively walking the directory tree instead of matching the longest prefix in a kernel table. Note that symbolic links will only work on network drives that are properly configured to support the "system" file attribute. Many do not do so by default (the Unix Samba server does not by default, for example). Windows filenames invalid under Windows are also invalid under Cygwin. This means that base filenames such as AUX, COM1, LPT1 or PRN (to name a few) cannot be used in a regular Cygwin Windows or POSIX path, even with an extension (prn.txt). However the special names can be used as filename extensions (file.aux). You can use the special names as you would under DOS, for example you can print on your default printer with the command cat filename > PRN (make sure to end with a Form Feed). There is no need to create a POSIX /dev directory as Cygwin automatically simulates it internally. These devices cannot be seen with the command ls /dev/ although commands such as ls /dev/tty work fine. If you want to be able to see all devices in /dev/, you can use Igor Pechtchanski's create_devices.sh script. Cygwin supports the following devices commonly found on POSIX systems: /dev/dsp, /dev/null, /dev/zero, /dev/console, /dev/tty, /dev/ttym, /dev/ttyX, /dev/ttySX, /dev/pipe, /dev/port, /dev/ptmx, /dev/mem, /dev/random, and /dev/urandom. Some other POSIX devices, such as /dev/kmem, are planned for development. Cygwin also has several Windows-specific devices: /dev/comX (the serial ports, starting with COM1 which is the same as ttyS0), /dev/conin (Windows CONIN$), /dev/conout (Windows CONOUT$), /dev/clipboard (the Windows clipboard, currently text only), and /dev/windows (the Windows message queue). Windows NT/W2K/XP additionally support raw devices like floppies, disks, partitions and tapes. These are accessed from Cygwin applications using POSIX device names which are supported in two different ways. Up to Cygwin 1.3.3 the only way to access those devices was to mount the Win32 device names to a POSIX device name but this usage is discouraged since Cygwin 1.3.4 and only kept for backward compatibility. Beginning with Cygwin 1.3.4, raw devices are accessible by Cygwin processes using fixed POSIX device names. These fixed POSIX device names are generated using a direct conversion from the POSIX namespace to the internal NT namespace. E.g. the first harddisk is the NT internal device \device\harddisk0\partition0 or the first partition on the third harddisk is \device\harddisk2\partition1. The first floppy in the system is \device\floppy0, the first CD-ROM is \device\cdrom0 and the first tape drive is \device\tape0. The new fixed POSIX names are mapped to NT internal devices as follows: /dev/st0 \device\tape0, rewind /dev/nst0 \device\tape0, no-rewind /dev/st1 \device\tape1 ... /dev/fd0 \device\floppy0 /dev/fd1 \device\floppy1 ... /dev/scd0 \device\cdrom0 /dev/scd1 \device\cdrom1 ... /dev/sr0 \device\cdrom0 /dev/sr1 \device\cdrom1 ... /dev/sda \device\harddisk0\partition0 (whole disk) /dev/sda1 \device\harddisk0\partition1 (first partition) ... /dev/sda15 \device\harddisk0\partition15 (fifteenth partition) /dev/sdb \device\harddisk1\partition0 /dev/sdb1 \device\harddisk1\partition1 [up to] /dev/sdl \device\harddisk11\partition0 /dev/sdl1 \device\harddisk11\partition1 ... /dev/sdl15 \device\harddisk11\partition15 if you don't like these device names, feel free to create symbolic links as they are created on Linux systems for convenience: ln -s /dev/scd0 /dev/cdrom ln -s /dev/nst0 /dev/tape ... Note that you can't use the mount table to map from fixed device name to your own device name or to map from internal NT device name to your own device name. Also using symbolic links to map from the internal NT device name to your own device name will not do what you want. The following three examples will not work as expected: mount -f -b /dev/nst0 /dev/tape # DOES NOT WORK mount -f -b /device/tape0 /dev/tape # DOES NOT WORK ln -s /device/tape0 /dev/tape # DOES NOT WORK Executable program filenames end with .exe but the .exe need not be included in the command, so that traditional UNIX names can be used. However, for programs that end in .bat and .com, you cannot omit the extension. As a side effect, the ls filename gives information about filename.exe if filename.exe exists and filename does not. In the same situation the function call stat("filename",..) gives information about filename.exe. The two files can be distinguished by examining their inodes, as demonstrated below. C:\> ls * a a.exe b.exe C:\> ls -i a a.exe 445885548 a 435996602 a.exe C:\> ls -i b b.exe 432961010 b 432961010 b.exe If a shell script myprog and a program myprog.exe coexist in a directory, the program has precedence and is selected for execution of myprog. The gcc compiler produces an executable named filename.exe when asked to produce filename. This allows many makefiles written for UNIX systems to work well under Cygwin. Unfortunately, the install and strip commands do distinguish between filename and filename.exe. They fail when working on a non-existing filename even if filename.exe exists, thus breaking some makefiles. This problem can be solved by writing install and strip shell scripts to provide the extension ".exe" when needed. Cygwin, like Linux and other similar operating systems, supports the /proc virtual filesystem. The files in this directory are representations of various aspects of your system, for example the command cat /proc/cpuinfo displays information such as what model and speed processor you have. One unique aspect of the Cygwin /proc filesystem is /proc/registry, which displays the Windows registry with each KEY as a directory and each VALUE as a file. As anytime you deal with the Windows registry, use caution since changes may result in an unstable or broken system. The Cygwin /proc is not as complete as the one in Linux, but it provides significant capabilities. The procps package contains several utilities that use it. To circumvent the limitations on shell line length in the native Windows command shells, Cygwin programs expand their arguments starting with "@" in a special way. If a file pathname exists, the argument @pathname expands recursively to the content of pathname. Double quotes can be used inside the file to delimit strings containing blank space. Embedded double quotes must be repeated. In the following example compare the behaviors of the bash built-in echo and of the program /bin/echo. bash$ echo 'This is "a long" line' > mylist bash$ echo @mylist @mylist c:\> c:\cygwin\bin\echo @mylist This is a long line