1438 lines
61 KiB
XML
1438 lines
61 KiB
XML
<?xml version="1.0" encoding='UTF-8'?>
|
|
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.5//EN"
|
|
"http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd">
|
|
|
|
<qandadiv id="faq.using">
|
|
<title>Using Cygwin</title>
|
|
|
|
<!-- faq-problems.xml -->
|
|
<qandaentry id="faq.using.missing-dlls">
|
|
<question><para>Why can't my application locate cygncurses-8.dll? or cygintl-3.dll? or cygreadline6.dll? or ...?</para></question>
|
|
<answer>
|
|
|
|
<para>Well, something has gone wrong somehow...
|
|
</para>
|
|
<para>To repair the damage, you must run Cygwin Setup again, and re-install the
|
|
package which provides the missing DLL package.
|
|
</para>
|
|
<para>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 <literal>Full/Part</literal>
|
|
button. This lists all packages, even those that are already
|
|
installed. Scroll down to locate the missing package, for instance
|
|
<literal>libncurses8</literal>. Click on the ``cycle'' glyph until it says
|
|
``Reinstall''. Continue with the installation.
|
|
</para>
|
|
<para>For a detailed explanation of the general problem, and how to extend
|
|
it to other missing DLLs and identify their containing packages, see
|
|
<ulink url="https://cygwin.com/ml/cygwin/2002-01/msg01619.html"/>.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.startup-slow">
|
|
<question><para>Starting a new terminal window is slow. What's going on?</para></question>
|
|
<answer>
|
|
|
|
<para>There are many possible causes for this.</para>
|
|
|
|
<para>If your terminal windows suddenly began starting slowly after a
|
|
Cygwin upgrade, it may indicate issues in the authentication
|
|
setup.</para>
|
|
|
|
<para>For almost all its lifetime, Cygwin has used Unix-like
|
|
<filename>/etc/passwd</filename> and <filename>/etc/group</filename>
|
|
files to mirror the contents of the Windows SAM and AD databases.
|
|
Although these files can still be used, since Cygwin 1.7.34, new
|
|
installations now use the SAM/AD databases directly.</para>
|
|
|
|
<para>To switch to the new method, move these two files out of the way
|
|
and restart the Cygwin terminal. That runs Cygwin in its new default
|
|
mode.</para>
|
|
|
|
<para>If you are on a system that isn't using AD domain logins, this
|
|
makes Cygwin use the native Windows SAM database directly, which may be
|
|
faster than the old method involving <filename>/etc/passwd</filename>
|
|
and such. At worst, it will only be a bit slower. (The speed difference
|
|
you see depends on which benchmark you run.) For the AD case, it can be
|
|
slower than the old method, since it is trading a local file read for a
|
|
network request. Version 1.7.35 will reduce the number of AD server
|
|
requests the DLL makes relative to 1.7.34, with the consequence that you
|
|
will now have to alter <filename>/etc/nsswitch.conf</filename> in order
|
|
to change your Cygwin home directory, instead of being able to change it
|
|
from the AD configuration.</para>
|
|
|
|
<para>If you are still experiencing very slow shell startups, there are
|
|
a number of other things you can look into:</para>
|
|
|
|
<orderedlist>
|
|
<listitem>
|
|
<para>One common cause of slow Cygwin Terminal starts is a bad DNS
|
|
setup. This particularly affects AD clients, but there may be other
|
|
things in your Cygwin startup that depend on getting fast answers
|
|
back from a network server.</para>
|
|
|
|
<para>Keep in mind that this may affect Cygwin even when the domain
|
|
controller is on the same machine as Cygwin, or is on a nearby
|
|
server. A bad DNS server IP can cause long delays while the local
|
|
TCP/IP stack times out on a connection to a server that simply isn't
|
|
there, for example.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Another cause for AD client system is slow DC replies,
|
|
commonly observed in configurations with remote DC access. The
|
|
Cygwin DLL queries information about every group you're in to
|
|
populate the local cache on startup. You may speed up this process a
|
|
little by caching your own information in local files. Run these
|
|
commands in a Cygwin terminal with write access to
|
|
<filename>/etc</filename>:</para>
|
|
|
|
<screen>getent passwd $(id -u) > /etc/passwd
|
|
getent group $(id -G) > /etc/group</screen>
|
|
|
|
<para>Also, set <filename>/etc/nsswitch.conf</filename> as
|
|
follows:</para>
|
|
|
|
<screen>passwd: files db
|
|
group: files db</screen>
|
|
|
|
<para>This will limit the need for Cygwin to contact the AD domain
|
|
controller (DC) while still allowing for additional information to
|
|
be retrieved from DC, such as when listing remote
|
|
directories.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>Either in addition to the previous item or instead of it, you
|
|
can run <ulink
|
|
url="https://cygwin.com/cygwin-ug-net/using-cygserver.html"><command>cygserver</command></ulink>
|
|
as a local caching service to speed up DC requests.</para>
|
|
|
|
<para>Cygwin programs will check with <command>cygserver</command>
|
|
before trying to query the DC directly.</para>
|
|
</listitem>
|
|
|
|
<listitem>
|
|
<para>A less preferable option is to create a static read-only cache
|
|
of the authentication data. This is the old-fashioned method of
|
|
making Cygwin integrate with AD, the only method available in
|
|
releases before 1.7.34. To do this, run <command>mkpasswd</command>
|
|
and <command>mkgroup</command>, then put the following into
|
|
<filename>/etc/nsswitch.conf</filename> to make Cygwin treat these
|
|
files as the only sources of user and group information:</para>
|
|
|
|
<screen>passwd: files
|
|
group: files</screen>
|
|
|
|
<para>By leaving out the <computeroutput>db</computeroutput> option,
|
|
we are telling the Cygwin DLL not to even try to do AD lookups. If
|
|
your AD servers are slow, this local cache will speed things up. The
|
|
downside is that you open yourself up to the <ulink
|
|
url="http://en.wikipedia.org/wiki/Cache_(computing)">stale cache
|
|
problem</ulink>: any time the AD databases change, your local cache
|
|
will go out of date until you update the files manually.</para>
|
|
</listitem>
|
|
</orderedlist>
|
|
|
|
<para>If none of the above helps, the best troubleshooting method is to
|
|
run your startup scripts in debug mode. Right-click your Cygwin Terminal
|
|
icon, go to Properties, and edit the command. It should be something
|
|
like <command>C:\cygwin\bin\mintty.exe -i /Cygwin-Terminal.ico
|
|
-</command>. Assuming you are using Bash for your login shell, change
|
|
it to <command>C:\cygwin\bin\mintty /bin/bash -lx</command> then try
|
|
running Cygwin Terminal again. The <option>-x</option> option tells Bash
|
|
to write every command it runs to the terminal before launching it. If
|
|
the terminal immediately starts filling with lines of text but then
|
|
pauses, the line where the output paused is your clue as to what's going
|
|
on. The Cygwin DLL proper probably isn't the cause of the slowdown in
|
|
this case, since those delays happen before the first line of text
|
|
appears in the terminal.</para>
|
|
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.slow">
|
|
<question><para>Why is Cygwin suddenly <emphasis>so</emphasis> slow?</para></question>
|
|
<answer>
|
|
|
|
<para>If suddenly <emphasis>every</emphasis> command takes a
|
|
<emphasis>very</emphasis> long time, then something is probably attempting to
|
|
access a network share. You may have the obsolete <literal>//c</literal>
|
|
notation in your PATH or startup files. Using <literal>//c</literal> means
|
|
to contact the <emphasis>network server</emphasis> <literal>c</literal>, which
|
|
will slow things down tremendously if it does not exist.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.shares">
|
|
<question><para>Why can't my services access network shares?</para></question>
|
|
<answer>
|
|
|
|
<para>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
|
|
<ulink url="https://cygwin.com/cygwin-ug-net/ntsec.html"/>.
|
|
</para>
|
|
<para>Workarounds include using public network share that does not require
|
|
authentication (for non-critical files), providing your password to a
|
|
<command>net use</command> command, or running the service as your own
|
|
user with <literal>cygrunsrv -u</literal> (see
|
|
<literal>/usr/share/doc/Cygwin/cygrunsrv.README</literal> for more
|
|
information).
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.path">
|
|
<question><para>How should I set my PATH?</para></question>
|
|
<answer>
|
|
|
|
<para>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
|
|
<literal>setup.exe</literal>. The line is
|
|
</para>
|
|
<screen>
|
|
PATH="/usr/local/bin:/usr/bin:/bin:$PATH"
|
|
</screen>
|
|
|
|
<para>Effectively, this <emphasis role='bold'>prepends</emphasis> /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 <emphasis role='bold'>must</emphasis> have <literal>/usr/bin</literal> in your PATH
|
|
<emphasis role='bold'>before</emphasis> 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.
|
|
</para>
|
|
<para>If you're using another shell than bash (say, tcsh), the mechanism
|
|
is the same, just the names of the login scripts are different.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.not-found">
|
|
<question><para>Bash (or another shell) says "command not found", but it's right there!</para></question>
|
|
<answer>
|
|
|
|
<para>If you compile a program, you might find that you can't run it:
|
|
</para>
|
|
<screen>
|
|
bash$ gcc -o hello hello.c
|
|
bash$ hello
|
|
bash: hello: command not found
|
|
</screen>
|
|
|
|
<para>Unlike the Windows default behaviour, Unix shells like bash do not look for programs in <literal>.</literal> (the current
|
|
directory) by default. You can add <literal>.</literal> 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:
|
|
</para>
|
|
<screen>
|
|
bash$ gcc -o hello hello.c
|
|
bash$ ./hello
|
|
Hello World!
|
|
</screen>
|
|
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.converting-paths">
|
|
<question><para>How do I convert between Windows and UNIX paths?</para></question>
|
|
<answer>
|
|
|
|
<para>Use the 'cygpath' utility. Type '<literal>cygpath --help</literal>' for
|
|
information. For example (on my installation):
|
|
<screen>
|
|
bash$ cygpath --windows ~/.bashrc
|
|
D:\starksb\.bashrc
|
|
bash$ cygpath --unix C:/cygwin/bin/ls.exe
|
|
/usr/bin/ls.exe
|
|
bash$ cygpath --unix C:\\cygwin\\bin\\ls.exe
|
|
/usr/bin/ls.exe
|
|
</screen>
|
|
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.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.bashrc">
|
|
<question><para>Why doesn't bash read my .bashrc file on startup?</para></question>
|
|
<answer>
|
|
|
|
<para>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 passwd account information) correctly.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.bash-insensitive">
|
|
<question><para>How can I get bash filename completion to be case insensitive?</para></question>
|
|
<answer>
|
|
|
|
<para>Add the following to your <literal>~/.bashrc</literal> file:
|
|
</para>
|
|
<screen>
|
|
shopt -s nocaseglob
|
|
</screen>
|
|
|
|
<para>and add the following to your <literal>~/.inputrc</literal> file:
|
|
</para>
|
|
<screen>
|
|
set completion-ignore-case on
|
|
</screen>
|
|
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.filename-spaces">
|
|
<question><para>Can I use paths/filenames containing spaces in them?</para></question>
|
|
<answer>
|
|
|
|
<para>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.
|
|
</para>
|
|
<para>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:
|
|
<screen>
|
|
bash-2.03$ cd '/cygdrive/c/Program Files'
|
|
</screen>
|
|
or
|
|
<screen>
|
|
bash-2.03$ cd /cygdrive/c/Program\ Files
|
|
</screen>
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.shortcuts">
|
|
<question><para>Why can't I cd into a shortcut to a directory?</para></question>
|
|
<answer>
|
|
|
|
<para>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.
|
|
</para>
|
|
<para>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.
|
|
</para>
|
|
<para>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.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.find">
|
|
<question><para>I'm having basic problems with find. Why?</para></question>
|
|
<answer>
|
|
|
|
<para>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.
|
|
</para>
|
|
<para>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 <literal>-follow</literal> option. This behavior is different than most
|
|
other UNIX implementations, but is not likely to change.
|
|
</para>
|
|
<para>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 <literal>.</literal> and <literal>..</literal>
|
|
directories on some filesystems, such as DVD-R UDF, can confuse find.
|
|
See the documentation for the option <literal>-noleaf</literal> in the man page.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.su">
|
|
<question><para>Why doesn't <literal>su</literal> work?</para></question>
|
|
<answer>
|
|
|
|
<para>The <literal>su</literal> 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.
|
|
</para>
|
|
<para>You should rather install <literal>sshd</literal> and use
|
|
<literal>ssh username@localhost</literal> as a <literal>su</literal>
|
|
replacement.
|
|
</para>
|
|
<para>For some technical background into why <literal>su</literal> doesn't
|
|
work, read
|
|
<ulink url="https://www.cygwin.com/ml/cygwin/2003-06/msg00897.html"/> and
|
|
related messages.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.man">
|
|
<question><para>Why doesn't <literal>man -k</literal>,
|
|
<literal>apropos</literal> or <literal>whatis</literal> work?</para></question>
|
|
<answer>
|
|
|
|
<para>Before you can use <literal>man -k</literal>, <literal>apropos</literal>
|
|
or <literal>whatis</literal>, you
|
|
must create the whatis database. Just run the command
|
|
</para>
|
|
<screen>
|
|
mandb
|
|
</screen>
|
|
|
|
<para>(it may take a few minutes to complete).
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.chmod">
|
|
<question><para>Why doesn't <literal>chmod</literal> work?</para></question>
|
|
<answer>
|
|
|
|
<para>If you're using FAT32 instead of NTFS, <literal>chmod</literal>
|
|
will fail since FAT32 does not provide any permission information.
|
|
You should really consider converting the drive to NTFS with
|
|
<literal>CONVERT.EXE</literal>. FAT and FAT32 are barely good enough
|
|
for memory cards or USB sticks to exchange pictures...
|
|
</para>
|
|
<para>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 <ulink url="https://cygwin.com/cygwin-ug-net/ntsec.html"/>
|
|
for more information on how Cygwin maps Windows permissions.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.shell-scripts">
|
|
<question><para>Why doesn't my shell script work?</para></question>
|
|
<answer>
|
|
|
|
<para>There are two basic problems you might run into. One is the fact that
|
|
<command>/bin/sh</command> is really <command>bash</command>.
|
|
It could be missing some features you might expect in
|
|
<command>/bin/sh</command>, if you are used to <command>/bin/sh</command>
|
|
actually being <command>zsh</command> (MacOS X "Panther") or
|
|
<command>ksh</command> (Tru64).
|
|
</para>
|
|
|
|
<para>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 <literal>chmod +x</literal>. However,
|
|
<literal>chmod</literal> 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
|
|
</para>
|
|
<screen>
|
|
#! /bin/sh
|
|
</screen>
|
|
|
|
<para>(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
|
|
</para>
|
|
<screen>
|
|
:
|
|
# This is the 2nd line, assume processing by /bin/sh
|
|
</screen>
|
|
|
|
<para>also works.
|
|
</para>
|
|
<para>Note that you can use the filesystem flag <literal>cygexec</literal> in
|
|
<filename>/etc/fstab</filename> 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.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.printing">
|
|
<question><para>How do I print under Cygwin?</para></question>
|
|
<answer>
|
|
|
|
<para>lpr is available in the cygutils package. Some <ulink url="https://cygwin.com/ml/cygwin/2008-05/msg00123.html">usage hints</ulink> are available courtesy of Rodrigo Medina.
|
|
</para>
|
|
<para>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
|
|
<ulink url="https://cygwin.com/ml/cygwin/2001-04/msg00657.html"/>. Note that
|
|
these are old mails and <command>a2ps</command> as well as
|
|
<command>file</command> are long available as part of the Cygwin distribution.
|
|
</para>
|
|
<para>Alternatively, you can use the Windows <command>print</command>
|
|
command. Type
|
|
</para>
|
|
<screen>
|
|
bash$ print /\?
|
|
</screen>
|
|
|
|
<para>for usage instructions (note the <literal>?</literal> must be escaped
|
|
from the shell).
|
|
</para>
|
|
<para>Finally, you can simply <command>cat</command> the file to the printer's share name:
|
|
</para>
|
|
<screen>
|
|
bash$ cat myfile > //host/printer
|
|
</screen>
|
|
|
|
<para>You may need to press the formfeed button on your printer or append the
|
|
formfeed character to your file.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.unicode">
|
|
<question><para>Why don't international (Unicode) characters work?</para></question>
|
|
<answer>
|
|
|
|
<para>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 <ulink url="https://cygwin.com/cygwin-ug-net/setup-locale.html">Internationalization</ulink>
|
|
</para>
|
|
|
|
<para> Cygwin uses UTF-8 by default. To use a different character set, you
|
|
need to set the LC_ALL, LC_CTYPE or LANG environment variables.</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.weirdchars">
|
|
<question><para>My application prints international characters but I only
|
|
see gray boxes</para></question>
|
|
<answer>
|
|
<para>In the case of Cygwin programs, this likely means that the
|
|
character set as determined by the LC_ALL, LC_CTYPE or LANG environment
|
|
variables does not match the one set on the Text page of the Cygwin Terminal's
|
|
options. Setting the locale in the terminal's options will set the LANG
|
|
variable accordingly.</para>
|
|
<para>Non-Cygwin programs in the Cygwin Terminal do not usually take
|
|
heed of the locale environment variables. Instead, they often use the
|
|
so-called console codepage, which can be determined with the command
|
|
<command>cmd /c chcp</command> followed by the appropriate Windows
|
|
codepage number. The codepage number for Cygwin's default UTF-8 character
|
|
set is 65001.</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.multiple-copies">
|
|
<question><para>Is it OK to have multiple copies of the DLL?</para></question>
|
|
<answer>
|
|
<para>Yes, as long as they are used in strictly separated installations.</para>
|
|
<para>The Cygwin DLL has to handle various sharing situations between
|
|
multiple processes. It has to keep a process table. It has to maintain
|
|
a mount table which is based on the installation path of the Cygwin DLL.</para>
|
|
<para>For that reason, the Cygwin DLL maintains shared resources based on
|
|
a hash value created from its own installation path. Each Cygwin DLL
|
|
on the machine constitutes a Cygwin installation, with the directory
|
|
the Cygwin DLL resides in treated as "/bin", the parent directory as "/".
|
|
</para>
|
|
<para>Therefore, you can install two or more separate Cygwin distros on
|
|
a single machine. Each of these installations use their own Cygwin DLL,
|
|
and they don't share the default POSIX paths, nor process tables, nor
|
|
any other shared resource used to maintain the installation.</para>
|
|
<para>However, a clean separation requires that you don't try to run
|
|
executables of one Cygwin installation from processes running in another
|
|
Cygwin installation. This may or may not work, but the chances that the
|
|
result is not what you expect are pretty high.</para>
|
|
<para>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. Apart from
|
|
mixing executables of different Cygwin installations, this could also happen
|
|
if you have one a single Cygwin installation, for example, if you update the
|
|
Cygwin package without exiting <emphasis>all</emphasis> Cygwin apps (including
|
|
services like sshd) beforehand.</para>
|
|
<para>The only DLL that is sanctioned by the Cygwin project is the one that
|
|
you get by running <ulink url="https://cygwin.com/install.html">setup-x86.exe or setup-x86_64.exe</ulink>,
|
|
installed in a 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
|
|
<filename>setup.exe</filename>.
|
|
</para>
|
|
<para>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).
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.third-party.multiple-copies">
|
|
<question><para>
|
|
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?
|
|
</para></question>
|
|
<answer><para>
|
|
Usually, if you keep your installation separate, nothing bad should happen.
|
|
However, for the user's convenience, and to avoid potential problems which
|
|
still can occur, consider to integrate your product with an already existing
|
|
Cygwin installation on the user's machine, or, if there is none, consider
|
|
to install the official Cygwin distro on behalf of the user and integrate
|
|
your tools from there. (If you write a tool to make this easy, consider
|
|
contributing it for others to use)
|
|
</para></answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.bundling-cygwin">
|
|
<question><para>
|
|
Can I bundle Cygwin with my product for free?
|
|
</para></question>
|
|
<answer><para>
|
|
Only if you comply with Cygwin's <ulink
|
|
url="https://cygwin.com/licensing.html">license</ulink> 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.
|
|
</para></answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.older-cygwin-conflict">
|
|
<question><para>
|
|
But doesn't that mean that if some application installs an older Cygwin
|
|
DLL on top of a newer DLL, my application will break?
|
|
</para></question>
|
|
<answer><para>
|
|
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
|
|
<xref linkend="faq.using.third-party.multiple-copies"></xref> apply.
|
|
If the application installs an older version of the DLL in /bin then you
|
|
should complain loudly to the application provider.
|
|
</para><para>
|
|
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.
|
|
</para></answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.missing-packages">
|
|
<question><para>Why isn't package XYZ available in Cygwin?</para></question>
|
|
<answer>
|
|
|
|
<para>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
|
|
<ulink url="https://cygwin.com/setup.html"/>.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.old-packages">
|
|
<question><para>Why is the Cygwin package of XYZ so out of date?</para></question>
|
|
<answer>
|
|
|
|
<para>(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?)
|
|
</para>
|
|
<para>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.
|
|
</para>
|
|
<para>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.
|
|
</para>
|
|
<para>Remember that the operative term here is "volunteer".
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.accessing-drives">
|
|
<question><para>How can I access other drives?</para></question>
|
|
<answer>
|
|
|
|
<para>You have some flexibility here.
|
|
</para>
|
|
<para>Cygwin has a builtin "cygdrive prefix" for drives that are not mounted.
|
|
You can access any drive, say Z:, as '/cygdrive/z/'.
|
|
</para>
|
|
<para>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:
|
|
<screen>
|
|
bash$ cd C:/Windows
|
|
bash$ pwd
|
|
/cygdrive/c/Windows
|
|
</screen>
|
|
and
|
|
<screen>
|
|
bash$ cd C:/cygwin
|
|
bash$ pwd
|
|
/
|
|
</screen>
|
|
for a default setup. You could also use backward-slashes in the
|
|
Windows path, but these would have to be escaped from the shell.
|
|
</para>
|
|
<para><emphasis role='bold'>Warning:</emphasis> 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.
|
|
</para>
|
|
<para>You can avoid the ambiguity of Windows paths, and avoid typing
|
|
"/cygdrive", by explicitly mounting drives to posix paths. For example:
|
|
<screen>
|
|
bash$ mkdir /c
|
|
bash$ mount c:/ /c
|
|
bash$ ls /c
|
|
</screen>
|
|
Then <literal>/cygdrive/c/Windows</literal> becomes <literal>/c/Windows</literal> which is a
|
|
little less typing.
|
|
</para>
|
|
<para>Note that you have to enter the mount point into the
|
|
<filename>/etc/fstab</filename> file to keep it indefinitely.
|
|
The mount command will only add the mount point for the lifetime
|
|
of your current Cygwin session.
|
|
</para>
|
|
<para>You can change the default <literal>cygdrive</literal> prefix and whether it is binmode or textmode using the <filename>/etc/fstab</filename> file
|
|
as well. See the Cygwin User's Guide at
|
|
<ulink url="https://cygwin.com/cygwin-ug-net/using.html#mount-table"/>
|
|
for more details.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.copy-and-paste">
|
|
<question><para>How can I copy and paste into Cygwin console windows?</para></question>
|
|
<answer>
|
|
|
|
<para>First, consider using mintty instead of the standard console
|
|
window. In mintty, selecting with the left-mouse also copies,
|
|
and middle-mouse pastes. It couldn't be easier!
|
|
</para>
|
|
<para>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.
|
|
</para>
|
|
<para>You can also bind the insert key to paste from the clipboard by adding
|
|
the following line to your .inputrc file:
|
|
<screen>
|
|
"\e[2~": paste-from-clipboard
|
|
</screen>
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.firewall">
|
|
<question><para>What firewall should I use with Cygwin? </para></question>
|
|
<answer>
|
|
|
|
<para>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).
|
|
</para>
|
|
<para>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.
|
|
</para>
|
|
<para>See also <ulink url="https://cygwin.com/faq/faq.html#faq.using.bloda"/>
|
|
for a list of applications that have been known, at one time or another, to
|
|
interfere with the normal functioning of Cygwin.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.sharing-files">
|
|
<question><para>How can I share files between Unix and Windows?</para></question>
|
|
<answer>
|
|
|
|
<para>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 <literal>scp</literal>, <literal>ftp</literal>,
|
|
<literal>rsync</literal>, ...
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.case-sensitive">
|
|
<question><para>Is Cygwin case-sensitive??</para></question>
|
|
<answer>
|
|
|
|
<para>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
|
|
<literal>Makefile</literal> and <literal>makefile</literal>. Windows can't
|
|
tell the difference between files with just different case, so the
|
|
configuration fails.
|
|
</para>
|
|
<para>To help with this problem, Cygwin supports case sensitivity. For a
|
|
detailed description how to use that feature see the Cygwin User's Guide at
|
|
<ulink url="https://cygwin.com/cygwin-ug-net/using-specialnames.html"/>.
|
|
</para>
|
|
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.dos-filenames">
|
|
<question><para>What about DOS special filenames?</para></question>
|
|
<answer>
|
|
|
|
<para>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
|
|
<literal>aux.sh</literal>. The perl configuration tries to make sure that
|
|
<literal>aux.sh</literal> is there, but an operation on a file with the magic
|
|
letters 'aux' in it will hang.
|
|
</para>
|
|
<para>At least that's what happens when using native Windows tools. Cygwin
|
|
can deal with these filenames just fine. Again, see the User's Guide at
|
|
<ulink url="https://cygwin.com/cygwin-ug-net/using-specialnames.html"/>
|
|
for a detailed description of what's possible with filenames and what is not.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.hangs">
|
|
<question><para>When it hangs, how do I get it back?</para></question>
|
|
<answer>
|
|
|
|
<para>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.
|
|
</para>
|
|
<para>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.
|
|
</para>
|
|
<para>And, if all else fails, there's always the reset button/power switch.
|
|
In theory this should never be necessary, though.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.directory-structure">
|
|
<question><para>Why the weird directory structure?</para></question>
|
|
<answer>
|
|
|
|
<para>Why do /lib and /usr/lib (and /bin, /usr/bin) point to the same thing?
|
|
</para>
|
|
<para>Why use mounts instead of symbolic links?
|
|
</para>
|
|
<para>Can I use a disk root (e.g., C:\) as Cygwin root? Why is this discouraged?
|
|
</para>
|
|
<para>After a new installation in the default location, your mount points will
|
|
look something like this:
|
|
</para>
|
|
<screen>
|
|
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)
|
|
</screen>
|
|
|
|
<para>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 <emphasis>really</emphasis> know what you are doing.
|
|
</para>
|
|
<para>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.
|
|
</para>
|
|
<para>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.
|
|
</para>
|
|
<para>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. <emphasis>So don't do this!</emphasis>
|
|
</para>
|
|
<para>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?)
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.anti-virus">
|
|
<question><para>How do anti-virus programs like Cygwin?</para></question>
|
|
<answer>
|
|
|
|
<para>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.)
|
|
</para>
|
|
<para>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.
|
|
</para>
|
|
<para>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 <literal>C:\cygwin\bin</literal>. Obviously, this could be
|
|
exploited by a hostile non-Cygwin program, so do this at your own risk.
|
|
</para>
|
|
<para>See also <ulink url="https://cygwin.com/faq/faq.html#faq.using.bloda"/>
|
|
for a list of applications that have been known, at one time or another, to
|
|
interfere with the normal functioning of Cygwin.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.emacs">
|
|
<question><para>Is there a Cygwin port of GNU Emacs?</para></question>
|
|
<answer>
|
|
|
|
<para>Yes. Install the emacs package. This provides everything you
|
|
need in order to run GNU emacs in a terminal window. If you also want
|
|
to be able to use the X11
|
|
(<ulink url="https://x.cygwin.com/"/>)
|
|
GUI, install the emacs-X11 package. In either case, you run emacs by
|
|
typing 'emacs' or '/usr/bin/emacs'.
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.xemacs">
|
|
<question><para>Is there a Cygwin port of XEmacs?</para></question>
|
|
<answer>
|
|
|
|
<para>Yes. It can be used in three different modes:</para>
|
|
<para><itemizedlist>
|
|
<listitem><para>X11 (<ulink url="https://x.cygwin.com/"/>) GUI</para></listitem>
|
|
</itemizedlist></para>
|
|
<para>You have to <emphasis>set</emphasis> the DISPLAY environment variable
|
|
before starting xemacs.</para>
|
|
<screen>
|
|
bash$ DISPLAY=127.0.0.1:0 xemacs &
|
|
</screen>
|
|
<para><itemizedlist>
|
|
<listitem><para>Windows native GUI</para></listitem>
|
|
</itemizedlist></para>
|
|
<para>You have to <emphasis>unset</emphasis> the DISPLAY environment variable
|
|
before starting xemacs.</para>
|
|
<screen>
|
|
bash$ DISPLAY= xemacs &
|
|
</screen>
|
|
<para><itemizedlist>
|
|
<listitem><para>Console mode</para></listitem>
|
|
</itemizedlist></para>
|
|
<para>Start xemacs with -nw in a terminal (native or X11) window</para>
|
|
<screen>
|
|
bash$ xemacs -nw
|
|
</screen>
|
|
<para>To use all the standard packages with XEmacs you should download the following
|
|
two packages:</para>
|
|
<para><itemizedlist>
|
|
<listitem><para>xemacs-sumo - XEmacs standard packages</para></listitem>
|
|
<listitem><para>xemacs-mule-sumo - XEmacs MULE (MUlti Lingual Emacs) packages</para></listitem>
|
|
</itemizedlist></para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.symlinkstoppedworking">
|
|
<question><para>Why don't some of my old symlinks work anymore?</para></question>
|
|
<answer>
|
|
|
|
<para>Cygwin supports multiple character sets. Symlinks created with Cygwin
|
|
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.</para>
|
|
|
|
<para>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.</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.symlinks-samba">
|
|
<question><para>Why don't symlinks work on Samba-mounted filesystems?</para></question>
|
|
<answer>
|
|
|
|
<para>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:
|
|
</para>
|
|
<screen>
|
|
map system = yes
|
|
create mask = 0775
|
|
</screen>
|
|
|
|
<para>Note that the 0775 can be anything as long as the 0010 bit is set.
|
|
</para>
|
|
<para>Alternatively, use Windows shortcuts as symlinks. See the CYGWIN
|
|
environment variable option "winsymlinks"
|
|
<ulink url="https://cygwin.com/cygwin-ug-net/using-cygwinenv.html"/>
|
|
</para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.sshd-in-domain">
|
|
<question><para>How do I setup sshd in a domain?</para></question>
|
|
<answer>
|
|
|
|
<para>
|
|
If you want to be able to logon with domain accounts to a domain member
|
|
machine, you should make sure that the "cyg_server" account under which
|
|
the sshd service is usually running, is a domain account. Otherwise you
|
|
might end up with weird problems. For instance, sshd might fail to load
|
|
the child process when trying to login with a domain account. A potential,
|
|
confirmed error message is
|
|
</para>
|
|
|
|
<screen>
|
|
*** fatal error - unable to load user32.dll, Win32 error 1114
|
|
</screen>.
|
|
|
|
<para>
|
|
Here's how you set up a sshd with a domain service account.
|
|
</para>
|
|
|
|
<para>
|
|
First of all, create a new domain account called "cyg_server". This
|
|
account must be an administrative account, so make sure it's in the
|
|
"Administrators" group. Now create a domain policy which is propagated
|
|
to all machines which are supposed to run an sshd service. This domain
|
|
policy should give the following user rights to the "cyg_server" account:
|
|
</para>
|
|
|
|
<screen>
|
|
Act as part of the operating system (SeTcbPrivilege)
|
|
Create a token object (SeCreateTokenPrivilege)
|
|
Replace a process level token (SeAssignPrimaryTokenPrivilege)
|
|
</screen>
|
|
|
|
<para>
|
|
Now to install sshd on the member machine, logon to that machine as
|
|
an admin. Make sure the aforementioend global policy has been propagated
|
|
to this machine. Examine the Local Security Policy settings and, if
|
|
necessary, call gpupdate.
|
|
</para>
|
|
|
|
<para>
|
|
If everything looks ok, run bash. Starting with Windows Vista, make
|
|
sure you're running bash elevated.
|
|
</para>
|
|
|
|
<para>
|
|
Then run ssh-host-config. Answer all questions so that "cyg_server" is
|
|
used to run the service. When done, check ownership of
|
|
<literal>/var/empty</literal> and all <literal>/etc/ssh*</literal>
|
|
files. All of them must be owned by "cyg_server". If that's ok, you're
|
|
usually all set and you can start the sshd service via
|
|
</para>
|
|
|
|
<screen>
|
|
$ cygrunsrv -S sshd
|
|
</screen>
|
|
|
|
<para>or</para>
|
|
|
|
<screen>
|
|
$ net start sshd
|
|
</screen>
|
|
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.ssh-pubkey-stops-working">
|
|
<question><para>Why does public key authentication with ssh fail after updating to Cygwin 1.7.34 or later?</para></question>
|
|
<answer>
|
|
|
|
<para>
|
|
This is the result of fixing a long-standing security problem in Cygwin's
|
|
POSIX ACL handling. IEEE 1003.1e draft 17 defines that the permissions
|
|
of secondary user and group entries in an ACL are reflected in the group
|
|
permission mask by or'ing the permissions of the file's primary group with
|
|
all permissions of secondary users and groups in the ACL. The background
|
|
is that this way the standard POSIX permission bits reflect the fact that
|
|
<emphasis role='bold'>somebody else</emphasis> has additional, otherwise
|
|
potentially invisible permissions on the file. This relatively complex
|
|
interface has been defined in order to ensure that applications that are
|
|
compliant with IEEE 1003.1 (“POSIX.1”) will still function as expected on
|
|
systems with ACLs.</para>
|
|
|
|
<para>So, what does that mean for your situation? Typically this means the
|
|
private key file, for instance <filename>~/.ssh/id_rsa</filename>, has too
|
|
open permissions. OpenSSH expects the permissions of the private key file
|
|
to be 0600. Let's use the default SSH2 RSA keyfile as example:</para>
|
|
|
|
<screen>
|
|
$ ls -l .ssh/id_rsa
|
|
-rw------- 1 user group 1766 Aug 26 2013 .ssh/id_rsa
|
|
</screen>
|
|
|
|
<para>However, if other accounts can read the file, the key is potentially
|
|
compromised. Consider the file has additional rw- permissions for a group
|
|
<literal>bad_guys</literal>. Up to Cygwin 1.7.33 that would have looked
|
|
like this:</para>
|
|
|
|
<screen>
|
|
$ ls -l .ssh/id_rsa
|
|
-rw-------+ 1 user group 1766 Aug 26 2013 .ssh/id_rsa
|
|
</screen>
|
|
|
|
<para>Notice the extra <emphasis role='bold'>+</emphasis> character following
|
|
the permission string. This shows that additional ACL entries are in the ACL.
|
|
But an application only checking the POSIX permission bits (and ssh is one of
|
|
them!), will not notice the fact, because it gets the permissions 0600 for the
|
|
file.</para>
|
|
|
|
<para>Starting with Cygwin 1.7.34, the extra permissions are reflected in
|
|
the group permission bits per IEEE 1003.1e draft 17:</para>
|
|
|
|
<screen>
|
|
$ ls -l .ssh/id_rsa
|
|
-rw-rw----+ 1 user group 1766 Aug 26 2013 .ssh/id_rsa
|
|
</screen>
|
|
|
|
<para>So now ssh will notice that the file has extra permissions and it will
|
|
complain. The same problem occurs if the file
|
|
<filename>~/.ssh/authorized_keys</filename> has too open permissions. On
|
|
the client side you won't get any helping text, though, other than that you're
|
|
suddenly asked for a password. That's a rather good hint to have a closer
|
|
look at the server's <filename>~/.ssh/authorized_keys</filename> file.</para>
|
|
|
|
<para>To fix the permissions of your private key file or your
|
|
<filename>~/.ssh/authorized_keys</filename> file, simply use the
|
|
<command>setfacl</command> command with the <literal>-b</literal> option.
|
|
This removes all additional ACL entries and thus fixes the permissions to
|
|
be not too open:</para>
|
|
|
|
<screen>
|
|
$ ls -l .ssh/id_rsa
|
|
-rw-rw----+ 1 user group 1766 Aug 26 2013 .ssh/id_rsa
|
|
$ setfacl -b .ssh/id_rsa
|
|
$ ls -l .ssh/id_rsa
|
|
-rw------- 1 user group 1766 Aug 26 2013 .ssh/id_rsa
|
|
</screen>
|
|
|
|
<para>If the second <command>ls</command> command still gives you
|
|
<computeroutput>-rw-rw----</computeroutput> permissions after running
|
|
the above commands, it is proably because the file's primary group
|
|
is your user's personal group:</para>
|
|
|
|
<screen>
|
|
$ ls -l .ssh/id_rsa
|
|
-rw-rw---- 1 Fred Fred 1766 Aug 26 2013 .ssh/id_rsa
|
|
</screen>
|
|
|
|
<para>Since the Windows security system treats groups and users as
|
|
much the same thing, a change to the user or group permissions on
|
|
such a file reflects the change to both user and group. In effect,
|
|
mode 0600 becomes mode 0660. Because we are saying we want these
|
|
files to be readable only by our user, the fix for this is easy:</para>
|
|
|
|
<screen>
|
|
$ chgrp `id -g` ~/.ssh/*
|
|
</screen>
|
|
|
|
<para>That resets the group on these files to your default group
|
|
which should be something like <computeroutput>Users</computeroutput>,
|
|
depending on your local configuration. If that doesn't work, you can
|
|
try something like this instead:</para>
|
|
|
|
<screen>
|
|
$ chgrp None ~/.ssh/*
|
|
</screen>
|
|
|
|
<para>That group always exists, but its name is different on
|
|
non-English versions of Windows. You might also want to use a
|
|
domain group instead of a local group if your site uses Windows
|
|
domains. For example, you might want to use the <computeroutput>Domain
|
|
Users</computeroutput> group instead.</para>
|
|
|
|
<para>For more information on <command>setfacl</command>, see
|
|
<ulink url="https://cygwin.com/cygwin-ug-net/using-utils.html#setfacl"/></para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.same-with-rhosts">
|
|
<question><para>Why is my .rhosts file not recognized by rlogin anymore after updating to Cygwin 1.7.34?</para></question>
|
|
<answer>
|
|
|
|
<para>The problem is exactly the same as with the key files of SSH. See
|
|
<xref linkend="faq.using.ssh-pubkey-stops-working"/>.</para>
|
|
|
|
<para>The solution is the same:</para>
|
|
|
|
<screen>
|
|
$ ls -l .rhosts
|
|
-rw-rw----+ 1 user group 42 Nov 12 2010 .rhosts
|
|
$ setfacl -b .rhosts
|
|
$ ls -l .rhosts
|
|
-rw------- 1 user group 42 Nov 12 2010 .rhosts
|
|
</screen>
|
|
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.same-with-permissions">
|
|
<question><para>Why do my files have extra permissions after updating to Cygwin 1.7.34?</para></question>
|
|
<answer>
|
|
|
|
<para>The problem is exactly the same as with the key files of SSH. See
|
|
<xref linkend="faq.using.ssh-pubkey-stops-working"/>.</para>
|
|
|
|
<para>The solution is the same:</para>
|
|
|
|
<screen>
|
|
$ ls -l *
|
|
-rw-rwxr--+ 1 user group 42 Nov 12 2010 file1
|
|
-rw-rwxr--+ 1 user group 42 Nov 12 2010 file2
|
|
$ setfacl -b *
|
|
$ ls -l *
|
|
-rw-r--r-- 1 user group 42 Nov 12 2010 file1
|
|
-rw-r--r-- 1 user group 42 Nov 12 2010 file2
|
|
</screen>
|
|
|
|
<para>You may find that newly-created files also have unexpected
|
|
permissions:</para>
|
|
|
|
<screen>
|
|
$ touch foo
|
|
$ ls -l foo
|
|
-rw-rwxr--+ 1 user group 42 Nov 12 2010 foo
|
|
</screen>
|
|
|
|
<para>This probably means that the directory in which you're creating
|
|
the files has unwanted default ACL entries that are inherited by
|
|
newly-created files and subdirectories. The solution is again the
|
|
same:</para>
|
|
|
|
<screen>
|
|
$ setfacl -b .
|
|
$ touch bar
|
|
$ ls -l bar
|
|
-rw-r--r-- 1 user group 42 Nov 12 2010 bar
|
|
</screen>
|
|
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.tcl-tk">
|
|
<question><para>Why do my Tk programs not work anymore?</para></question>
|
|
<answer>
|
|
|
|
<para>Previous versions of Tcl/Tk distributed with Cygwin (e.g. tclsh84.exe,
|
|
wish84.exe) were not actually "Cygwin versions" of those tools.
|
|
They were built as native libraries, which means they did not understand
|
|
Cygwin mounts or symbolic links. This lead to all sorts of problems interacting
|
|
with true Cygwin programs.</para>
|
|
|
|
<para>As of February 2012, this was replaced with a version of Tcl/Tk which
|
|
uses Cygwin's POSIX APIs and X11 for GUI functionality. If you get a message
|
|
such as this when trying to start a Tk app:</para>
|
|
|
|
<screen>
|
|
Application initialization failed: couldn't connect to display ""
|
|
</screen>
|
|
|
|
<para>Then you need to start an X server, or if one is already running, set the
|
|
<literal>DISPLAY</literal> variable to the proper value. The Cygwin distribution
|
|
includes an X server; please see the <ulink url="https://x.cygwin.com/docs/ug/cygwin-x-ug.html">Cygwin/X User Guide</ulink>
|
|
for installation and startup instructions.
|
|
</para></answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.ipv6">
|
|
<question><para>Why do I get "Address family not supported" errors when playing with IPv6?</para></question>
|
|
<answer>
|
|
|
|
<para>IPv6 is only fully supported and available right from the start
|
|
beginning with Windows Vista and Windows Server 2008.</para>
|
|
|
|
<para>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. Note, however, that the IPv6 stack on these systems
|
|
don't fully support all features of IPv6.</para>
|
|
|
|
<para>For more information about IPv6 on Windows and how to install the
|
|
IPv6 stack, see the <ulink url="http://www.microsoft.com/technet/network/ipv6/ipv6faq.mspx">Microsoft TechNet IPv6 FAQ article</ulink>
|
|
</para></answer></qandaentry>
|
|
|
|
<qandaentry id="faq.using.bloda" xreflabel="BLODA">
|
|
<question><para>What applications have been found to interfere with Cygwin?</para></question>
|
|
<answer>
|
|
|
|
<para>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.
|
|
</para>
|
|
<para>Among the software that has been found to cause difficulties are:</para>
|
|
<para><itemizedlist>
|
|
<listitem><para>AR Soft RAM Disk</para></listitem>
|
|
<listitem><para>ATI Catalyst (some versions)</para></listitem>
|
|
<listitem><para>AVAST (disable FILESYSTEM and BEHAVIOR realtime shields)</para></listitem>
|
|
<listitem><para>Avira AntiVir</para></listitem>
|
|
<listitem><para>BitDefender</para></listitem>
|
|
<listitem><para>Bufferzone from Trustware</para></listitem>
|
|
<listitem><para>ByteMobile laptop optimization client</para></listitem>
|
|
<listitem><para>COMODO Firewall Pro</para></listitem>
|
|
<listitem><para>Citrix Metaframe Presentation Server/XenApp (see <ulink url="http://support.citrix.com/article/CTX107825">Citrix Support page</ulink>)</para></listitem>
|
|
<listitem><para>Credant Guardian Shield</para></listitem>
|
|
<listitem><para>Earthlink Total-Access</para></listitem>
|
|
<listitem><para>Forefront TMG</para></listitem>
|
|
<listitem><para>Google Desktop</para></listitem>
|
|
<listitem><para>Iolo System Mechanic/AntiVirus/Firewall</para></listitem>
|
|
<listitem><para>Kerio, Agnitum or ZoneAlarm Personal Firewall</para></listitem>
|
|
<listitem><para>LanDesk</para></listitem>
|
|
<listitem><para>Lavasoft Web Companion</para></listitem>
|
|
<listitem><para>Lenovo IPS Core Service (ipssvc)</para></listitem>
|
|
<listitem><para>Lenovo RapidBoot Shield</para></listitem>
|
|
<listitem><para>Logitech webcam software with "Logitech process monitor" service</para></listitem>
|
|
<listitem><para>MacType</para></listitem>
|
|
<listitem><para>NOD32 Antivirus</para></listitem>
|
|
<listitem><para>NVIDIA GeForce (some versions)</para></listitem>
|
|
<listitem><para>Norton/McAfee/Symantec antivirus or antispyware</para></listitem>
|
|
<listitem><para>PC Tools Spyware Doctor</para></listitem>
|
|
<listitem><para>Panda Internet Security</para></listitem>
|
|
<listitem><para>Sonic Solutions burning software containing DLA component (when DLA disabled)</para></listitem>
|
|
<listitem><para>Sophos Anti-Virus 7</para></listitem>
|
|
<listitem><para>Spybot S&D TeaTimer</para></listitem>
|
|
<listitem><para>Various programs by Wave Systems Corp using wxvault.dll, including Embassy Trust Suite and Embassy Security Center</para></listitem>
|
|
<listitem><para>Webroot Spy Sweeper with Antivirus</para></listitem>
|
|
<listitem><para>Windows Defender </para></listitem>
|
|
<listitem><para>Windows LiveOneCare</para></listitem>
|
|
</itemizedlist></para>
|
|
<para>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.
|
|
</para>
|
|
<para>Some of the symptoms you may experience are:</para>
|
|
<para><itemizedlist>
|
|
<listitem>
|
|
<para>Random fork() failures</para>
|
|
<para>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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>File access problems</para>
|
|
<para>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.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Networking issues</para>
|
|
<para>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.</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>Memory and/or handle leaks</para>
|
|
<para>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.</para>
|
|
</listitem>
|
|
</itemizedlist></para>
|
|
</answer></qandaentry>
|
|
|
|
<qandaentry id='faq.using.fixing-fork-failures'>
|
|
<question><para>How do I fix <literal>fork()</literal> failures?</para></question>
|
|
<answer>
|
|
<para>Unfortunately, Windows does not use the fork/exec model of process creation
|
|
found in UNIX-like OSes, so it is difficult for Cygwin to implement a reliable and
|
|
correct <literal>fork()</literal>, which can lead to error messages such as:</para>
|
|
<para><itemizedlist>
|
|
<listitem>unable to remap <emphasis>somedll</emphasis> to same address as parent</listitem>
|
|
<listitem>couldn't allocate heap</listitem>
|
|
<listitem>died waiting for dll loading</listitem>
|
|
<listitem>child -1 - died waiting for longjmp before initialization</listitem>
|
|
<listitem>STATUS_ACCESS_VIOLATION</listitem>
|
|
<listitem>resource temporarily unavailable</listitem>
|
|
</itemizedlist></para>
|
|
<para>Potential solutions for the above errors:</para>
|
|
<para><itemizedlist>
|
|
<listitem>Restart whatever process is trying (and failing) to use
|
|
<literal>fork()</literal>. Sometimes Windows sets up a process
|
|
environment that is even more hostile to <literal>fork()</literal> than usual.</listitem>
|
|
<listitem>Ensure that you have eliminated (not just disabled) all
|
|
software on the <xref linkend="faq.using.bloda"/>.
|
|
</listitem>
|
|
<listitem>Switch from 32-bit Cygwin to 64-bit Cygwin, if your OS and CPU support that.
|
|
With the bigger address space <literal>fork()</literal> is less likely to fail.</listitem>
|
|
<listitem>
|
|
<para>
|
|
Try setting the environment variable CYGWIN to "detect_bloda", which
|
|
enables some extra debugging, which may indicate what other software is
|
|
causing the problem.
|
|
</para>
|
|
<para>
|
|
See <ulink url="https://cygwin.com/ml/cygwin/2012-02/msg00797.html">this
|
|
mail</ulink> for more information.
|
|
</para>
|
|
</listitem>
|
|
<listitem>
|
|
<para>
|
|
Force a full rebase: Run <command>rebase-trigger fullrebase</command>,
|
|
exit all Cygwin programs and run Cygwin setup.
|
|
</para>
|
|
<para>
|
|
By default, Cygwin's setup program automatically performs an incremental
|
|
rebase of newly installed files. Forcing a full rebase causes the
|
|
rebase map to be cleared before doing the rebase.
|
|
</para>
|
|
<para>
|
|
See <literal>/usr/share/doc/rebase/README</literal> and
|
|
<literal>/usr/share/doc/Cygwin/_autorebase.README</literal> for more
|
|
details.
|
|
</para>
|
|
<para>Please note that installing new packages or updating existing
|
|
ones undoes the effects of rebase and often causes fork() failures to
|
|
reappear.
|
|
</para>
|
|
</listitem>
|
|
</itemizedlist></para>
|
|
<para>See the <ulink url="https://cygwin.com/cygwin-ug-net/highlights.html#ov-hi-process">
|
|
process creation</ulink> section of the User's Guide for the technical reasons it is so
|
|
difficult to make <literal>fork()</literal> work reliably.</para>
|
|
</answer>
|
|
</qandaentry>
|
|
</qandadiv>
|