Re: Timestamps
On Aug 27 02:28, Wes S wrote: > Replying to my own email for archives. > > I didn't have syslogd running. Install script /bin/syslogd-config > I initially installed sshd with: > cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a '-D -e' > changed to cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a '-D' > Now I'm happier. > > Wes > > On 26 Aug 2005 at 10:05, Wes S wrote: > > > I'm using exim and sshd which is working wonderfully on my w2k box. > > > > My cygwin programs are recent as of the last 7 days if that matters. > > > > What I can't figure out is how to get time/date stamps on the log > > files such as sshd.log and exim_main.log. I got entries but when > > they were made, who knows. For the records, if syslogd is not running, the syslog output goes to the Windows event log, which also maintains timestamps. The service log files created in /var/log only contain the stdout and stderr output of the services. Switching on syslogd will not redirect stdout/stderr output to syslogd, but only the syslog output. But usually this doesn't matter since "real" services are logging the important stuff to the syslog anyway and stdout/stderr is only used for debugging output. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem with sh/bash and snapshot cygwin1-20050825.dll
On Aug 26 14:30, Eric Blake wrote: > $ readlink u > x > $ ls x* > x.exe > $ ls -lF x > - -rwxr-xr-x 1 eblake None 13961 Mar 10 06:54 x* > $ file x# See below for more on this... > x: writable, executable, regular file, no read permission > $ ./myreadlink u/blah > 'u/blah': NULL, 2 No such file or directory > > You are right that the code is correctly giving ENOTDIR when the symlink > isn't half-dangling (ie stat() succeeds but open() fails): > $ readlink u.exe > x.exe > $ ./myreadlink u/blah > 'u/blah': NULL, 20 Not a directory That's a result of attaching .exe to symlinks. When iterating over paths, the .exe suffix is only checked on the last component, never on inner (== directory) components. This makes sense, otherwise every component has to tested twice as often, which would slow down Cygwin a lot. I don't see a good reason to change that, just for the (questionable) success, to exchange one errno for another. After all, EINVAL is correct, as would be ENOTDIR. I don't see that POSIX demands an order of errnos in the case where two or more different errnos are correct. For instance, consider a function which treats the first parameter as invalid if it's NULL, and which copies something into the space where the second parameter points to: int err = foo (NULL, (void *) 0x01); Which errno is correct to return, EINVAL or EFAULT? Btw., what was the exact reason to attach the .exe suffix to symlinks pointing to executables? I fail to see the advantage, right now. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader mailto:cygwin@cygwin.com Red Hat, Inc. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Emacs from cygwin in X mode with no X running
"James R. Phillips" <[EMAIL PROTECTED]> writes: > Have you actually tried installing the x-server and using it? It takes a > while Yes. I just wanted to stay away from extra stuff. But as you surmised, not if it requires huge energy output. > to download, but can be used somewhat unobtrusively. > The default startxwin.sh shell script starts xwin in the multiwindow mode, > which means you get a black X icon in the system tray when there are no X > clients, and otherwise each client opens in a fairly normal looking window on > the windows desktop. If you comment out the xterm invocation in the script, > you mostly don't need to be aware that X is running. Client windows will just This sounds like a handy way to go at it. I wasn't clever enough to think to edit the startx script. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Problem with sh/bash and snapshot cygwin1-20050825.dll
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Corinna Vinschen on 8/27/2005 2:44 AM:
>
> That's a result of attaching .exe to symlinks. When iterating over
> paths, the .exe suffix is only checked on the last component, never
> on inner (== directory) components. This makes sense, otherwise every
> component has to tested twice as often, which would slow down Cygwin
> a lot. I don't see a good reason to change that, just for the
> (questionable) success, to exchange one errno for another.
OK - I see what is happening. When u (not u.exe) is a symlink to x
(although only x.exe exists), then path resolution of u/something tries to
dereference u, looks for directory x, and since no x exists, reports
ENOENT instead of ENOTDIR. And this is correct, since there really is no
x. This is a case where u is a half-broken symlink - for the purposes of
exec*(), u resolves to x.exe, but for the purposes of open(), u fails to
resolve with ENOENT. So there is no bug in realpath() in this regards.
>
> Btw., what was the exact reason to attach the .exe suffix to symlinks
> pointing to executables? I fail to see the advantage, right now.
Which .exe are you asking about? If only x.exe exists, and you do 'ln -s
x u', there are several options:
create u, pointing to x (u is half-broken - it works in exec but not open)
create u, pointing to x.exe (u is a working symlink, but 'readlink u' does
not show the user's spelling, and there is no indication the magic happened)
create u.exe, pointing to x.exe (u is a working symlink, and the extension
to u hints why the user's spelling was changed)
Right now, coreutils does the latter. Furthermore, the current extension
search order of cygwin is none, .exe, .exe.lnk, and then .lnk, so naming a
link to an .exe with .exe is slightly faster than leaving the .exe off
(although it does seem a bit inconsistent to me that if both x and x.exe
are regular files, stat("x") finds x, but if both are symlinks, stat("x")
finds the x.exe link).
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDEIY084KuGfSFAYARAqvpAJ9jIZg7N2/d4YPKBQApyLRwNttXPgCgyQh8
NCEVMRFZobvnUT24R1p0kIs=
=0e7C
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Site changes
Please, read the document. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Spaces in Environment Variables
If I set environment variables to paths that have spaces in them they don't work right with common shell commands. Does anybody know a work around for this? For example: --SHELL $ PF="/cygdrive/c/Program\ Files" $ export PF $ cd $PF : cd: /cygdrive/c/Program\: No such file or directory $ ls $PF ls: /cygdrive/c/Program\: No such file or directory ls: Files: No such file or directory --SHELL __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Spaces in Environment Variables
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Jesse Hogan on 8/27/2005 3:38 PM: > If I set environment variables to paths that have > spaces in them they don't work right with common shell > commands. Does anybody know a work around for this? Read up on shells; this problem is not unique to cygwin (although cygwin tends to be more likely to expose it, since Windows is more likely to have spaces in filenames). Bash splits words on spaces after expanding variables, unless the variables are double quoted. > $ cd $PF cd "$PF" - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] volunteer cygwin bash maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDEN5s84KuGfSFAYARAlf4AJ9IF5xvUpbaCJD/+q2unbBxaXCiKwCggDr0 B93BmvBkUwnkNKTMPDbzsdo= =ymnC -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Spaces in Environment Variables
Jesse Hogan wrote: > $ PF="/cygdrive/c/Program\ Files" > $ export PF > $ cd $PF > : cd: /cygdrive/c/Program\: No such file or directory > $ ls $PF > ls: /cygdrive/c/Program\: No such file or directory > ls: Files: No such file or directory You are simultaneously overquoting and underquoting. When you assign a value to PF you need to use either quotes or backslash-escapes, but not both. When you 'cd' you need to quote the argument if it contains spaces. $ export PF="/cygdrive/c/Program Files" $ cd "$PF" Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Spaces in Environment Variables
Brian Dessent wrote: > $ export PF="/cygdrive/c/Program Files" > $ cd "$PF" And for the record, I find that it's a heck of a lot easier to do the following once and then never have to deal with this kind of crap again. mount -fsb "c:/Program Files" "/pgf" Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Xargs positioning the arguments in a command -- is this a bug or a feature?
CygWin 1.5.18
I was trying to create a date-time-sortable list of
files with an appended tag for each entry (ham or
spam flag if you care about the detail) and had some
difficulty with xargs:
dir -gGtcr --time-style=+%Y%m%d%X | cut -c 24- | xargs -i -n 2 echo {}
MORE_STUFF
...doesn't work -- i.e., "{}" appears in the output.
However, reversing the switches does work as expected:
dir -gGtcr --time-style=+%Y%m%d%X | cut -c 24- | xargs -n 2 -i echo {}
MORE_STUFF
I am curious if this is expected behavior as I didn't
see any warning in the xarg --help or man/info entries.
It is an unusual command that requires switches to
appear in a specific order, especially when the
switches are not directly dependent on each other.
--
Herb Martin
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Spaces in Environment Variables
> [mailto:[EMAIL PROTECTED] On Behalf Of Brian Dessent > Sent: Saturday, August 27, 2005 5:00 PM > To: cygwin@cygwin.com > Subject: Re: Spaces in Environment Variables > > Brian Dessent wrote: > > > $ export PF="/cygdrive/c/Program Files" > > $ cd "$PF" > > And for the record, I find that it's a heck of a lot easier > to do the following once and then never have to deal with > this kind of crap again. > > mount -fsb "c:/Program Files" "/pgf" Agreed. A common recommendation in the Windows world is to use C:\progra~1 which is GENERALLY right but not totally reliable if either of the following is true: 1) This is a second copy of Windows installed where an older C:\Progra~1 already existed -- and so we have c:\progra~2 etc. 2) Short names have been disabled (and of course if the Program Files aren't on the C:\ drive path.) My practice (even under pure) Windows is to always setup an alternative path with "linkd". This is effectively the same principle as just going ahead and fixing it with your "mount" suggestion. Thanks for the good suggestion. -- Herb Martin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Xargs positioning the arguments in a command -- is this a bug or a feature?
>
> dir -gGtcr --time-style=+%Y%m%d%X | cut -c 24- | xargs -i -n 2 echo {}
> MORE_STUFF
>
> ...doesn't work -- i.e., "{}" appears in the output.
>
> However, reversing the switches does work as expected:
>
> dir -gGtcr --time-style=+%Y%m%d%X | cut -c 24- | xargs -n 2 -i echo {}
> MORE_STUFF
>
> I am curious if this is expected behavior as I didn't
> see any warning in the xarg --help or man/info entries.
>
> It is an unusual command that requires switches to
> appear in a specific order, especially when the
> switches are not directly dependent on each other.
The upcoming findutils-4.2.25-1 (whenever upstream releases 4.2.25)
better documents this. -i is being deprecated in favor of POSIX -I, which
requires an argument, whereas the non-standard -i treated its
argument as optional. So what may be happening (although you'd
actually have to debug to see for sure) is that -i -n treats -n as the
string to replace, instead of the default {}. But that sounds odd, and
it may be an upstream bug; I'll investigate further.
--
Eric Blake
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: Xargs positioning the arguments in a command -- is this a bug or a feature?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Eric Blake on 8/27/2005 6:08 PM:
>
> The upcoming findutils-4.2.25-1 (whenever upstream releases 4.2.25)
> better documents this. -i is being deprecated in favor of POSIX -I, which
> requires an argument, whereas the non-standard -i treated its
> argument as optional. So what may be happening (although you'd
> actually have to debug to see for sure) is that -i -n treats -n as the
> string to replace, instead of the default {}. But that sounds odd, and
> it may be an upstream bug; I'll investigate further.
Known upstream issue, still no behavior change in the upcoming 4.2.25:
http://savannah.gnu.org/bugs/?func=detailitem&item_id=13041
Also, a POSIX interpretations request was recently raised:
http://www.opengroup.org/austin/mailarchives/ag/msg08430.html
- -i implies -l (or in terms of their POSIX replacements, -I implies -L),
while -L and -n are mutually exclusive. Whichever you specify first will
be cancelled by what you specify second.
- --
Life is short - so eat dessert first!
Eric Blake [EMAIL PROTECTED]
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDEQUm84KuGfSFAYARAhNCAKCZCsrM/ivwKT5FMacSmXz2stAOoACfTFkW
LhjM9iwvdD5AkpSdVYZhMvI=
=QhWQ
-END PGP SIGNATURE-
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: Xargs positioning the arguments in a command -- is this a bug or a feature?
> [mailto:[EMAIL PROTECTED] On Behalf Of Eric Blake
> > It is an unusual command that requires switches to appear in a
> > specific order, especially when the switches are not directly
> > dependent on each other.
>
> The upcoming findutils-4.2.25-1 (whenever upstream releases
> 4.2.25) better documents this. -i is being deprecated in
> favor of POSIX -I, which requires an argument, whereas the
> non-standard -i treated its argument as optional. So what
> may be happening (although you'd actually have to debug to
> see for sure) is that -i -n treats -n as the string to
> replace, instead of the default {}. But that sounds odd, and
> it may be an upstream bug; I'll investigate further.
>
> --
> Eric Blake
Thanks, Eric. That is very cool of you to check.
FYI: I had trouble with -I, and with --string,
and even trying to specify the replacement string
using -i, although I didn't exercise those other
options as carefully as the "-i" and default {}.
--
Herb Martin
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Cygwin on CD?
Is there anyplace I can buy a *recent* copy of the full Cygwin distribution on CD? I live in the US in a place where only modem internet connections are available and Cygwin is a bit big to download that way... Thanks... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Spaces in Environment Variables
On Sat, 27 Aug 2005, Herb Martin wrote: mount -fsb "c:/Program Files" "/pgf" Agreed. A common recommendation in the Windows world is to use C:\progra~1 which is GENERALLY right but not totally reliable if either of the following is true: 1) This is a second copy of Windows installed where an older C:\Progra~1 already existed -- and so we have c:\progra~2 etc. Here's a new one to add to that: Windows XP x64 uses *two* program files directories: C:\Program Files C:\Program Files (x86) Most stuff now goes in the second (x86) directory because we don't yet have programs compiled for x64. Mike -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
script hangs with 20050716/20050826 snapshot but not with 1.5.18 dll
The following script hangs after running a short while when using
the 20050716/20050826 snapshots, but works with the 1.5.18 dll.
--- start tcsh_hang.csh ---
#!/bin/tcsh
while (1)
# perl -e 'print("12\n");' |& /usr/bin/grep -v "yy"
perl -e 'exec( "/cygdrive/c/WINNT/system32/cmd", "/c", "echo 12");' |& /usr/bin/grep
-v "yy"
date
end
--- end tcsh_hang.csh ---
Interestingly the hanging script can be cured by hitting CTRL-z and
"restarting" it with "fg" afterwards.
In case someone wonders why I should use something like this, I don't!
This is a reduced testcase from an OpenOffice build where different
other native W32 programs are exec'ed in perl and then piped through
grep.
Help is, as always, very much appreciated.
Volker
P.S.: cygcheck.log attached
--
PGP/GPG key (ID: 0x9F8A785D) available from wwwkeys.de.pgp.net
key-fingerprint 550D F17E B082 A3E9 F913 9E53 3D35 C9BA 9F8A 785D
Cygwin Configuration Diagnostics
Current System Time: Sun Aug 28 00:27:09 2005
Windows 2000 Professional Ver 5.0 Build 2195 Service Pack 4
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\WINNT\system32
c:\WINNT
c:\WINNT\System32\Wbem
c:\Programme\ATI Technologies\ATI Control Panel
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1001(q) GID: 513(none)
0(root) 513(none)544(Administratoren)
545(Benutzer)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1001(q) GID: 513(none)
0(root) 513(none)544(Administratoren)
545(Benutzer)
SysDir: C:\WINNT\system32
WinDir: C:\WINNT
USER = `q'
PWD = `/home/q'
CYGWIN = `tty'
HOME = `/home/q'
MAKE_MODE = `unix'
HOMEPATH = `\Dokumente und Einstellungen\q'
MANPATH =
`/usr/local/man:/usr/man:/usr/share/man:/usr/autotool/devel/man::/usr/ssl/man'
APPDATA = `C:\Dokumente und Einstellungen\q\Anwendungsdaten'
HOSTNAME = `lisi'
VS71COMNTOOLS = `C:\Programme\Microsoft Visual Studio .NET 2003\Common7\Tools\'
DXSDK_DIR = `C:\Programme\Microsoft DirectX 9.0 SDK (Summer 2004)\'
TERM = `xterm'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 6 Stepping 2, AuthenticAMD'
WINDIR = `C:\WINNT'
WINDOWID = `4402144'
OLDPWD = `/usr/bin'
USERDOMAIN = `LISI'
OS = `Windows_NT'
ALLUSERSPROFILE = `C:\Dokumente und Einstellungen\All Users'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
LS_COLORS =
`no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:ex=01;32:*.cmd=01;32:*.exe=01;32:*.com=01;32:*.btm=01;32:*.bat=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.gz=01;31:*.bz2=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.flac=01;35:*.mp3=01;35:*.mpc=01;35:*.ogg=01;35:*.wav=01;35:'
TEMP = `/cygdrive/c/DOKUME~1/q/LOKALE~1/Temp'
COMMONPROGRAMFILES = `C:\Programme\Gemeinsame Dateien'
LIB = `C:\Programme\Microsoft Visual Studio .NET 2003\SDK\v1.1\Lib\'
USERNAME = `q'
PROCESSOR_LEVEL = `6'
FTP_PASSIVE = `1'
SYSTEMDRIVE = `C:'
EDITOR = `nano -w'
USERPROFILE = `C:\Dokumente und Einstellungen\q'
PS1 = `\[\033]0;[EMAIL PROTECTED] - \w\007
[EMAIL PROTECTED] \[\033[33m\w\033[0m\]
$ '
LOGONSERVER = `\\LISI'
PROCESSOR_ARCHITECTURE = `x86'
SHLVL = `1'
COLORFGBG = `0;default;15'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = `C:'
COMSPEC = `C:\WINNT\system32\cmd.exe'
TMP = `/cygdrive/c/DOKUME~1/q/LOKALE~1/Temp'
SYSTEMROOT = `C:\WINNT'
PRINTER = `\\Boxy2\Canon i560'
CVS_RSH = `/bin/ssh'
PROCESSOR_REVISION = `0602'
INFOPATH =
`/usr/local/info:/usr/info:/usr/share/info:/usr/autotool/devel/info:/usr/autotool/stable/info:'
PROGRAMFILES = `C:\Programme'
DISPLAY = `:0'
NUMBER_OF_PROCESSORS = `1'
INCLUDE = `C:\Programme\Microsoft Visual Studio .NET 2003\SDK\v1.1\include\'
COMPUTERNAME = `LISI'
COLORTERM = `rxvt-xpm'
_ = `/usr/bin/cygcheck'
POSIXLY_CORRECT = `1'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = `C:\cygwin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = `C:\cygwin/bin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
(default) = `C:\cygwin/lib'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
