rcs 5.8-1 corrupt files?
rcs 5.8-1 A problem with rcs. - corrupt files.. Here is the sequence: Create a 'hello world' file using vi. Check in a file. ci -u sam Check out the file co -l sam get error when doing rlog on the next ci of the file. example: rlog sam rlog: RCS/sam,v:31: junk at end of file: 't' rlog aborted Here is a hex dump of sam $ od -cx sam 000 h e l l o w o r l d . \r \n \r \n 65686c6c206f6f776c722e640a0d0a0d 020 \r \n \r \n \r \n 0a0d0a0d0a0d 026 Here is a hex dump of the rcs file: $ od -cx rcs/sam,v 000 h e a d \t 1 . 1 ; \r \n a c c e s 656864613109312e0d3b610a63637365 020 s ; \r \n s y m b o l s ; \r \n l o 3b730a0d7973626d6c6f3b730a0d6f6c 040 c k s \r \n \t j a y : 1 . 1 ; s 6b630d73090a616a3a792e313b317320 060 t r i c t ; \r \n c o m m e n t \t 727463693b740a0d6f636d6d6e650974 100 @ # @ ; \r \n \r \n \r \n 1 . 1 \r \n 234040200d3b0d0a0d0a310a312e0a0d 120 d a t e \t 2 0 1 1 . 1 2 . 1 1 . 61646574320931302e313231312e2e31 140 0 3 . 4 6 . 3 3 ; \t a u t h o r 3330342e2e36093b75616874726f 160 j a y ; \t s t a t e E x p ; 6a207961093b74737461206578453b70 200 \r \n b r a n c h e s ; \r \n n e x 0a0d72626e61686373650d3b6e0a7865 220 t \t ; \r \n \r \n \r \n d e s c \r \n @ 09740d3b0d0a0d0a640a73650d63400a 240 h e l l o \r \n @ \r \n \r \n \r \n 1 . 65686c6c0d6f400a0a0d0a0d0a0d2e31 260 1 \r \n l o g \r \n @ I n i t i a l 0d316c0a676f0a0d4940696e69746c61 300 r e v i s i o n \r \n @ \r \n t e 7220766573696f690d6e400a0a0d6574 320 x t \r \n @ h e l l o w o r l d 74780a0d68406c656f6c7720726f646c 340 . \r \n \r \n \r \n \r \n \r \n @ \r \n t \r 0d2e0d0a0d0a0d0a0d0a400a0a0d0d74 360 \r \n @ h e l l o w o r l d . \r 0a0d68406c656f6c7720726f646c0d2e 400 \r \n \r \r \n \r \r \n \r \r \n \r \r \n @ \r 0a0d0d0d0d0a0a0d0d0d0d0a0a0d0d40 420 \r \n 0a0d 422 --- problem also exists if you add a line, then try to check in. $ vi sam $ ci -u sam ci: RCS/sam,v:31: junk at end of file: 't' ci aborted --- Suspected line-ender problem. Started over and used 'flip' to go with unix line-ender. Same problems. BUT it looks like the DOS lime ender was added after the flip by ci, or co. $ vi henry $ flip -u henry $ od -cx henry 000 W h a t s u p ? \n \n 68577461207370750a3f000a 013 $ ci -u henry RCS/henry,v <-- henry enter description, terminated with single '.' or end of file: NOTE: This is NOT the log message! Did a flip before ci. . initial revision: 1.1 done $ co -l henry RCS/henry,v --> henry revision 1.1 (locked) done $ od -cx henry 000 W h a t s u p ? \r \n \r \n 68577461207370750d3f0d0a000a 015 -- Promlem is still there. $ rlog henry rlog: RCS/henry,v:28: junk at end of file: '@' rlog aborted --- I have saved off my home directory. Deleted Both the cygwin and the download directories. Reinstalled from a different mirror. reloaded my home. Still problem. I found that flip -u does better job than dos2unix. - reverting back to 5.7-11 of rcs bypasses problem. T H A N K S, Jay PS The cygcheck.out file will show that I reverted back to an older rcs. cygcheck.out Description: Binary data -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFE: mintty + trackpoint?
On 10 December 2011 15:15, Ryan Johnson wrote: > Hi all (esp. Andy), > > A recent email on the cygwin/x mailing list pointed out that Lenovo > trackpoint scrolling had stopped working in xterm [1]. I didn't know it was > there in the first place, but I can just imagine how useful it would be. Any > chance of mintty picking up that functionality? Combining mintty's existing > handling of mouse scrolling with the trackpoint would be really slick, but I > don't know how hard it would be. It's also unclear whether the X11 faq entry > about trackpoint is out of date [2], since I've never followed those > directions and yet xterm scrolls fine for me. > > [1] http://cygwin.com/ml/cygwin-xfree/2011-12/msg00022.html > [2] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trackpoint I'm afraid I don't know what special support if any might be needed here, and I haven't got the hardware to try it. Both scroll messages and mousewheel messages should work already, so unless there's a special message type for trackpoints, this sounds primarily like a driver configuration issue. Andy -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Failure to bootstrap current gcc trunk on cygwin (20111207 snapshot): conflicting declarations in cygwin's /usr/include/sys/wait.h
On 7 December 2011 20:14, Christian Joensson wrote: > I am trying to build gcc trunk on cygwin (with the snapshot of > 20111207) and get this: > > /usr/local/src/trunk/objdir.withada/./prev-gcc/g++ > -B/usr/local/src/trunk/objdir.withada/./prev-gcc/ > -B/usr/i686-pc-cygwin/bin/ -nostdinc++ > -B/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/src/.libs > -B/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/libsupc++/.libs > -I/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/include/i686-pc-cygwin > -I/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/include > -I/usr/local/src/trunk/gcc/libstdc++-v3/libsupc++ > -L/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/src/.libs > -L/usr/local/src/trunk/objdir.withada/prev-i686-pc-cygwin/libstdc++-v3/libsupc++/.libs > -c -g -O2 -gtoggle -DIN_GCC -fno-exceptions -fno-rtti -W -Wall > -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror > -fno-common -Wno-error -DHAVE_CONFIG_H -I. -Iada > -I/usr/local/src/trunk/gcc/gcc -I/usr/local/src/trunk/gcc/gcc/ada > -I/usr/local/src/trunk/gcc/gcc/../include > -I/usr/local/src/trunk/gcc/gcc/../libcpp/include -I/usr/include > -I/usr/include -I/usr/local/src/trunk/gcc/gcc/../libdecnumber > -I/usr/local/src/trunk/gcc/gcc/../libdecnumber/bid -I../libdecnumber > /usr/local/src/trunk/gcc/gcc/ada/adaint.c -o ada/adaint.o > In file included from /usr/local/src/trunk/gcc/gcc/system.h:346:0, > from /usr/local/src/trunk/gcc/gcc/ada/adaint.c:107: > /usr/include/sys/wait.h: In function 'int __wait_status_to_int(const wait&)': > /usr/include/sys/wait.h:77:61: error: declaration of C function 'int > __wait_status_to_int(const wait&)' conflicts with > /usr/include/sys/wait.h:75:12: error: previous declaration 'int > __wait_status_to_int(int)' here > /usr/include/sys/wait.h: In function 'pid_t wait(wait*)': > /usr/include/sys/wait.h:81:40: error: declaration of C function 'pid_t > wait(wait*)' conflicts with > /usr/include/sys/wait.h:37:7: error: previous declaration 'pid_t > wait(__wait_status_ptr_t)' here > /usr/include/sys/wait.h: In function 'pid_t waitpid(pid_t, wait*, int)': > /usr/include/sys/wait.h:83:71: error: declaration of C function 'pid_t > waitpid(pid_t, wait*, int)' conflicts with > /usr/include/sys/wait.h:38:7: error: previous declaration 'pid_t > waitpid(pid_t, __wait_status_ptr_t, int)' here > /usr/include/sys/wait.h: In function 'pid_t wait3(wait*, int, rusage*)': > /usr/include/sys/wait.h:85:81: error: declaration of C function 'pid_t > wait3(wait*, int, rusage*)' conflicts with > /usr/include/sys/wait.h:39:7: error: previous declaration 'pid_t > wait3(__wait_status_ptr_t, int, rusage*)' here > /usr/include/sys/wait.h: In function 'pid_t wait4(pid_t, wait*, int, > rusage*)': > /usr/include/sys/wait.h:87:94: error: declaration of C function 'pid_t > wait4(pid_t, wait*, int, rusage*)' conflicts with > /usr/include/sys/wait.h:40:7: error: previous declaration 'pid_t > wait4(pid_t, __wait_status_ptr_t, int, rusage*)' here this seems to me to be fixed, as of cygwin snapshot 20111209 I no longer get this specific error. -- Cheers, /ChJ -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Sun, Dec 11, 2011 at 08:07:12AM +0100, marco atzeri wrote: >On 12/11/2011 7:34 AM, Christopher Faylor wrote: > >>> The issue is still present from 2029 to current CVS (fith select). >>> Any clue ? >> >> The hanging problem should be fixed in recent snapshots. > >it was fixed on yesterday CVS Actually, it should have been fixed a couple of days ago. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Sun, 2011-12-11 at 01:34 -0500, Christopher Faylor wrote: > The hanging problem should be fixed in recent snapshots. Unfortunately not for automoc4. :-( Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: RFE: mintty + trackpoint?
On 11/12/2011 6:08 AM, Andy Koppe wrote: On 10 December 2011 15:15, Ryan Johnson wrote: Hi all (esp. Andy), A recent email on the cygwin/x mailing list pointed out that Lenovo trackpoint scrolling had stopped working in xterm [1]. I didn't know it was there in the first place, but I can just imagine how useful it would be. Any chance of mintty picking up that functionality? Combining mintty's existing handling of mouse scrolling with the trackpoint would be really slick, but I don't know how hard it would be. It's also unclear whether the X11 faq entry about trackpoint is out of date [2], since I've never followed those directions and yet xterm scrolls fine for me. [1] http://cygwin.com/ml/cygwin-xfree/2011-12/msg00022.html [2] http://x.cygwin.com/docs/faq/cygwin-x-faq.html#q-trackpoint I'm afraid I don't know what special support if any might be needed here, and I haven't got the hardware to try it. Both scroll messages and mousewheel messages should work already, so unless there's a special message type for trackpoints, this sounds primarily like a driver configuration issue. Looks like you're right. The following magic incantation works for me (T410s, Win7/x64), thanks to [3]. Add the following near the top of both TP4Scrol.dat and TP4Table.dat (in C:\Program Files\Synaptic\SynTP on my machine), then kill all UltraNav-related processes and restart them; you also have to restart any mintty you want to see the new behavior. ; mintty *,*,mintty.exe,*,*,*,WheelStd,0,9 [3] http://forums.lenovo.com/t5/ThinkVantage-Technologies/Trackpoint-Auto-select-scrolling-not-compatible-with-Firefox-3/td-p/94075 -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
Corinna Vinschen, le Thu 08 Dec 2011 09:47:45 +0100, a écrit : > Too bad. In that case, Samuel, can you please have a closer look to > see what broke brltty? The switch to mintty, simply. Brltty uses ReadConsoleOutputCharacter() to get the text from consoles, I bet mintty does not implement this. Lars thus needs cygwin to be able to run from a standard windows console too. > I have not the faintest idea how to test it Install brltty, and run brltty -b xw When the focus is on a windows console, a window on the top of the screen will show up, representing the output that would show up on a braille device. > and how to see if it works or not. Try to switch to mintty, the window will disappear, because ReadConsoleOutputCharacter will stop working. Samuel -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Sun, Dec 11, 2011 at 09:32:39PM +0100, Samuel Thibault wrote: >Corinna Vinschen, le Thu 08 Dec 2011 09:47:45 +0100, a ?crit : >> Too bad. In that case, Samuel, can you please have a closer look to >> see what broke brltty? > >The switch to mintty, simply. Brltty uses ReadConsoleOutputCharacter() >to get the text from consoles, I bet mintty does not implement this. >Lars thus needs cygwin to be able to run from a standard windows console >too. > >> I have not the faintest idea how to test it > >Install brltty, and run > >brltty -b xw > >When the focus is on a windows console, a window on the top of the >screen will show up, representing the output that would show up on a >braille device. > >> and how to see if it works or not. > >Try to switch to mintty, the window will disappear, because >ReadConsoleOutputCharacter will stop working. So, then, don't use mintty with brltty. If it is an issue, you as the package maintainer, should provide a way to start brltty from a Windows console. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Sun, Dec 11, 2011 at 02:59:49PM -0600, Yaakov (Cygwin/X) wrote: >On Sun, 2011-12-11 at 01:34 -0500, Christopher Faylor wrote: >> The hanging problem should be fixed in recent snapshots. > >Unfortunately not for automoc4. :-( How do you duplicate your problem? bash-4.1$ automoc4 bash: automoc4: command not found bash-4.1$ cygcheck -p automoc4 Found 0 matches for automoc4 Also, in what snapshot did this problem first manifest? cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] CALL FOR TESTING: Cygwin 1.7.10
On Sun, Dec 11, 2011 at 08:10:15PM -0500, Christopher Faylor wrote: >On Sun, Dec 11, 2011 at 02:59:49PM -0600, Yaakov (Cygwin/X) wrote: >>On Sun, 2011-12-11 at 01:34 -0500, Christopher Faylor wrote: >>> The hanging problem should be fixed in recent snapshots. >> >>Unfortunately not for automoc4. :-( > >How do you duplicate your problem? > > bash-4.1$ automoc4 > bash: automoc4: command not found > bash-4.1$ cygcheck -p automoc4 > Found 0 matches for automoc4 > >Also, in what snapshot did this problem first manifest? And, also, more strace output would be useful from the snapshot which will be showing up in the next ten minutes or so but please make sure that you use the strace.exe from the latest snapshot. There have been some changes made to strace.exe to accommodate corresponding changes in the latest cygwin1.dll. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Sorry for a previous stupid problem reporting
I report a problem before: http://cygwin.com/ml/cygwin/2011-06/msg00069.html To my surprise, recently I found that it is caused by Norton Antivirus 9.0. It worked well with Cygwin before, things may be changed after a live updating. I'm sorry for not having read the FAQ before reporting. a huge fan of Cygwin -- Chiheng Xu -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Latest cygwin.bat - need one
Because I already had a cygwin.bat file, the upgrade from 1.5.x to 1.7.x did not provide a new one, not even a cygwin.bat.sample (which would have been nice), so that one could see if there are differences between releases. As a result of there not being a sample, my current bat file will not correctly start my Z-shell. Most of the time double-clicking on the shortcut results in the program (CMD) flashing on the screen and going away. When it does manage to stick, it seems to fail to start the zsh login process, i.e., the reading on my .z* startup files. That results in any entered characters being ignored, as there isn't a prompt there to accept input. If I start cmd.exe manually, I can then start zsh and have something to work with. At that point, if I run cygwin.bat, (from the shell, not the shortcut) it works. Something in the 1.7 environment is required for rxvt to work correctly, even though rxvt is the same version in both installations (1.5 and 1.7). That or something changed to keep zsh from starting via the bat file using rxvt. If someone would be so kind as to post the contents of the default installed cygwin.bat file, I'd appreciate it. It is the only thing keeping me from getting back to where I was working, before the upgrade. Thanks. MB -- e-mail: vid...@vidiot.com | vid...@vidiot.net/~\ The ASCII [I've been to Earth. I know where it is. ] \ / Ribbon Campaign [And I'm gonna take us there.Starbuck 3/25/07] X Against Visit - URL: http://vidiot.com/ | http://vidiot.net/ / \ HTML Email -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Another call for filesystem testing
Here's a test from Win7/64 SP1 with MVFS version 7.1.1.7 (Wed Aug 3 22:33:34 2011). ente59@PCFX061 /cygdrive/c/MyDevelopment/cygwin/test-qfif $ uname -a CYGWIN_NT-6.1-WOW64 PCFX061 1.7.10s(0.255/5/3) 2029 17:41:48 i686 Cygwin ente59@PCFX061 /cygdrive/c/MyDevelopment/cygwin/test-qfif $ /usr/lib/csih/getVolInfo /cygdrive/v Device Type: 7 Characteristics: 10 Volume Name: Serial Number : 36984713 Max Filenamelength : 255 Filesystemname : Flags : 3 FILE_CASE_SENSITIVE_SEARCH : TRUE FILE_CASE_PRESERVED_NAMES : TRUE FILE_UNICODE_ON_DISK: FALSE FILE_PERSISTENT_ACLS: FALSE FILE_FILE_COMPRESSION : FALSE FILE_VOLUME_QUOTAS : FALSE FILE_SUPPORTS_SPARSE_FILES : FALSE FILE_SUPPORTS_REPARSE_POINTS: FALSE FILE_SUPPORTS_REMOTE_STORAGE: FALSE FILE_VOLUME_IS_COMPRESSED : FALSE FILE_SUPPORTS_OBJECT_IDS: FALSE FILE_SUPPORTS_ENCRYPTION: FALSE FILE_NAMED_STREAMS : FALSE FILE_READ_ONLY_VOLUME : FALSE FILE_SEQUENTIAL_WRITE_ONCE : FALSE FILE_SUPPORTS_TRANSACTIONS : FALSE ente59@PCFX061 /cygdrive/c/MyDevelopment/cygwin/test-qfif $ ./test- qfif.exe /cygdrive/v/Stg_V5.108_ente59_iv/stg2/steuerung /cygdrive/v/Stg_V5.108 _ente59_iv/stg2/steuerung/makefile NtQueryFullAttributesFile(\??\V:\Stg_V5.108_ente59_iv\stg2\steuerung) by name works NtQueryFullAttributesFile(\??\V:\Stg_V5.108_ente59_iv\stg2\steuerung) by handle works NtQueryFullAttributesFile(\??\V:\Stg_V5.108_ente59_iv\stg2\steuerung\makefile) by name works NtQueryFullAttributesFile(\??\V:\Stg_V5.108_ente59_iv\stg2\steuerung\makefile) by handle works regards Heiko Elger -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Latest cygwin.bat - need one
On Sun, Dec 11, 2011 at 11:48:01PM -0600, Mike Brown wrote: > As a result of there not being a sample, my current bat file will not > correctly start my Z-shell. Most of the time double-clicking on the shortcut > results in the program (CMD) flashing on the screen and going away. When it > does manage to stick, it seems to fail to start the zsh login process, i.e., > the reading on my .z* startup files. That results in any entered characters > being ignored, as there isn't a prompt there to accept input. >From what I can discover, the default cygwin.bat file does not use rxvt. It has been a while since I first installed cygwin. I was starting my shell with the following line: rxvt -e zsh --login -i That got me the window, but not the shell. Doing some more digging I found the following posting (via google): > Does changing 'bash' to '/bin/bash' make a difference? Answering my own question: yes. There was a change in execvp()'s behaviour to no longer look up an executable in the current working directory, wasn't there? I can't find it in the ChangeLog though. You've got to be kidding. Why was the looking into CWD removed? Probably beating a dead horse. Suggestions for document improvement: FAQ addition to show how to modify the cygwin.bat file, or a copied file for modification, in order to be able to run rxvt to start a better terminal. This would solve the issue of users upgrading and their BAT file being broken. Be sure to explain that "/bin/" is now required. Same thing with the main documention. There are pieces about starting the shell, but absolutely nothing about using a better terminal (rxvt) and how to start/configure it. Hell, why not make the use of rxvt standard in the default BAT file. The rxvt terminal is many times superior to the Windblows cmd terminal. The only thing left now is getting ssh configured correctly so that I can remotely log into the Windblows box using ssh. The two config scripts failed to provide a working config. The remote login fails at the password checking. MB -- e-mail: vid...@vidiot.com | vid...@vidiot.net/~\ The ASCII [I've been to Earth. I know where it is. ] \ / Ribbon Campaign [And I'm gonna take us there.Starbuck 3/25/07] X Against Visit - URL: http://vidiot.com/ | http://vidiot.net/ / \ HTML Email -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
ssh login not working
When I try to ssh into the latest cygqin on the XP-pro box, I get the following: BRN <1> ssh -v -v -l vidiot PVRpeecee Sun_SSH_1.1, SSH protocols 1.5/2.0, OpenSSL 0x0090704f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to PVRpeecee [192.168.1.4] port 22. debug1: Connection established. debug1: identity file /home/brown/.ssh/identity type -1 debug1: identity file /home/brown/.ssh/id_rsa type -1 debug1: identity file /home/brown/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.9 debug1: match: OpenSSH_5.9 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-Sun_SSH_1.1 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: i-default debug2: kex_parse_kexinit: i-default debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible Unknown code 0 ) debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: i-default debug2: kex_parse_kexinit: i-default debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac...@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd...@openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: none,z...@openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: Peer sent proposed langtags, ctos: debug1: Peer sent proposed langtags, stoc: debug1: We proposed langtags, ctos: i-default debug1: We proposed langtags, stoc: i-default debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 129/256 debug1: bits set: 1032/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Host 'pvrpeecee' is known and matches the RSA host key. debug1: Found key in /home/brown/.ssh/known_hosts:4 debug1: bits set: 985/2048 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug2: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Trying private key: /home/brown/.ssh/identity debug1: Trying private key: /home/brown/.ssh/id_rsa debug1: Trying private key
Re: gcc-4.5.3 segfaults wrt alloca
On Sat, Dec 10, 2011 at 02:42:39PM +, Dave Korn wrote: >> 5. Setting the program's initial stack size larger by adding e.g. >> "-Wl,-stack,400" to the compiler commandline ensures that the initial >> stack pointer is located somewhere that at least that much memory is >> available, and makes the testcase run OK for me where previously it was >> faulting. Me (OP) too. Thank you for the explanations. Denis Excoffier. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Latest cygwin.bat - need one
On Mon, 12 Dec 2011, Mike Brown wrote: Doing some more digging I found the following posting (via google): > Does changing 'bash' to '/bin/bash' make a difference? Answering my own question: yes. There was a change in execvp()'s behaviour to no longer look up an executable in the current working directory, wasn't there? I can't find it in the ChangeLog though. You've got to be kidding. Why was the looking into CWD removed? PATH specifies the list of directories to search for executables. So if execvp() ever used "." unconditionally regardless of PATH, then it violated one of the most long-standing UNIXy rules. It can also be a massive security hole. On a multi-user system, I can put a script named "ls" in /tmp, or other likely directory for others to cd to, to - copy /bin/bash to some location - set the setuid bit and setgid on this copy - run /bin/ls (Bonus points: somehow filter out this nasty ls script if they are looking at /tmp. This is hard.) Anyone foolish enough to put "." near the start of their PATH and who did cd /tmp ls would thereby get their account hacked, and changing their password would do no good. I removed "." from my PATH in the 1980s for just this reason. At least if "." is after standard system directories like /bin /usr/bin, it mitigates the problem to a large extent: it catches only typos and attempts to run programs that you don't have installed. I wonder if there are any common typos to try for. If execvp() ever looked in "." unconditionally, there would be no way to ever completely close this security hole. -- Tim McDaniel, t...@panix.com -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
