Why can't my application locate cygncurses-8.dll? or cygintl-3.dll? or cygreadline6.dll? or ...? Well, something has gone wrong somehow... To repair the damage, you must run Cygwin Setup again, and re-install the package which provides the missing DLL package. If you already installed the package at one point, Cygwin Setup won't show the option to install the package by default. In the ``Select packages to install'' dialog, click on the Full/Part button. This lists all packages, even those that are already installed. Scroll down to locate the missing package, for instance libncurses8. Click on the ``cycle'' glyph until it says ``Reinstall''. Continue with the installation. For a detailed explanation of the general problem, and how to extend it to other missing DLLs and identify their containing packages, see http://cygwin.com/ml/cygwin/2002-01/msg01619.html. Why is Cygwin suddenly so slow? If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist. Using //c (for C:) doesn't work. (Similarly for any drive letter, e.g. //z for Z:) This ``feature'' has long been deprecated. For a detailed discussion of why this change was made, and how deal with it, refer to http://sources.redhat.com/ml/cygwin/2001-09/msg00014.html. Just note that, in contrast to what that posting claims, using / as the cygdrive prefix is not supported anymore for a long time (though it still might work). Why can't my services access network shares? If your service is one of those which switch the user context (sshd, inetd, etc), then it depends on the method used to switch to another user. This problem as well as its solution is described in detail in the Cygwin User's Guide, see . Workarounds include using public network share that does not require authentication (for non-critical files), providing your password to a net use command, or running the service as your own user with cygrunsrv -u (see /usr/share/doc/Cygwin/cygrunsrv.README for more information). How should I set my PATH? This is done for you in the file /etc/profile, which is sourced by bash when you start it from the Desktop or Start Menu shortcut, created by setup.exe. The line is PATH="/usr/local/bin:/usr/bin:/bin:$PATH" Effectively, this prepends /usr/local/bin and /usr/bin to your Windows system path. If you choose to reset your PATH, say in $HOME/.bashrc, or by editing etc/profile directly, then you should follow this rule. You must have /usr/bin in your PATH before any Windows system directories. (And you must not omit the Windows system directories!) Otherwise you will likely encounter all sorts of problems running Cygwin applications. If you're using another shell than bash (say, tcsh), the mechanism is the same, just the names of the login scripts are different. Bash (or another shell) says "command not found", but it's right there! If you compile a program, you might find that you can't run it: bash$ gcc -o hello hello.c bash$ hello bash: hello: command not found Unlike the Windows default behaviour, Unix shells like bash do not look for programs in . (the current directory) by default. You can add . to your PATH (see above), but this is not recommended (at least on UNIX) for security reasons. Just tell bash where to find it, when you type it on the command line: bash$ gcc -o hello hello.c bash$ ./hello Hello World! How do I convert between Windows and UNIX paths? Use the 'cygpath' utility. Type 'cygpath --help' for information. For example (on my installation): bash$ cygpath --windows ~/.bashrc D:\starksb\.bashrc bash$ cygpath --unix C:/cygwin/bin/cygwin.bat /usr/bin/cygwin.bat bash$ cygpath --unix C:\\cygwin\\bin\\cygwin.bat /usr/bin/cygwin.bat Note that bash interprets the backslash '\' as an escape character, so you must type it twice in the bash shell if you want it to be recognized as such. Why doesn't bash read my .bashrc file on startup? Your .bashrc is read from your home directory specified by the HOME environment variable. It uses /.bashrc if HOME is not set. So you need to set HOME (and the home dir in your /etc/passwd entry) correctly. How can I get bash filename completion to be case insensitive? Add the following to your ~/.bashrc file: shopt -s nocaseglob and add the following to your ~/.inputrc file: set completion-ignore-case on Can I use paths/filenames containing spaces in them? Cygwin does support spaces in filenames and paths. That said, some utilities that use the library may not, since files don't typically contain spaces in Unix. If you stumble into problems with this, you will need to either fix the utilities or stop using spaces in filenames used by Cygwin tools. In particular, bash interprets space as a word separator. You would have to quote a filename containing spaces, or escape the space character. For example: bash-2.03$ cd '/cygdrive/c/Program Files' or bash-2.03$ cd /cygdrive/c/Program\ Files Why can't I cd into a shortcut to a directory? Cygwin does not follow MS Windows Explorer Shortcuts (*.lnk files). It sees a shortcut as a regular file and this you cannot "cd" into it. Cygwin is also capable to create POSIX symlinks as Windows shortcuts (see the CYGWIN environment variable option "winsymlinks"), but these shortcuts are different from shortcuts created by native Windows applications. Windows applications can usually make use of Cygwin shortcuts but not vice versa. This is by choice. The reason is that Windows shortcuts may contain a bunch of extra information which would get lost, if, for example, Cygwin tar archives and extracts them as symlinks. Changing a Cygwin shortcut in Windows Explorer usually changes a Cygwin shortcut into a Windows native shortcut. Afterwards, Cygwin will not recognize it as symlink anymore. I'm having basic problems with find. Why? Make sure you are using the find that came with Cygwin and that you aren't picking up the Win32 find command instead. You can verify that you are getting the right one by doing a "type find" in bash. If the path argument to find, including current directory (default), is itself a symbolic link, then find will not traverse it unless you specify the -follow option. This behavior is different than most other UNIX implementations, but is not likely to change. If find does not seem to be producing enough results, or seems to be missing out some directories, you may be experiencing a problem with one of find's optimisations. The absence of . and .. directories on some filesystems, such as DVD-R UDF, can confuse find. See the documentation for the option -noleaf in the man page. Why doesn't su work? The su command has been in and out of Cygwin distributions, but it has not been ported to Cygwin and has never worked. It is currently installed as part of the sh-utils, but again, it does not work. You should rather install sshd and use ssh username@localhost as a su replacement. For some technical background into why su doesn't work, read http://www.cygwin.com/ml/cygwin/2003-06/msg00897.html and related messages. Why doesn't man -k (or apropos) work? Before you can use man -k or apropos, you must create the whatis database. Just run the command /usr/sbin/makewhatis (it may take a minute to complete). Why doesn't chmod work? The most common case is that your /etc/passwd or /etc/group files are not properly set up. If ls -l shows a group of mkpasswd or mkgroup, you need to run one or both of those commands. If you're using FAT32 instead of NTFS, chmod will fail since FAT32 does not provide any permission information. You should really consider converting the drive to NTFS with CONVERT.EXE. FAT and FAT32 are barely good enough for memory cards or USB sticks to exchange pictures... For other cases, understand that Cygwin attempts to show UNIX permissions based on the security features of Windows, so the Windows ACLs are likely the source of your problem. See the Cygwin User's Guide at for more information on how Cygwin maps Windows permissions. Why doesn't my shell script work? There are two basic problems you might run into. One is the fact that /bin/sh is really bash. It could be missing some features you might expect in /bin/sh, if you are used to /bin/sh actually being zsh (MacOS X "Panther") or ksh (Tru64). Or, it could be a permission problem, and Cygwin doesn't understand that your script is executable. On NTFS or NFS just make the script executable using chmod +x. However, chmod may not work due to restrictions of the filesystem (see FAQ entry above). In this case Cygwin must read the contents of files to determine if they are executable. If your script does not start with #! /bin/sh (or any path to a script interpreter, it does not have to be /bin/sh) then Cygwin will not know it is an executable script. The Bourne shell idiom : # This is the 2nd line, assume processing by /bin/sh also works. Note that you can use the filesystem flag cygexec in /etc/fstab to force Cygwin to treat all files under the mount point as executable. This can be used for individual files as well as directories. Then Cygwin will not bother to read files to determine whether they are executable. How do I print under Cygwin? lpr is available in the setup.exe cygutils package. Some usage hints are available courtesy of Rodrigo Medina. Jason Tishler has written a couple of messages that explain how to use a2ps (for nicely formatted text in PostScript) and ghostscript (to print PostScript files on non-PostScript Windows printers). Start at http://cygwin.com/ml/cygwin/2001-04/msg00657.html. Note that the file command is now available as part of Cygwin setup. Alternatively, on NT, you can use the Windows print command. (It does not seem to be available on Win9x.) Type bash$ print /\? for usage instructions (note the ? must be escaped from the shell). Finally, you can simply cat the file to the printer's share name: bash$ cat myfile > //host/printer You may need to press the formfeed button on your printer or append the formfeed character to your file. Why don't international (Unicode) characters work? Internationalization is a complex issue. The short answer is that Cygwin relies on the setting of the setting of LANG/LC_xxx environment variables. The long answer can be found in the User's Guide in the section Internationalization To get UTF-8 support you must set the LANG, LC_ALL, or LC_CTYPE environment variables. To get UTF-8 support you can set, for instance, $LANG to "en_US.UTF-8". This will give you support for the UTF-8 character set. Note that the language part has to contain a valid language specifier, but is otherwise so far ignored. There's no support for correct language-specific collation, monetary or date/time-related string handling. This is planned for a later release, though. To type international characters (£äö) in bash, check if the following settings are available in your bash, and if not, add them to your ~/.inputrc file and restart bash: set meta-flag on set convert-meta off set output-meta on set input-meta on These are options to the readline library, which you can read about in the bash(1) and readline(3) man pages. Other tools that do not use readline for display, such as less and ls, might require additional settings for doublebyte or multibyte charsets, which could be put in your ~/.bashrc, for instance: alias less='/bin/less -r' alias ls='/bin/ls -F --color=tty --show-control-chars' My application prints international characters but I only see gray boxes Very likely you didn't set your Console character set to the preferred character set before the first Cygwin application was started in the console. To make sure the console is using the desired character set, maile sure that one of the internationalization environment variables LC_ALL, LC_CTYPE, or LANG is set before the first Cygwin process starts. You can do that, for instance, by setting the variable in your Cygwin.bat file from which you start your Cygwin shell. For a more detailed explanation see the section The Windows Console character set in the Cygwin User's Guide. Is it OK to have multiple copies of the DLL? You should only have one copy of the Cygwin DLL on your system. If you have multiple versions, they will conflict and cause problems. If you get the error "shared region is corrupted" or "shared region version mismatch" it means you have multiple versions of cygwin1.dll running at the same time which conflict with each other. This could happen, for example, if you update cygwin1.dll without exiting all Cygwin apps (including inetd) beforehand. The only DLL that is sanctioned by the Cygwin project is the one that you get by running setup.exe, installed in the directory controlled by this program. If you have other versions on your system and desire help from the cygwin project, you should delete or rename all DLLs that are not installed by setup.exe. If you're trying to find multiple versions of the DLL that are causing this problem, reboot first, in case DLLs still loaded in memory are the cause. Then use the Windows System find utility to search your whole machine, not just components in your PATH (as 'type' would do) or cygwin-mounted filesystems (as Cygwin 'find' would do). I read the above but I want to bundle Cygwin with a product, and ship it to customer sites. How can I do this without conflicting with any Cygwin installed by the user? Third party developers who wish to use Cygwin should check if there is a version of cygwin installed and use the installed version if it is newer, or conditionally upgrade if it is not. (If you write a tool to make this easy, consider contributing it for others to use) Can I bundle Cygwin with my product for free? Only if you comply with Cygwin's license very carefully. If you choose to distribute cygwin1.dll, you must be willing to distribute the exact source code used to build that copy of cygwin1.dll as per the terms of the GPL. If you ship applications that link with cygwin1.dll, you must either provide those applications' source code under a GPL-compatible license, *or* purchase a cygwin license from Red Hat. So I can't install a private version of the Cygwin DLL without conflicting with the system cygwin? Actually, if you are very careful, you can have two different versions of the Cygwin DLL installed on your system at the same time but they must be run serially. The only exception from this rule is, if one of the DLLs is a pre-1.7 DLL and the other is a 1.7.0 or later DLL. These DLLs can work concurrently without knowing about each other due to massive changes using shared resources in Cygwin 1.7. However, processes using different DLLs will not interact with each other correctly, so keep them separate except you really really know what you're doing. This usage is not recommeded for novices. Only limited support will be provided in the mailing lists if you run into problems. But doesn't that mean that if some application installs an older Cygwin DLL on top of a newer DLL, my application will break? It depends on what you mean by "break". If the application installs a version of the Cygwin DLL in another location than Cygwin's /bin directory then the rules in apply. If the application installs an older version of the DLL in /bin then you should complain loudly to the application provider. Remember that the Cygwin DLL strives to be backwards compatible so a newer version of the DLL should always work with older executables. So, in general, it is always best to keep one version of the DLL on your system and it should always be the latest version which matches your installed distribution. Why isn't package XYZ available in Cygwin? Probably because there is nobody willing or able to maintain it. It takes time, and the priority for the Cygwin Team is the Cygwin package. The rest is a volunteer effort. Want to contribute? See http://cygwin.com/setup.html. Why is the Cygwin package of XYZ so out of date? (Also: Why is the version of package XYZ older than the version that I can download from the XYZ web site? Why is the version of package XYZ older than the version that I installed on my linux system? Is there something special about Cygwin which requires that only an older version of package XYZ will work on it?) Every package in the Cygwin distribution has a maintainer who is responsible for sending out updates of the package. This person is a volunteer who is rarely the same person as the official developer of the package. If you notice that a version of a package seems to be out of date, the reason is usually pretty simple -- the person who is maintaining the package hasn't gotten around to updating it yet. Rarely, the newer package actually requires complex changes that the maintainer is working out. If you urgently need an update, sending a polite message to the cygwin mailing list pinging the maintainer is perfectly acceptable. There are no guarantees that the maintainer will have time to update the package or that you'll receive a response to your request, however. Remember that the operative term here is "volunteer". How can I access other drives? You have some flexibility here. Cygwin has a builtin "cygdrive prefix" for drives that are not mounted. You can access any drive, say Z:, as '/cygdrive/z/'. In some applications (notably bash), you can use the familiar windows <drive>:/path/, using posix forward-slashes ('/') instead of Windows backward-slashes ('\'). (But see the warning below!) This maps in the obvious way to the Windows path, but will be converted internally to use the Cygwin path, following mounts (default or explicit). For example: bash$ cd C:/Windows bash$ pwd /cygdrive/c/Windows and bash$ cd C:/cygwin bash$ pwd / for a default setup. You could also use backward-slashes in the Windows path, but these would have to be escaped from the shell. Warning: There is some ambiguity in going from a Windows path to the posix path, because different posix paths, through different mount points, could map to the same Windows directory. This matters because different mount points may be binmode or textmode, so the behavior of Cygwin apps will vary depending on the posix path used to get there. You can avoid the ambiguity of Windows paths, and avoid typing "/cygdrive", by explicitly mounting drives to posix paths. For example: bash$ mkdir /c bash$ mount c:/ /c bash$ ls /c Then /cygdrive/c/Windows becomes /c/Windows which is a little less typing. Note that you have to enter the mount point into the /etc/fstab file to keep it indefinitely. The mount command will only add the mount point for the lifetime of your current Cygwin session. You can change the default cygdrive prefix and whether it is binmode or textmode using the /etc/fstab file as well. See the Cygwin User's Guide at http://cygwin.com/1.7/cygwin-ug-net/using.html#mount-table for more details. How can I copy and paste into Cygwin console windows? First, consider using rxvt or mintty instead of the standard console window. In rxvt/mintty, selecting with the left-mouse also copies, and middle-mouse pastes. It couldn't be easier! In Windows's console window, open the properties dialog. The options contain a toggle button, named "Quick edit mode". It must be ON. Save the properties. You can also bind the insert key to paste from the clipboard by adding the following line to your .inputrc file: "\e[2~": paste-from-clipboard What firewall should I use with Cygwin? We have had good reports about Kerio Personal Firewall, ZoneLabs Integrity Desktop, and the built-in firewall in Windows XP. Other well-known products including ZoneAlarm and Norton Internet Security have caused problems for some users but work fine for others. At last report, Agnitum Outpost did not work with Cygwin. If you are having strange connection-related problems, disabling the firewall is a good troubleshooting step (as is closing or disabling all other running applications, especially resource-intensive processes such as indexed search). On the whole, Cygwin doesn't care which firewall is used. The few rare exceptions have to do with socket code. Cygwin uses sockets to implement many of its functions, such as IPC. Some overzealous firewalls install themselves deeply into the winsock stack (with the 'layered service provider' API) and install hooks throughout. Sadly the mailing list archives are littered with examples of poorly written firewall-type software that causes things to break. Note that with many of these products, simply disabling the firewall does not remove these changes; it must be completely uninstalled. See also for a list of applications that have been known, at one time or another, to interfere with the normal functioning of Cygwin. How can I share files between Unix and Windows? During development, we have Linux boxes running Samba and NFS as well as Windows machines. We often build with cross-compilers under Linux and copy binaries and source to the Windows system or just toy with them directly off the Samba-mounted partition. Or, we use the Microsoft NFS client and just use NFS shares on Linux from Windows. And then there are tools like scp, ftp, rsync, ... Is Cygwin case-sensitive?? Several Unix programs expect to be able to use to filenames spelled the same way, but with different case. A prime example of this is perl's configuration script, which wants Makefile and makefile. Windows can't tell the difference between files with just different case, so the configuration fails. To help with this problem, Cygwin supports casesensitivity starting with Cygwin 1.7.0. For a detailed description how to use that feature see the Cygwin User's Guilde at http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html. What about DOS special filenames? In Windows, files cannot be named com1, lpt1, or aux (to name a few); either as the root filename or as the extension part. If you do, you'll have trouble. Unix programs don't avoid these names which can make things interesting. E.g., the perl distribution has a file called aux.sh. The perl configuration tries to make sure that aux.sh is there, but an operation on a file with the magic letters 'aux' in it will hang. At least that's what happens when using native Windows tools. Cygwin 1.7.0 and later can deal with these filenames just fine. Again, see the User's Guide at http://cygwin.com/1.7/cygwin-ug-net/using-specialnames.html for a detailed description of what's possible with filenames and what is not. When it hangs, how do I get it back? If something goes wrong and the tools hang on you for some reason (easy to do if you try and read a file called aux.sh), first try hitting ^C to return to bash or the cmd prompt. If you start up another shell, and applications don't run, it's a good bet that the hung process is still running somewhere. Use the Task Manager, pview, or a similar utility to kill the process. And, if all else fails, there's always the reset button/power switch. In theory this should never be necessary, though. Why the weird directory structure? Why do /lib and /usr/lib (and /bin, /usr/bin) point to the same thing? Why use mounts instead of symbolic links? Can I use a disk root (e.g., C:\) as Cygwin root? Why is this discouraged? After a new installation in the default location, your mount points will look something like this: bash$ mount C:\cygwin\bin on /usr/bin type ntfs (binary,auto) C:\cygwin\lib on /usr/lib type ntfs (binary,auto) C:\cygwin on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) Note that /bin and /usr/bin point to the same location, as do /lib and /usr/lib. This is intentional, and you should not undo these mounts unless you really know what you are doing. Various applications and packages may expect to be installed in /lib or /usr/lib (similarly /bin or /usr/bin). Rather than distinguish between them and try to keep track of them (possibly requiring the occasional duplication or symbolic link), it was decided to maintain only one actual directory, with equivalent ways to access it. Symbolic links had been considered for this purpose, but were dismissed because they do not always work on Samba drives. Also, mounts are faster to process because no disk access is required to resolve them. Note that non-cygwin applications will not observe Cygwin mounts (or symlinks for that matter). For example, if you use WinZip to unpack the tar distribution of a Cygwin package, it may not get installed to the correct Cygwin path. So don't do this! It is strongly recommended not to make the Cygwin root directory the same as your drive's root directory, unless you know what you are doing and are prepared to deal with the consequences. It is generally easier to maintain the Cygwin hierarchy if it is isolated from, say, C:\. For one thing, you avoid possible collisions with other (non-cygwin) applications that may create (for example) \bin and \lib directories. (Maybe you have nothing like that installed now, but who knows about things you might add in the future?) How do anti-virus programs like Cygwin? Users have reported that NAI (formerly McAfee) VirusScan for NT (and others?) is incompatible with Cygwin. This is because it tries to scan the newly loaded shared memory in cygwin1.dll, which can cause fork() to fail, wreaking havoc on many of the tools. (It is not confirmed that this is still a problem, however.) There have been several reports of NAI VirusScan causing the system to hang when unpacking tar.gz archives. This is surely a bug in VirusScan, and should be reported to NAI. The only workaround is to disable VirusScan when accessing these files. This can be an issue during setup, and is discussed in that FAQ entry. Some users report a significant performance hit using Cygwin when their anti-virus software is enabled. Rather than disable the anti-virus software completely, it may be possible to specify directories whose contents are exempt from scanning. In a default installation, this would be C:\cygwin\bin. Obviously, this could be exploited by a hostile non-Cygwin program, so do this at your own risk. See also for a list of applications that have been known, at one time or another, to interfere with the normal functioning of Cygwin. Is there a Cygwin port of GNU Emacs? Yes. It uses the X11 (http://cygwin.com/xfree/) GUI. Right now the package is old and outdated. Consider using XEmacs for now. Is there a Cygwin port of XEmacs? Yes. It can be used in three different modes: X11 (http://cygwin.com/xfree/) GUI You have to set the DISPLAY environment variable before starting xemacs. bash$ DISPLAY=127.0.0.1:0 xemacs & Windows native GUI You have to unset the DISPLAY environment variable before starting xemacs. bash$ DISPLAY= xemacs & Console mode Start xemacs with -nw in a terminal (native or X11) window bash$ xemacs -nw The current stable Cygwin version of XEmacs is 21.4.x. But there is also a Cygwin test release version (21.5.x) available for download via setup.exe. To use all the standard packages with XEmacs you should download the following two packages: xemacs-sumo - XEmacs standard packages xemacs-mule-sumo - XEmacs MULE (MUlti Lingual Emacs) packages An alternative native distribution of XEmacs for Windows based systems can be downloaded from http://xemacs.org/Download/win32/index.html. It uses an InnoSetup Kit based installer. What about NT Emacs? If you want GNU Emacs with a native Microsoft GUI interface, then you can either use XEmacs (see above), or native NT Emacs: see section Where can I get pre-compiled versions? in NT Emacs FAQ. NT Emacs uses the Windows command shell by default. Since it is not a Cygwin application, it has no knowledge of Cygwin mounts. With those points in mind, you need to add the following code to your ~/.emacs (or ~/_emacs) file in order to use Cygwin bash. This is particularly useful for the JDEE package (http://jdee.sunsite.dk/). The following settings are for Emacs 21.1: ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Initial setup ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; This assumes that Cygwin is installed in C:\cygwin (the ;; default) and that C:\cygwin\bin is not already in your ;; Windows Path (it generally should not be). (setq exec-path (cons "C:/cygwin/bin" exec-path)) (setenv "PATH" (concat "C:\\cygwin\\bin;" (getenv "PATH"))) ;; LOGNAME and USER are expected in many Emacs packages ;; Check these environment variables. (if (and (null (getenv "USER")) ;; Windows includes variable USERNAME, which is copied to ;; LOGNAME and USER respectively. (getenv "USERNAME")) (setenv "USER" (getenv "USERNAME"))) (if (and (getenv "LOGNAME") ;; Bash shell defines only LOGNAME (null (getenv "USER"))) (setenv "USER" (getenv "LOGNAME"))) (if (and (getenv "USER") (null (getenv "LOGNAME"))) (setenv "LOGNAME" (getenv "USER"))) ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; (A) M-x shell: This change M-x shell permanently ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; Would call Windows command interpreter. Change it. (setq shell-file-name "bash") (setenv "SHELL" shell-file-name) (setq explicit-shell-file-name shell-file-name) ;; Remove C-m (^M) characters that appear in output (add-hook 'comint-output-filter-functions 'comint-strip-ctrl-m) ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;; (B) *OR* call following function with M-x my-bash ;; The M-x shell would continue to run standard Windows shell ;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; (defun my-bash (&optional buffer) "Run Cygwin Bash shell in optional BUFFER; default *shell-bash*." (autoload 'comint-check-proc "comint") (interactive (let ((name "*shell-bash*")) (if current-prefix-arg (setq name (read-string (format "Cygwin shell buffer (default %s): " name) (not 'initial-input) (not 'history) name))) (list name))) (or buffer (setq buffer "*shell-bash*")) (if (comint-check-proc buffer) (pop-to-buffer buffer) (let* ((shell-file-name "bash") (explicit-shell-file-name shell-file-name) (explicit-sh-args '("--login" "-i")) (explicit-bash-args explicit-sh-args) (w32-quote-process-args ?\"));; Use Cygwin quoting rules. (shell buffer) ;; By default Emacs sends "\r\n", but bash wants plain "\n" (set-buffer-process-coding-system 'undecided-dos 'undecided-unix) ;; With TAB completion, add slash path separator, none to filenames (make-local-variable 'comint-completion-addsuffix) (setq comint-completion-addsuffix '("/" . "")) ;; This variable is local to buffer (setq comint-prompt-regexp "^[ \n\t]*[$] ?")))) If you want NT Emacs to understand Cygwin paths, get cygwin-mount.el from http://www.emacswiki.org/elisp/index.html. Note that all of this ``just works'' if you use the Cygwin port of Emacs or XEmacs from Cygwin Setup. Is there a better alternative to the standard console window? Yes! Use rxvt or mintty instead. Both are optional packages in Cygwin Setup. You can use rxvt with or without X11, while mintty is a Cygwin application providing a native GUI. Why do some of my old symlinks don't work anymore? Beginning with Cygwin 1.7, Cygwin supports multiple character sets. Symlinks created with Cygwin 1.7 are using the UTF-16 character set, which is portable across all character sets. Old symlinks were written using your current Windows codepage, which is not portable across all character sets. If the target of the symlink doesn't resolve anymore, it's very likely that the symlink points to a target filename using native, non-ASCII characters, and you're now using another character set than way back when you created the symlink. Solution: Delete the symlink and create it again under you new Cygwin. The new symlink will be correctly point to the target no matter what character set you're using in future. Why don't symlinks work on samba-mounted filesystems? Symlinks are marked with "system" file attribute. Samba does not enable this attribute by default. To enable it, consult your Samba documentation and then add these lines to your samba configuration file: map system = yes create mask = 0775 Note that the 0775 can be anything as long as the 0010 bit is set. Alternatively, use Windows shortcuts as symlinks. See the CYGWIN environment variable option "winsymlinks" http://cygwin.com/1.7/cygwin-ug-net/using-cygwinenv.html Why doesn't Cygwin tcl/tk understand Cygwin paths? The versions of Tcl/Tk distributed with Cygwin (e.g. cygtclsh80.exe, cygwish80.exe) are not actually "Cygwin versions" of those tools. They are built as native libraries, which means they do not understand Cygwin mounts or symbolic links. See the entry "How do I convert between Windows and UNIX paths?" elsewhere in this FAQ. Why do I get "Address family not supported" errors when playing with IPv6? IPv6 is fully supported and available right from the start with Windows Vista and Windows Server 2008. The previous generation of Windows, Windows XP and Windows Server 2003, only support IPv6 on an "experimental" basis. On these Windows versions, the IPv6 TCP/IP stack is not installed automatically, rather the system administrator has to install it manually. Unless this has already been done on your machine, your machine is not IPv6-capable and that's why you see the "Address family not supported" error message. There's also a very experimental IPv6 stack for Windows 2000, and Cygwin will try its best to support it, but it's not recommended to install it. Windows NT4 or older never saw IPv6 at all. For more information about IPv6 on Windows and how to install the IPv6 stack, see the Microsoft TechNet IPv6 FAQ article What applications have been found to interfere with Cygwin? From time to time, people have reported strange failures and problems in Cygwin and Cygwin packages that seem to have no rational explanation. Among the most common symptoms they report are fork failures, memory leaks, and file access denied problems. These problems, when they have been traced, often appear to be caused by interference from other software installed on the same PC. Security software, in particular, such as anti-virus, anti-spyware, and firewall applications, often implements its functions by installing hooks into various parts of the system, including both the Explorer shell and the underlying kernel. Sometimes these hooks are not implemented in an entirely transparent fashion, and cause changes in the behaviour which affect the operation of other programs, such as Cygwin. Among the software that has been found to cause difficulties are: Sonic Solutions burning software containing DLA component (when DLA disabled) Norton/MacAfee/Symantec antivirus or antispyware Logitech webcam software with "Logitech process monitor" service Kerio, Agnitum or ZoneAlarm Personal Firewall Iolo System Mechanic/AntiVirus/Firewall LanDesk Windows Defender Embassy Trust Suite fingerprint reader software wxvault.dll NOD32 Antivirus ByteMobile laptop optimization client Earthlink Total-Access Spybot S&D TeaTimer AR Soft RAM Disk ATI Catalyst drivers Windows LiveOneCare Webroot Spy Sweeper with Antivirus COMODO Firewall Pro PC Tools Spyware Doctor Avira AntiVir Panda Internet Security BitDefender Google Desktop Sophos Anti-Virus 7 Bufferzone from Trustware Sometimes these problems can be worked around, by temporarily or partially disabling the offending software. For instance, it may be possible to disable on-access scanning in your antivirus, or configure it to ignore files under the Cygwin installation root. Often, unfortunately, this is not possible; even disabling the software may not work, since many applications that hook the operating system leave their hooks installed when disabled, and simply set them into what is intended to be a completely transparent pass-through mode. Sometimes this pass-through is not as transparent as all that, and the hooks still interfere with Cygwin; in these cases, it may be necessary to uninstall the software altogether to restore normal operation. Some of the symptoms you may experience are: Random fork() failures. Caused by hook DLLs that load themselves into every process in the system. POSIX fork() semantics require that the memory map of the child process must be an exact duplicate of the parent process' layout. If one of these DLLs loads itself at a different base address in the child's memory space as compared to the address it was loaded at in the parent, it can end up taking the space that belonged to a different DLL in the parent. When Cygwin can't load the original DLL at that same address in the child, the fork() call has to fail. File access problems. Some programs (e.g., virus scanners with on-access scanning) scan or otherwise operate on every file accessed by all the other software running on your computer. In some cases they may retain an open handle on the file even after the software that is really using the file has closed it. This has been known to cause operations such as deletes, renames and moves to fail with access denied errors. In extreme cases it has been known for scanners to leak file handles, leading to kernel memory starvation. Networking issues Firewall software sometimes gets a bit funny about Cygwin. It's not currently understood why; Cygwin only uses the standard Winsock2 API, but perhaps in some less-commonly used fashion that doesn't get as well tested by the publishers of firewalls. Symptoms include mysterious failures to connect, or corruption of network data being sent or received. Memory and/or handle leaks Some applications that hook into the Windows operating system exhibit bugs when interacting with Cygwin that cause them to leak allocated memory or other system resources. Symptoms include complaints about out-of-memory errors and even virtual memory exhaustion dialog boxes from the O/S; it is often possible to see the excess memory allocation using a tool such as Task Manager or Sysinternals' Process Explorer, although interpreting the statistics they present is not always straightforward owing to complications such as virtual memory paging and file caching.