From: John Wiersba <John.Wiersba@medstat.com>
To: "'cygwin@sourceware.cygnus.com'" <cygwin@sourceware.cygnus.com>
Subject: question (latest "stable" dll?) + bugs: vim, bash, gcc, cp, find, less, zip, ls
Date: Mon, 21 Jun 1999 15:40:00 -0000 [thread overview]
Message-ID: <03F4742D8225D21191EF00805FE62B990205E15F@AA-MSG-01> (raw)
Question:
Is there a later "stable" release than 19990115? I installed
cygwin-inst-19990115.tar.gz (which actually has a date of 1/16/99), but
there are a few significant bugs (see below) that I'd like to get fixes to
if possible. I tried downloading a recent cygwin1.dll, but it was obviously
not meant for general consumption since it dumped some sort of trace to the
screen when it ran.
--------------------
Bugs reports.
I'm submitting all these in one lump, since I don't want to fill up the
mailing list with too much mail. I realize that it will make the subject
line less useful to bunch these up.
1) Running programs using relative paths is screwed up. I've seen mention
of this bug in the archives, so I know it's not new. Is there a more recent
"stable" cygwin1.dll which fixes this?
2) Every once in a while one or more of my terminals gets into a mode where
I can't cntl-c out of (any?) program run from that terminal. I just have to
let the program finish. This can be quite annoying if I was running
something like find /. The general fix seems to be to unload cygwin1.dll by
exiting all bash sessions, which is obviously less than optimal.
3) The following two commands cause bash to hang for several seconds before
executing properly. I believe that bash is, for some reason, going out to
the LAN before figuring out what to do. Could it be related to bug #1?
cd /
cd relativepath/subdir
Other symptoms: after experiencing this bug, an immediate retry of these
two commands will usually work speedily (which is why I believe that it is
related to something cached on the network), but waiting a little longer
causes a replay of the original several-second hang.
4) find is broken across mounts. find clearly can see the files/dirs under
the mount, but then for some reason, reports "No such file or directory".
See the bottom of this email for my cygcheck outout.
$ find /
/
/a
/a/a
find: /a/a/new.zip: No such file or directory
/bin
/c
find: /c/UNATTEND.TXT: No such file or directory
find: /c/BOOTSECT.DOS: No such file or directory
find: /c/WINNT: No such file or directory
find: /c/NTDETECT.COM: No such file or directory
find: /c/ntldr: No such file or directory
...
/etc
/etc/group
/etc/hosts
...
5) vim 5.3 is badly broken using TERM=linux. After starting it, if I hit
backspace once or twice quickly, it hangs in an infinite loop. Sending it a
signal from another shell prompt causes it to report:
Vim: Caught deadly signal TERM
Vim: Finished.
after which the shell is hosed (because vim didn't reset it when it exited).
Trying TERM=ansi works ok except that the function keys aren't defined.
TERM=xterm works for function keys 5-8, but not 1-4. I eventually made my
own terminal definition based on xterm which properly defines function keys
1-4, too. Could it be that I'm the only one using vim which has this
problem (I didn't see it in the archives)?
6) I can't get less to take into account that wrapped lines take up multiple
screen lines. This has the annoying side effect of scrolling the top few
lines off the screen. The only workaround I've found is to use fold -w79 |
less.
7) The version of gcc released in full.exe creates huge executables which
need to be stripped to come down to a reasonable size. The 1/15/99 gcc
fixes this (but not everyone will take the 1/15 release.
8) gcc doesn't use a very accomodating algorithm to find cpp. It appears
that if you do any rearranging of the originally installed directories, gcc
gets totally lost and requires that GCC_EXEC_PREFIX be defined. It would be
nice for gcc to try a few other likely places before giving up. For
example, gcc might try ../lib/gcc-lib relative to the directory where gcc is
found. Also, I couldn't find any documentation about what value to use for
GCC_EXEC_PREFIX. It's not obvious that it should be set to cpp's parent's
parent's directory.
9) bash's internal "set" command doesn't appear to be interruptable with
cntl-c.
10) zip (built according to the directions at ftp.franken.de) fails when
redirecting output to a UNC path, e.g.
zip -r - . >//h/mystuff.zip
reporting:
zip error: Internal logic error (incorrect compressed size)
11) cp -p has an annoying behavior of (often, for me anyway) reporting a
permission problem when it fails to successfully chown the copied files. In
fact, the files do get set to the proper owner. I had to fix this by
commenting out the error handling starting at lines 983-986 of cp.c so that
if a chown error occurs, it's ignored. I think that silently ignoring such
errors when called with the -p option is a more proper behavior, because
there doesn't seem to be a good reason to squawk when the file has been
successfully copied and it's only the file ownership which can't be set
correctly.
12) Under cygwin 19, "ls -lF /" didn't need to hit my floppy drive, even
though a: was mounted as /a. But under cygwin 20 it does, forcing me to use
something less intuitive than /a (so that whenever I don't have to wait
while the floppy disk grinds whenever I get a listing of /).
Output of cygcheck -s -r -v:
Cygnus Win95/NT Configuration Diagnostics
Current System Time: Mon Jun 21 18:05:14 1999
WinNT Ver 4.0 build 1381 Service Pack 4
Path: /jrw/jrw/mdst/sh
/jrw/binu
/opt/cygwin/local/bin
/opt/cygwin/bin
/opt/cygwin/bin
/jrw/binw
/winnt/system32
/winnt
.
SysDir: C:\WINNT\System32
WinDir: C:\WINNT
CYGWIN = ` notitle tty nostrip_title binmode glob'
GCC_EXEC_PREFIX = `/opt/cygwin/lib/gcc-lib/'
HOME = `/jrw'
MAKE_MODE = `UNIX'
PWD = `/jrw/jrw/mdst/mab'
...<snip>...
CDPATH = `.:..:/jrw'
COLUMNS = `80'
LINES = `67'
...<snip>...
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
(default) = `C:'
unix = `/c'
fbinary = 0x00000001
fsilent = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
(default) = `A:'
unix = `/a/a'
fbinary = 0x00000001
fsilent = 0x00000001
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
(default) = `D:'
unix = `/'
fbinary = 0x00000001
fsilent = 0x00000001
HKEY_CURRENT_USER\Software\FTP Explorer\Profiles\cygnus
(default) = `sourceware.cygnus.com'
Login = `anonymous'
InitialPath = `/pub/cygwin'
AnonLogin = 0x00000001
CacheData = 0x00000000
Description = `'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20\B20.1
...<snip>...
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\GNUPro\i586-cygwin32\i586-cygwin32\cygwin-B20.1
(default) = `d:\opt\cygwin\cygwin-b20'
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Cygnu
s Cygwin B20
(default) = `C:\WINNT\IsUninst.exe -fd:\opt\cygwin\cygwin-b20\Uninst.isu'
DisplayName = `Cygwin B20'
a:\ fd FAT 1Mb 39% CP UN
c:\ hd FAT 2044Mb 29% CP UN
d:\ hd NTFS 4104Mb 26% CP CS UN PA FC
e:\ cd N/A N/A
f:\ net NWFS 900Mb 39% CP SYS
...<snip>...
D: / native text=binary
A: /a/a native text=binary
C: /c native text=binary
Found: D:\opt\cygwin\bin\bash.exe
Found: D:\opt\cygwin\bin\cat.exe
Not Found: cpp (good!)
Found: D:\opt\cygwin\bin\find.exe
Found: D:\opt\cygwin\bin\gcc.exe
Found: D:\opt\cygwin\bin\gdb.exe
Found: D:\opt\cygwin\bin\ld.exe
Found: D:\opt\cygwin\bin\ls.exe
Found: D:\opt\cygwin\bin\make.exe
Found: D:\opt\cygwin\bin\sh.exe
371k 1998/12/01 D:\opt\cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
"cygtcl80.dll" v0.0 ts=1998/12/1 3:25
5k 1998/12/01 D:\opt\cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
10k 1998/12/01 D:\opt\cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
"cygtclreg80.dll" v0.0 ts=1998/12/1 3:25
600k 1998/12/01 D:\opt\cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
"cygtk80.dll" v0.0 ts=1998/12/1 3:28
446k 1998/12/04 D:\opt\cygwin\bin\cygwin1-old.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=1998/12/3 23:39
451k 1999/06/15 D:\opt\cygwin\bin\cygwin1-recommended.dll - os=4.0 img=1.0
sys=4.0
"cygwin1.dll" v0.0 ts=1999/1/16 0:09
451k 1999/01/16 D:\opt\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=1999/1/16 0:09
Anyway, even with these problems, cygwin is a life-saver for someone having
to work in a windows environment. It's amazing that it's so usable! Thanks
guys!
John Wiersba (john.wiersba@medstat.com)
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
WARNING: multiple messages have this Message-ID
From: John Wiersba <John.Wiersba@medstat.com>
To: "'cygwin@sourceware.cygnus.com'" <cygwin@sourceware.cygnus.com>
Subject: question (latest "stable" dll?) + bugs: vim, bash, gcc, cp, find, less, zip, ls
Date: Wed, 30 Jun 1999 22:10:00 -0000 [thread overview]
Message-ID: <03F4742D8225D21191EF00805FE62B990205E15F@AA-MSG-01> (raw)
Message-ID: <19990630221000.14FTfCmtoQoqbk_gTFC3wdVjrudtAf_9_Tx2MWFLjo4@z> (raw)
Question:
Is there a later "stable" release than 19990115? I installed
cygwin-inst-19990115.tar.gz (which actually has a date of 1/16/99), but
there are a few significant bugs (see below) that I'd like to get fixes to
if possible. I tried downloading a recent cygwin1.dll, but it was obviously
not meant for general consumption since it dumped some sort of trace to the
screen when it ran.
--------------------
Bugs reports.
I'm submitting all these in one lump, since I don't want to fill up the
mailing list with too much mail. I realize that it will make the subject
line less useful to bunch these up.
1) Running programs using relative paths is screwed up. I've seen mention
of this bug in the archives, so I know it's not new. Is there a more recent
"stable" cygwin1.dll which fixes this?
2) Every once in a while one or more of my terminals gets into a mode where
I can't cntl-c out of (any?) program run from that terminal. I just have to
let the program finish. This can be quite annoying if I was running
something like find /. The general fix seems to be to unload cygwin1.dll by
exiting all bash sessions, which is obviously less than optimal.
3) The following two commands cause bash to hang for several seconds before
executing properly. I believe that bash is, for some reason, going out to
the LAN before figuring out what to do. Could it be related to bug #1?
cd /
cd relativepath/subdir
Other symptoms: after experiencing this bug, an immediate retry of these
two commands will usually work speedily (which is why I believe that it is
related to something cached on the network), but waiting a little longer
causes a replay of the original several-second hang.
4) find is broken across mounts. find clearly can see the files/dirs under
the mount, but then for some reason, reports "No such file or directory".
See the bottom of this email for my cygcheck outout.
$ find /
/
/a
/a/a
find: /a/a/new.zip: No such file or directory
/bin
/c
find: /c/UNATTEND.TXT: No such file or directory
find: /c/BOOTSECT.DOS: No such file or directory
find: /c/WINNT: No such file or directory
find: /c/NTDETECT.COM: No such file or directory
find: /c/ntldr: No such file or directory
...
/etc
/etc/group
/etc/hosts
...
5) vim 5.3 is badly broken using TERM=linux. After starting it, if I hit
backspace once or twice quickly, it hangs in an infinite loop. Sending it a
signal from another shell prompt causes it to report:
Vim: Caught deadly signal TERM
Vim: Finished.
after which the shell is hosed (because vim didn't reset it when it exited).
Trying TERM=ansi works ok except that the function keys aren't defined.
TERM=xterm works for function keys 5-8, but not 1-4. I eventually made my
own terminal definition based on xterm which properly defines function keys
1-4, too. Could it be that I'm the only one using vim which has this
problem (I didn't see it in the archives)?
6) I can't get less to take into account that wrapped lines take up multiple
screen lines. This has the annoying side effect of scrolling the top few
lines off the screen. The only workaround I've found is to use fold -w79 |
less.
7) The version of gcc released in full.exe creates huge executables which
need to be stripped to come down to a reasonable size. The 1/15/99 gcc
fixes this (but not everyone will take the 1/15 release.
8) gcc doesn't use a very accomodating algorithm to find cpp. It appears
that if you do any rearranging of the originally installed directories, gcc
gets totally lost and requires that GCC_EXEC_PREFIX be defined. It would be
nice for gcc to try a few other likely places before giving up. For
example, gcc might try ../lib/gcc-lib relative to the directory where gcc is
found. Also, I couldn't find any documentation about what value to use for
GCC_EXEC_PREFIX. It's not obvious that it should be set to cpp's parent's
parent's directory.
9) bash's internal "set" command doesn't appear to be interruptable with
cntl-c.
10) zip (built according to the directions at ftp.franken.de) fails when
redirecting output to a UNC path, e.g.
zip -r - . >//h/mystuff.zip
reporting:
zip error: Internal logic error (incorrect compressed size)
11) cp -p has an annoying behavior of (often, for me anyway) reporting a
permission problem when it fails to successfully chown the copied files. In
fact, the files do get set to the proper owner. I had to fix this by
commenting out the error handling starting at lines 983-986 of cp.c so that
if a chown error occurs, it's ignored. I think that silently ignoring such
errors when called with the -p option is a more proper behavior, because
there doesn't seem to be a good reason to squawk when the file has been
successfully copied and it's only the file ownership which can't be set
correctly.
12) Under cygwin 19, "ls -lF /" didn't need to hit my floppy drive, even
though a: was mounted as /a. But under cygwin 20 it does, forcing me to use
something less intuitive than /a (so that whenever I don't have to wait
while the floppy disk grinds whenever I get a listing of /).
Output of cygcheck -s -r -v:
Cygnus Win95/NT Configuration Diagnostics
Current System Time: Mon Jun 21 18:05:14 1999
WinNT Ver 4.0 build 1381 Service Pack 4
Path: /jrw/jrw/mdst/sh
/jrw/binu
/opt/cygwin/local/bin
/opt/cygwin/bin
/opt/cygwin/bin
/jrw/binw
/winnt/system32
/winnt
.
SysDir: C:\WINNT\System32
WinDir: C:\WINNT
CYGWIN = ` notitle tty nostrip_title binmode glob'
GCC_EXEC_PREFIX = `/opt/cygwin/lib/gcc-lib/'
HOME = `/jrw'
MAKE_MODE = `UNIX'
PWD = `/jrw/jrw/mdst/mab'
...<snip>...
CDPATH = `.:..:/jrw'
COLUMNS = `80'
LINES = `67'
...<snip>...
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\00
(default) = `C:'
unix = `/c'
fbinary = 0x00000001
fsilent = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\01
(default) = `A:'
unix = `/a/a'
fbinary = 0x00000001
fsilent = 0x00000001
HKEY_CURRENT_USER\Software\Cygnus Solutions\CYGWIN.DLL setup\b15.0\mounts\02
(default) = `D:'
unix = `/'
fbinary = 0x00000001
fsilent = 0x00000001
HKEY_CURRENT_USER\Software\FTP Explorer\Profiles\cygnus
(default) = `sourceware.cygnus.com'
Login = `anonymous'
InitialPath = `/pub/cygwin'
AnonLogin = 0x00000001
CacheData = 0x00000000
Description = `'
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin B20\B20.1
...<snip>...
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus
Solutions\GNUPro\i586-cygwin32\i586-cygwin32\cygwin-B20.1
(default) = `d:\opt\cygwin\cygwin-b20'
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\Cygnu
s Cygwin B20
(default) = `C:\WINNT\IsUninst.exe -fd:\opt\cygwin\cygwin-b20\Uninst.isu'
DisplayName = `Cygwin B20'
a:\ fd FAT 1Mb 39% CP UN
c:\ hd FAT 2044Mb 29% CP UN
d:\ hd NTFS 4104Mb 26% CP CS UN PA FC
e:\ cd N/A N/A
f:\ net NWFS 900Mb 39% CP SYS
...<snip>...
D: / native text=binary
A: /a/a native text=binary
C: /c native text=binary
Found: D:\opt\cygwin\bin\bash.exe
Found: D:\opt\cygwin\bin\cat.exe
Not Found: cpp (good!)
Found: D:\opt\cygwin\bin\find.exe
Found: D:\opt\cygwin\bin\gcc.exe
Found: D:\opt\cygwin\bin\gdb.exe
Found: D:\opt\cygwin\bin\ld.exe
Found: D:\opt\cygwin\bin\ls.exe
Found: D:\opt\cygwin\bin\make.exe
Found: D:\opt\cygwin\bin\sh.exe
371k 1998/12/01 D:\opt\cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
"cygtcl80.dll" v0.0 ts=1998/12/1 3:25
5k 1998/12/01 D:\opt\cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
10k 1998/12/01 D:\opt\cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
"cygtclreg80.dll" v0.0 ts=1998/12/1 3:25
600k 1998/12/01 D:\opt\cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
"cygtk80.dll" v0.0 ts=1998/12/1 3:28
446k 1998/12/04 D:\opt\cygwin\bin\cygwin1-old.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=1998/12/3 23:39
451k 1999/06/15 D:\opt\cygwin\bin\cygwin1-recommended.dll - os=4.0 img=1.0
sys=4.0
"cygwin1.dll" v0.0 ts=1999/1/16 0:09
451k 1999/01/16 D:\opt\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
"cygwin1.dll" v0.0 ts=1999/1/16 0:09
Anyway, even with these problems, cygwin is a life-saver for someone having
to work in a windows environment. It's amazing that it's so usable! Thanks
guys!
John Wiersba (john.wiersba@medstat.com)
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com
next reply other threads:[~1999-06-21 15:40 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-06-21 15:40 John Wiersba [this message]
1999-06-30 22:10 ` John Wiersba
1999-06-21 15:59 Phil Edwards
1999-06-21 16:32 ` Brendan Simon
1999-06-30 22:10 ` Brendan Simon
1999-06-22 11:00 ` itz
1999-06-30 22:10 ` itz
1999-06-30 22:10 ` Phil Edwards
1999-06-22 11:57 John Wiersba
1999-06-22 13:41 ` Christopher Faylor
1999-06-30 22:10 ` Christopher Faylor
1999-06-30 22:10 ` John Wiersba
1999-06-22 12:09 Lincoln, W. Terry
1999-06-30 22:10 ` Lincoln, W. Terry
1999-06-22 13:57 John Wiersba
1999-06-22 14:07 ` DJ Delorie
1999-06-30 22:10 ` DJ Delorie
1999-06-30 22:10 ` John Wiersba
1999-06-23 6:19 Lincoln, W. Terry
1999-06-30 22:10 ` Lincoln, W. Terry
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=03F4742D8225D21191EF00805FE62B990205E15F@AA-MSG-01 \
--to=john.wiersba@medstat.com \
--cc=cygwin@sourceware.cygnus.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).