1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
|
<!-- 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="http://cygwin.com/ml/cygwin/2002-01/msg01619.html">http://cygwin.com/ml/cygwin/2002-01/msg01619.html</ulink>.
</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="http://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/cygwin.bat
/usr/bin/cygwin.bat
bash$ cygpath --unix C:\\cygwin\\bin\\cygwin.bat
/usr/bin/cygwin.bat
</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 /etc/passwd entry) 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="http://www.cygwin.com/ml/cygwin/2003-06/msg00897.html">http://www.cygwin.com/ml/cygwin/2003-06/msg00897.html</ulink> and
related messages.
</para>
</answer></qandaentry>
<qandaentry id="faq.using.man">
<question><para>Why doesn't man -k (or apropos) work?</para></question>
<answer>
<para>Before you can use <literal>man -k</literal> or <literal>apropos</literal>, you
must create the whatis database. Just run the command
</para>
<screen>
/usr/sbin/makewhatis
</screen>
<para>(it may take a minute to complete).
</para>
</answer></qandaentry>
<qandaentry id="faq.using.chmod">
<question><para>Why doesn't <literal>chmod</literal> work?</para></question>
<answer>
<para>The most common case is that your <literal>/etc/passwd</literal>
or <literal>/etc/group</literal> files are not properly set up. If
<literal>ls -l</literal> shows a group of <literal>mkpasswd</literal>
or <literal>mkgroup</literal>, you need to run one or both of those
commands.
</para>
<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="http://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 <ulink url="http://cygwin.com/setup.exe">setup.exe</ulink> cygutils package. Some <ulink url="http://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="http://cygwin.com/ml/cygwin/2001-04/msg00657.html">http://cygwin.com/ml/cygwin/2001-04/msg00657.html</ulink>. Note that the
<literal>file</literal> command is now available as part of Cygwin setup.
</para>
<para>Alternatively, you can use the Windows <literal>print</literal>
command. (It does not seem to be available on Win9x.) 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 <literal>cat</literal> 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="http://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>
<para>To type international characters (£äö) in
<literal>bash</literal>, check if the following settings are available in
your <literal>bash</literal>, and if not, add them to your
<literal>~/.inputrc</literal> file and restart <literal>bash</literal>:
</para>
<screen>
set meta-flag on
set convert-meta off
set output-meta on
set input-meta on
</screen>
<para>These are options to the <literal>readline</literal> library, which
you can read about in the <literal>bash(1)</literal> and
<literal>readline(3)</literal> man pages. Other tools that do not use
<literal>readline</literal> for display, such as <literal>less</literal>
and <literal>ls</literal>, might require additional settings for doublebyte
or multibyte charsets, which could be put
in your <literal>~/.bashrc</literal>, for instance:
<screen>
alias less='/bin/less -r'
alias ls='/bin/ls -F --color=tty --show-control-chars'
</screen>
</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>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,
make 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
<literal>Cygwin.bat</literal> file from which you start your Cygwin shell.
</para>
<para>
For a more detailed explanation see the section
<ulink url="http://cygwin.com/cygwin-ug-net/setup-locale.html#setup-locale-console">The Windows Console character set</ulink> in the Cygwin User's Guide.</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>You should only have one copy of the Cygwin DLL on your system. If you
have multiple versions, they will conflict and cause problems.
</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. This could happen,
for example, if you update cygwin1.dll without exiting
<emphasis>all</emphasis> Cygwin apps (including inetd) beforehand.
</para>
<para>The only DLL that is sanctioned by the Cygwin project is the one that
you get by running <ulink url="http://cygwin.com/setup.exe">setup.exe</ulink>,
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
<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>
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)
</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="http://cygwin.com/license.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.private-cygwin">
<question><para>
So I can't install a private version of the Cygwin DLL without
conflicting with the system cygwin?
</para></question>
<answer><para>
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.
</para>
<para>This usage is not recommeded for novices. Only limited support will be
provided in the <ulink url="http://cygwin.com/lists.html">mailing lists</ulink>
if you run into problems.
</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="http://cygwin.com/setup.html">http://cygwin.com/setup.html</ulink>.
</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="http://cygwin.com/cygwin-ug-net/using.html#mount-table">http://cygwin.com/cygwin-ug-net/using.html#mount-table</ulink>
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 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!
</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="http://cygwin.com/faq/faq.using.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 casesensitivity
starting with Cygwin 1.7.0. For a detailed description how to use that
feature see the Cygwin User's Guilde at
<ulink url="http://cygwin.com/cygwin-ug-net/using-specialnames.html">http://cygwin.com/cygwin-ug-net/using-specialnames.html</ulink>.
</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
1.7.0 and later can deal with these filenames just fine. Again, see the
User's Guide at
<ulink url="http://cygwin.com/cygwin-ug-net/using-specialnames.html">http://cygwin.com/cygwin-ug-net/using-specialnames.html</ulink>
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="http://cygwin.com/faq/faq.using.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="http://cygwin.com/xfree/">http://cygwin.com/xfree/</ulink>)
GUI, install the emacs-X11 package. In either case, you run emacs by
typing 'emacs' or '/usr/bin/emacs'. If you run emacs in the cygwin
console, be sure that your CYGWIN environment variable contains tty.
See /usr/share/doc/Cygwin/emacs.README for further information.
</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="http://cygwin.com/xfree/">http://cygwin.com/xfree/</ulink>) 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>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.
</para>
<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>
<para>An alternative <emphasis>native</emphasis> distribution of XEmacs for
Windows based systems can be downloaded from
<ulink url="http://xemacs.org/Download/win32/index.html">http://xemacs.org/Download/win32/index.html</ulink>.
It uses an <emphasis>InnoSetup Kit</emphasis> based installer.</para>
</answer></qandaentry>
<qandaentry id="faq.using.ntemacs">
<question><para>What about NT Emacs?</para></question>
<answer>
<para>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
<ulink url="http://www.gnu.org/software/emacs/windows/Getting-Emacs.html#Getting-Emacs">Where can I get pre-compiled versions?</ulink> in NT Emacs FAQ.
</para>
<para>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 (<ulink url="http://jdee.sunsite.dk/">http://jdee.sunsite.dk/</ulink>). The following
settings are for Emacs 21.1:
</para>
<screen>
;; ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;; 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]*[$] ?"))))
</screen>
<para>If you want NT Emacs to understand Cygwin paths, get
cygwin-mount.el from <ulink url="http://www.emacswiki.org/elisp/index.html">http://www.emacswiki.org/elisp/index.html</ulink>.
</para>
<para>Note that all of this ``just works'' if you use the Cygwin port of
Emacs or XEmacs from Cygwin Setup.
</para>
</answer></qandaentry>
<qandaentry id="faq.using.console-window">
<question><para>Is there a better alternative to the standard console window?</para></question>
<answer>
<para>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.
</para>
</answer></qandaentry>
<qandaentry id="faq.using.symlinkstoppedworking">
<question><para>Why do some of my old symlinks don't work anymore?</para></question>
<answer>
<para>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.</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="http://cygwin.com/cygwin-ug-net/using-cygwinenv.html">http://cygwin.com/cygwin-ug-net/using-cygwinenv.html</ulink>
</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 as well. Here's
how you set this up.
</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>
If "cyg_server" is not already in <literal>/etc/passwd</literal>, add it
using <literal>mkpasswd</literal>. Make sure all domain accounts which are
supposed to be able to logon via ssh are in <literal>/etc/passwd</literal>.
Also make sure that all important domain groups are in
<literal>/etc/group</literal>. If in doubt, call
</para>
<screen>
$ mkpasswd -l -d your_domain > /etc/passwd
$ mkgroup -l -d your_domain > /etc/group
</screen>
<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.tcl-tk">
<question><para>Why doesn't Cygwin tcl/tk understand Cygwin paths?</para></question>
<answer>
<para>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.
</para>
<para>See the entry "How do I convert between Windows and UNIX paths?"
elsewhere in this FAQ.
</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>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.</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">
<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>Sonic Solutions burning software containing DLA component (when DLA disabled)</para></listitem>
<listitem><para>Norton/McAfee/Symantec antivirus or antispyware</para></listitem>
<listitem><para>Logitech webcam software with "Logitech process monitor" service</para></listitem>
<listitem><para>Kerio, Agnitum or ZoneAlarm Personal Firewall</para></listitem>
<listitem><para>Iolo System Mechanic/AntiVirus/Firewall</para></listitem>
<listitem><para>LanDesk</para></listitem>
<listitem><para>Windows Defender </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>NOD32 Antivirus</para></listitem>
<listitem><para>ByteMobile laptop optimization client</para></listitem>
<listitem><para>Earthlink Total-Access</para></listitem>
<listitem><para>Spybot S&D TeaTimer</para></listitem>
<listitem><para>AR Soft RAM Disk</para></listitem>
<listitem><para>ATI Catalyst drivers</para></listitem>
<listitem><para>Windows LiveOneCare</para></listitem>
<listitem><para>Webroot Spy Sweeper with Antivirus</para></listitem>
<listitem><para>COMODO Firewall Pro</para></listitem>
<listitem><para>PC Tools Spyware Doctor</para></listitem>
<listitem><para>Avira AntiVir</para></listitem>
<listitem><para>Panda Internet Security</para></listitem>
<listitem><para>BitDefender</para></listitem>
<listitem><para>Google Desktop</para></listitem>
<listitem><para>Sophos Anti-Virus 7</para></listitem>
<listitem><para>Bufferzone from Trustware</para></listitem>
<listitem><para>Lenovo IPS Core Service (ipssvc)</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>
|