~^Z hangs ssh
Hello, I'm finding that ~^Z hangs the cygwin session rather than suspending my connection. I'm using cygwin to ssh into a solaris box. I've confirmed that suspension works properly when using ssh from sun box to sun box. Can't find any mention of this problem in the mailing list or Google. Does anyone else have this problem, or a fix? Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- 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: ~^Z hangs ssh
Larry Hall wrote: > > Shing-Fat Fred Ma wrote: > > > Hello, > > > > I'm finding that ~^Z hangs the cygwin session > > rather than suspending my connection. I'm using > > cygwin to ssh into a solaris box. I've confirmed > > that suspension works properly when using ssh from > > sun box to sun box. Can't find any mention of this > > problem in the mailing list or Google. Does anyone > > else have this problem, or a fix? > > > Sorry, I don't have a Sun box to ssh into but it works fine > going from Cygwin (W2K) to Cygwin (W2K) (different boxes though). > Perhaps you want to try "round-tripping" to Cygwin on the same box > or different ones and see how that works for you. Hmm, it works fine for me too. At my current location, I only have a single PC running cygwin and sshd, so I ssh'd myself. ~^Z works fine. It also works fine if I ssh to cygwin from a sunbox. The solaris version is OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090602f The Cygwin version is OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090702f Anyway, thanks for checking into it. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- 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/
gnu tar opens tgz's with file times in the future
Hello, I'm gnu-tarring files with tar version 1.13.25 on solaris, then untarring with the same version on cygwin. The files are dated 2002-12-31 18:09:xx in the tgz on solaris. When I sftp them to cygwin, the tar programs shows the files to be dated 2003-01-01 03:09.xx. But typing "date" at the cygwin prompt shows the computer clock to be right i.e. Tue Dec. 31 2002. Cygcheck gives: cygutils1.1.3-1 cygwin 1.3.17-1 I'm using Win2K with SP3. Thanks for any pointers. -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
SOLVED: gnu tar opens tgz's with file times in the future
Shing-Fat Fred Ma wrote: Hello, I'm gnu-tarring files with tar version 1.13.25 on solaris, then untarring with the same version on cygwin. The files are dated 2002-12-31 18:09:xx in the tgz on solaris. When I sftp them to cygwin, the tar programs shows the files to be dated 2003-01-01 03:09.xx. But typing "date" at the cygwin prompt shows the computer clock to be right i.e. Tue Dec. 31 2002. It was the time zone not set right on the PC. Didn't know gnu tar was made to compensate for time zones.. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: less 378 still not anchoring to \
Max Bowsher wrote: > f wrote: > > I just reinstalled "less" from the cygwin site. > > It still doesn't seem to anchor to word boundaries > > using regex(3) rules i.e. \ doesn't > > match anything, as does . I read > > a posting suggesing a solution by using perl > > syntax (apparently): > > > > /\bSomeWord\b > > > > That works, but is there a known reason why > > the regex notation doesn't work? > > Because less is linked with pcre(3), not regex(3). > > Max. Thanks, Max. The posting I saw did indeed mention linking Perl, but I thought that meant added features rather than different syntax. It looks like I better accelerate my picking up of Perl. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question re. export environment variable
Igor Pechtchanski wrote: > On Thu, 20 Feb 2003, Fred Ma wrote: > > > Hello, > > > > I'm using cygwin bash 2.05b-8 (it's actually gnu). > > I thought that $HOSTNAME was an environment > > variable. When I run gnu make (I'm pretty > > sure this is not a make problem), $(HOSTNAME) > > is empty. It gets fixed if I do "export HOSTNAME" > > before running make. > > > > Is there a way to check if the export command > > has been applied to $HOSTNAME? Does the > > actual transcription of $HOSTNAME's value to > > the environment happen only once, when > > "export" is applied, or is there a continual > > monitoring an mirroring of changes to $HOSTNAME > > forever after applying "export"? > > > > Fred > > Fred, > > I'm afraid you might be confused about what "exporting" a variable means. > Bash maintains an "environment", which contains the values of all the > variables it's using. When bash spawns a child, that child inherits those > variables from the parent's environment that are "exported". Thus, if you > export HOSTNAME, the child will get the current value of HOSTNAME. If you > then change HOSTNAME in the parent, the child *will not* see the change. > However, if you spawn another child, that new child *will* see the new > value. > > BTW, "export" with no variable name will print out the list of all > variables that are exported from the current shell. And, if you want to > make sure it's exported, "export HOSTNAME" can do no harm. But both this > and the above are off-topic for the Cygwin list, and could have been found > by a simple perusal of "man bash". > Igor > -- >http://cs.nyu.edu/~pechtcha/ > |\ _,,,---,,_[EMAIL PROTECTED] > ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] > |,4- ) )-,_. ,\ ( `'-' Igor Pechtchanski > '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! > > Oh, boy, virtual memory! Now I'm gonna make myself a really *big* RAMdisk! > -- /usr/games/fortune Igor, Thanks for the information. The "man bash" confirms what you said, and what I thought I knew before encountering the problem. What made me uncertain was that things don't always behave the same in the cygwin environment as they do in, say, solaris, and I'm never sure what behaviour might be due to customizations. Another thing that made me unsure was that it seems strange for $HOSTNAME not to be marked export by default, I didn't think that would happen intentionally. Though it appears now that it is that way. I did miss the bit in the man pages about showing all the export variables. My apologies, I should have spent more time reading it more carefully. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Question re. export environment variable
Thanks, Bob. That's the way I expected it to work. I was just unsure of whether there was something cygwin-specific, as it seems strange that something like HOSTNAME is not marked for export at the time that it is set. I'll stick it into ~/.bashrc. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 Bob McGowan wrote: > Fred, perhaps this will help: > > echo $TEST # Test has no value, hence the blank line. > > $ TEST=noexport # Set but not exported > $ echo $TEST > noexport > $ env|grep TEST # Nothing found, no output. > $ export TEST # Export it. > $ env|grep TEST # And now it's found in the environment. > TEST=noexport > $ TEST=second # Change its value. > $ env|grep TEST # Same search as above, but the value is changed. > TEST=second > > Perhaps the easiest way to look at it is to think of exporting as making a type > of global variable. Everyone (within certain limits; for the shell, only its > children...) will see the exported variable. If the value changes, it changes > "everywhere". I've quoted everywhere because this only applies to children > invoked after the change. So if TEST=second and you run an xterm, the new shell > sees TEST=second. Change TEST=third in the first shell, you still have > TEST=second in the second shell, since it already got its value for TEST. Start > a third shell from the first, it will see TEST=third. And so on. > > Fred Ma wrote: > > Hello, > > > > I'm using cygwin bash 2.05b-8 (it's actually gnu). > > I thought that $HOSTNAME was an environment > > variable. When I run gnu make (I'm pretty > > sure this is not a make problem), $(HOSTNAME) > > is empty. It gets fixed if I do "export HOSTNAME" > > before running make. > > > > Is there a way to check if the export command > > has been applied to $HOSTNAME? Does the > > actual transcription of $HOSTNAME's value to > > the environment happen only once, when > > "export" is applied, or is there a continual > > monitoring an mirroring of changes to $HOSTNAME > > forever after applying "export"? > > -- > Bob McGowan > Staff Development Engineer > VERITAS Software > [EMAIL PROTECTED] -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: "tee" is coredumping
Igor Pechtchanski wrote: > On Thu, 20 Feb 2003, Fred Ma wrote: > > > Hello, > > > > I've got the latest cygwin 1.3.20-1, cygutils 1.1.3-1. > > The "tee" command is core dumping on me, but > > only with a particular set of circumstances. I use > > it as follows: > > > > make -f client.mak 2>&1 | tee client.out > > > > I realize this is not telling you a whole lot because > > it depends on what all happens in client.mak. I don't > > get a core dump if I just do "ls 2>&1 | tee client.out". > > Here is the short contents of client.mak: > > > > CC = gfilt > > > > $(warning Hostname is $(HOSTNAME)) > > ifeq ($(HOSTNAME),fmalap) > > $(warning Disabling Matlab engine code.) > > NOML = -DNOML > > LIBS = > > else > > NOML = > > LIBS = -L /opt/matlab13/extern/lib/sol2 -leng -lmx > > endif > > > > client: client.cpp client.hpp client.mak > > $(CC) $(NOML) -O -o client \ > > -I/opt/matlab13/extern/include \ > > client.cpp \ > > $(LIBS) > > > > The key in this file that seems to cause the crash is > > using CC=gfilt instead of g++. "gfilt" is a perl script > > (or rather, a shell script that invokes perl) to decrypt > > the very confusing messages from the C++ standard > > library. > > > > I realize it's not realistic to ask "What's wrong", but > > perhaps a few strategies to isolate the problem? I > > am no perl guy (I've used twice, like an overpowered > > sed script). The perl version is 5.6.1-2, with gnu license. > > But perl is probably not the problem, since it's tee that's > > dumping. > > > > Thanks in advance. > > > > Fred > > "man addr2line". "cd /bin && cygcheck tee.exe". This should get you > started. > Igor > -- > http://cs.nyu.edu/~pechtcha/ > |\ _,,,---,,_[EMAIL PROTECTED] > ZZZzz /,`.-'`'-. ;-;;,_[EMAIL PROTECTED] Thanks again, Igor. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Two ssh connections slow
Hello, I'm using TightVNC1.2.2 to connect to Solaris8 from WinMe. I'm using OpenSSH_3.4p1, SSH protocols 1.5/2.0, OpenSSL 0x0090607f to open the connection. This ssh came with cygwin-1.3.12-4, which I just upgraded to. Prior to this, I was running OpenSSH_2.3.0p1, protocol versions 1.5/2.0. I don't remember what the cygwin version was prior to the upgrade. I'm finding that when I have two VNC sessions open via two ssh channels to two different sun boxes, each session slows to an unusable speed. Most of the time, the response freezes before too long and the connection is dropped (both ssh and VNC). Strangely, it is always the same machine that drops the line, but thereafter, the remaining line speeds up to a usable speed. I don't recall two connections being a problem before the upgrade, though I can't positively say it is "correlated" with upgrading. At first, I thought it was the free ZoneAlarm firewall, but the same behaviour is observed without the firewall. Just wondering if anyone else has experienced similar kind of situation-specific slowdowns with ssh on the new cygwin installation. Fred --- Fred Ma Department of Electronics Carleton University, Mackenzie Building 1125 Colonel By Drive Ottawa, Ontario Canada K1S 5B6 [EMAIL PROTECTED] === -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
gvimdiff fails on network drive
Hello,
I'm using cygwin-1.3.12-4 on WinME. I'm
using gvim 6.0 to diff a pair of files residing
on a mounted network drive i.e. /SomeUser
is a mount pointing to \\RemoteSunBox\SomeUser.
Read/write access to /SomeUser is no problem.
Using "gvim -d" on localfiles is no problem.
But using "gvim -d" on files residing on /SomeUser
generates the error E97 (can't create diff files).
I thought it might be a path name problem,
though both invocations would use unix
style path names. But just to see, I tried
putting this in _vimrc (courtesy Machitani-san):
> if has("unix")
> set shell=/bin/bash
> elseif has("win32")
> " set shell=c:/cygwin/bin/bash
> set shell=c:\\cygwin\\bin\\bash.exe
> set shellcmdflag=-c
> set shellpipe=2>&1\|\ tee
> set shellslash
> endif
But the problem persisted. Just as a note,
my gvim is invoked by the bash function
{
( unset SHELL;
/c/Program\ Files/vim/vim60/gvim $* ) &
}
because gvim's diff *never* worked prior
to the "unset SHELL".
Thanks for any suggestions.
Fred
---
Fred Ma
Department of Electronics
Carleton University, Mackenzie Building
1125 Colonel By Drive
Ottawa, Ontario
Canada K1S 5B6
[EMAIL PROTECTED]
===
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: gvimdiff fails on network drive
Vince Hoffman wrote:
> Gvim isnt linked to cygwin1.dll so it wont see cygwin mount points.
Vince,
I understand your explanation, and it sounds
like it is the cause. But why am I able to open
the two files, but not diff them? When I use
"gvim -dR", the two files open but just don't
diff. (I first cd to the remote directory via
the mount point).
Fred
---
Fred Ma
Department of Electronics
Carleton University, Mackenzie Building
1125 Colonel By Drive
Ottawa, Ontario
Canada K1S 5B6
[EMAIL PROTECTED]
===
> > -Original Message-----
> > From: Shing-Fat Fred Ma [mailto:fma@;doe.carleton.ca]
> > Sent: 25 October 2002 19:25
> > To: [EMAIL PROTECTED]
> > Subject: gvimdiff fails on network drive
> >
> >
> > Hello,
> >
> > I'm using cygwin-1.3.12-4 on WinME. I'm
> > using gvim 6.0 to diff a pair of files residing
> > on a mounted network drive i.e. /SomeUser
> > is a mount pointing to \\RemoteSunBox\SomeUser.
> > Read/write access to /SomeUser is no problem.
> > Using "gvim -d" on localfiles is no problem.
> > But using "gvim -d" on files residing on /SomeUser
> > generates the error E97 (can't create diff files).
> >
> > I thought it might be a path name problem,
> > though both invocations would use unix
> > style path names. But just to see, I tried
> > putting this in _vimrc (courtesy Machitani-san):
> >
> > > if has("unix")
> > > set shell=/bin/bash
> > > elseif has("win32")
> > > " set shell=c:/cygwin/bin/bash
> > > set shell=c:\\cygwin\\bin\\bash.exe
> > > set shellcmdflag=-c
> > > set shellpipe=2>&1\|\ tee
> > > set shellslash
> > > endif
> >
> > But the problem persisted. Just as a note,
> > my gvim is invoked by the bash function
> >
> > {
> > ( unset SHELL;
> > /c/Program\ Files/vim/vim60/gvim $* ) &
> > }
> >
> > because gvim's diff *never* worked prior
> > to the "unset SHELL".
> >
> > Thanks for any suggestions.
> >
> > Fred
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
ftp put; less search; directory timestamp
Hello, I recently upgraded to cygwin-1.3.12-4 on WinME. Recently I noticed that ftp (Gnu inetutils) 1.3.2 hangs when "put"-ing a file (the entire file seems to be transferred though). Don't recall having this problem before. I'm connecting to my university via sympatico dialup. Also, when I use "less", I can't seem to indicate that I want to search for an entire word e.g. regexp is \ But this ends up finding nothing. I don't seem to recall this before either. I even tried less on solaris 8, and it recognizes whole words. Another thing I notice is that the timestamp (used by "ls -t" to sort) isn't necessarily updated for a directory if new files are ftp'd into the directory. This doesn't match the behaviour of solaris 8 (not that it should, but isn't the solaris 8 behaviour pretty sane?) Thanks for any suggestions, or even acknowledgements of the problem so that I know it's not just my installation. Fred --- Fred Ma Department of Electronics Carleton University, Mackenzie Building 1125 Colonel By Drive Ottawa, Ontario Canada K1S 5B6 [EMAIL PROTECTED] [EMAIL PROTECTED] === -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
No such file, but it's right there
Hi, I'm using cygwin 1.3.15 in WinME: Cygwin DLL version info: DLL version: 1.3.15 DLL epoch: 19 When I try to "ls" a file I know to be there, I'm told it isn't: $ which ftp telnet /usr/bin/ftp /usr/bin/telnet $ cd /usr/bin $ ls -l ftp telnet -rwxr-xr-x 1 unknown unknown 57344 Jan 6 2002 ftp* -rwxr-xr-x 1 unknown unknown 79360 Jan 6 2002 telnet* $ less ftp telnet ftp: No such file or directory telnet: No such file or directory I don't really want to less a binary file, just see whether the file's presence is recognized. I wouldn't think it's a mount problem, but here's the mount information: $ mount C:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type system (binmode) C:\cygwin\bin on /usr/bin type system (binmode) C:\cygwin\lib on /usr/lib type system (binmode) C:\cygwin on / type system (binmode) c: on /c type user (textmode) d: on /d type user (textmode) Thanks if you have any suggestions. Fred -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
No such file, but it's right there
>Well the files are, of course, ftp.exe and telnet.exe.
>Cygwin's automagical .exe workarounds seems to not be working when going
>through a mount where there is no underlying directory.
>
>Max.
>
> Cygwin follows the Windows convention of using file file name suffix
> ".exe" for its binary executable files. While Cygwin will locate and
> execute files files given only the base name (sans suffix), other uses
> ("cat," "less," or more apropos "nm," "size" or "file") demand the
> full file name, including the ".exe" suffix.
>
> Randall Schulz
> Mountain View, CA USA
Thanks.
Fred
--
Fred Ma, [EMAIL PROTECTED]
Carleton University, Dept. of Electronics
1125 Colonel By Drive, Ottawa, Ontario
Canada, K1S 5B6
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
dos2unix/d2u does nothing
Cygwin DLL version info: DLL version: 1.3.15 DLL epoch: 19 Hello, I'm finding that dos2unix and d2u doesn't change a file in-place, even with -U (the timestamp doesn't even change). It works find for stdin-to-stdout, though. Just thought I'd share my feelings on that (that is, I feel it doesn't work in-place, but thank goodness it works). Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: dos2unix/d2u does nothing
> > Subject: > RE: dos2unix/d2u does nothing > From: > David Kilroy <[EMAIL PROTECTED]> > Date: > Mon, 25 Nov 2002 13:33:42 - > To: > [EMAIL PROTECTED] > > >I have seen similar behaviour to what Fred sees, but I can't remember if >that was u2d or d2u. In that case the files had mixed use of \n and \r\n >line endings. I presumed d2u/u2d detected a single \n (or \r\n) in the first >X bytes, and assumed the file was already in the appropriate format. > >I 'fixed' this by running u2d then d2u (or vice versa). > >Dave. > > > >>-Original Message- >>From: Randall R Schulz [mailto:[EMAIL PROTECTED]] >>Sent: 23 November 2002 05:12 >>To: [EMAIL PROTECTED] >>Subject: Re: dos2unix/d2u does nothing >> >> >>Fred, >> >>It works OK for me. You may be experiencing an interaction >>with a text mode >>mount (though from the looks of it, "conv.c" was ported for >>cygwin to open >>files in binary mode, so this shouldn't happen). >> >>As to the mod time, perhaps you wrote the file and then >>converted it within >>the same minute, so "ls -l" doesn't show a change in the >>modification time >>(even though the difference is there at the finer time >>resolution that the >>OS and / or file system uses to record file modification times). >> >>By the way, dos2unix and d2u are identical (byte-for-byte). >> >>The other thing I can think of is that you're not running the >>dos2unix from >>the "cygutils" package, that the version you're running was >>not ported to >>Cygwin to be immune to the mount type and (conceivably) that >>it resets the >>file's modification time after reformatting it. >> >>Randall Schulz >>Mountain View, CA USA >> Hi, All, It's in the cygwin file tree, /usr/bin/dos2unix version 0.1.2. The file was a few minutes old when I tried in-place conversion. Anything is possible, regarding preserving the file timestamp even after the conversion (afterall, I think some gzip's do that). My "fix" is to use it as a filter. Fred -- Fred Ma, [EMAIL PROTECTED] Carleton University, Dept. of Electronics 1125 Colonel By Drive, Ottawa, Ontario Canada, K1S 5B6 -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
