src/winsup/cygwin ChangeLog termios.cc
CVSROOT:/cvs/src Module name:src Changes by: [EMAIL PROTECTED] 2007-09-26 08:57:35 Modified files: winsup/cygwin : ChangeLog termios.cc Log message: * termios.cc (setspeed): Support new baud rates introduced 2007-02-05. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/ChangeLog.diff?cvsroot=srcr1=1.3932r2=1.3933 http://sourceware.org/cgi-bin/cvsweb.cgi/src/winsup/cygwin/termios.cc.diff?cvsroot=srcr1=1.31r2=1.32
Re: Non-standard serial port baud rates
On Sep 25 18:33, Andrew M. Bishop wrote: In the snapshot versions from mid-February there is indeed support for other non-standard speeds (like 100, 200, 300) in the tcsetattr() and tcgetattr() functions in fhandler_serial.cc. There isn't however the corresponding change to the cfsetospeed() and cfsetispeed() functions in termios.cc. [...] Can the change be applied to the cfset[oi]speed() functions as well please. Done. Thanks for the heads-up. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: cygpath -u doesn't seem to convert spaces properly
Brian Dessent wrote: $ cd $ttt bash: cd: /cygdrive/c/Program: No such file or directory Yes, that's wrong. [...] It's got nothing to do with cygpath and everything to do with proper portable scripting practice. Quite true. When you're using bash or sh, you must *quote your arguments* if they could possibly contain spaces or other word separators. So learn to do it. Seriously, take a few minutes and try it: $ mkdir a b c $ ABC=a b c bash: cd: a: No such file or directory $ cd $ABC ... etc. If you don't want to have to quote variable expansions all the time, use another shell. I know that zsh, at least, doesn't require you to quote them. That being said, you still should learn how to quote in a regular POSIX shell. Portable shell scripts should really start with #!/bin/sh, after all. -gsw -- 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: Bash -c without exiting
I modified Cygwin.bat to the following, bash --login -i -c 'cd /cygdrive/c exec bash' and it still exits. -- View this message in context: http://www.nabble.com/Bash--c-without-exiting-tf4518164.html#a12901775 Sent from the Cygwin Users mailing list archive at Nabble.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/
MATLAB mexFunction() with Cygwin GCC Windows
I have successfully built/linked MATLAB mex files on Windows using GCC in
Cygwin. Unfortunately, it has a runtime error. It appears the error is due to
mismatched calling coventions for parameter passing. The MATLAB interpreter
successfully invokes the mexFunction() in my shared library (.mexw32), but the
passed parameters are corrupted.
I've tried GCC's attribute to set the mexFunction() to cdecl, stdcall,
and fastcall, but still no luck.
Anyone know the solution?
Details follow:
MATLAB mexopts.bat
=
@echo off
rem Cygwin GCC on Windows
set MATLAB=%MATLAB%
set COMPILER=gcc
set COMPFLAGS=-mno-cygwin -D_WIN32 -shared -DMATLAB_MEX_FILE -Wall -c -msse3
-I%ProgramFiles%\Pthreads\include -I%ProgramFiles%\Verasonics\Hal\Hal
C\Includes -o%MEX_NAME%.obj
set OPTIMFLAGS=-O3
set DEBUGFLAGS=-g3
set LINKER=gcc
set LINKFLAGS=-mno-cygwin -D_WIN32 -shared -DMATLAB_MEX_FILE -nostartfiles
-L%ProgramFiles%\Verasonics\Hal\Hal C\Shared Libraries -lverasonicshalwindows
-L%ProgramFiles%\MATLAB\R2007a\bin\win32 -lmat -lmex -lmx
set LINKOPTIMFLAGS=-s
set LINKDEBUGFLAGS=
set NAME_OUTPUT=-o%MEX_NAME%.mexw32
myMex.c
#include mex.h
#include stdio.h
void mexFunction(int nlhs, mxArray *plhs[], int nrhs, const mxArray *prhs[])
{
//x
printf(We are not successfully passing parameters. We will be successful
when 'nlhs' is '1' and 'nrhs' is '0'. They are: %d and %d\n, nlhs, nrhs);
//x
// Return the result as a string.
plhs[0] = mxCreateString(Some text goes here);
return;
}
--
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: MATLAB mexFunction() with Cygwin GCC Windows
On Wed, 26 Sep 2007, Boyd Edmondson wrote: I have successfully built/linked MATLAB mex files on Windows using GCC in Cygwin. Unfortunately, it has a runtime error. It appears the error is due to mismatched calling coventions for parameter passing. The MATLAB interpreter successfully invokes the mexFunction() in my shared library (.mexw32), but the passed parameters are corrupted. I've tried GCC's attribute to set the mexFunction() to cdecl, stdcall, and fastcall, but still no luck. Anyone know the solution? Details follow: MATLAB mexopts.bat = [snip] set COMPILER=gcc set COMPFLAGS=-mno-cygwin -D_WIN32 -shared -DMATLAB_MEX_FILE -Wall -c -msse3 -I%ProgramFiles%\Pthreads\include -I%ProgramFiles%\Verasonics\Hal\Hal C\Includes -o%MEX_NAME%.obj ^^^ set LINKER=gcc set LINKFLAGS=-mno-cygwin -D_WIN32 -shared -DMATLAB_MEX_FILE -nostartfiles -L%ProgramFiles%\Verasonics\Hal\Hal C\Shared Libraries -lverasonicshalwindows -L%ProgramFiles%\MATLAB\R2007a\bin\win32 -lmat -lmex -lmx ^^^ See the underlined portions above. You're not using the Cygwin gcc, you're really using the MinGW gcc that understands Cygwin paths. So you're better off asking on the MinGW list. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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: MATLAB mexFunction() with Cygwin GCC Windows
Done. Thanks. Boyd -Original Message- From: Igor Peshansky [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 26, 2007 7:24 AM To: Boyd Edmondson Cc: cygwin@cygwin.com Subject: Re: MATLAB mexFunction() with Cygwin GCC Windows On Wed, 26 Sep 2007, Boyd Edmondson wrote: I have successfully built/linked MATLAB mex files on Windows using GCC in Cygwin. Unfortunately, it has a runtime error. It appears the error is due to mismatched calling coventions for parameter passing. The MATLAB interpreter successfully invokes the mexFunction() in my shared library (.mexw32), but the passed parameters are corrupted. I've tried GCC's attribute to set the mexFunction() to cdecl, stdcall, and fastcall, but still no luck. Anyone know the solution? Details follow: MATLAB mexopts.bat = [snip] set COMPILER=gcc set COMPFLAGS=-mno-cygwin -D_WIN32 -shared -DMATLAB_MEX_FILE -Wall -c -msse3 -I%ProgramFiles%\Pthreads\include -I%ProgramFiles%\Verasonics\Hal\Hal C\Includes -o%MEX_NAME%.obj ^^^ set LINKER=gcc set LINKFLAGS=-mno-cygwin -D_WIN32 -shared -DMATLAB_MEX_FILE -nostartfiles -L%ProgramFiles%\Verasonics\Hal\Hal C\Shared Libraries -lverasonicshalwindows -L%ProgramFiles%\MATLAB\R2007a\bin\win32 -lmat -lmex -lmx ^^^ See the underlined portions above. You're not using the Cygwin gcc, you're really using the MinGW gcc that understands Cygwin paths. So you're better off asking on the MinGW list. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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: OpenSSH and user environment: Maybe not initialized correctly
Frank wrote: I try to send the three cygcheck outputs unzipped with this mail. OnAMD64 sshd is running as sshd_server SMITHFIELD sshd is running as SYSTEM on both machines I use public key authentication. And for my application I shall stick to public key authentication. Does this clarify and can you now give more information or do you still need any additional thigs/settings to tell? No, I don't see allot that clarifies things for me here, but thanks for sending it. :-) I do see that FI-WIN and AMD64 don't have '/bin/sh' but I don't think that's significant in your case (though you should reinstall the 'bash' package to fix this). I'm actually surprised that you get AMD to report your user name with pubkey authentication. I'm not aware of anything in the current Cygwin release that would allow one to authenticate with Windows using pubkey authentication, which is why I suggested password authentication as an alternative (I know it's hardly the same thing). You might find comparing debugging output from the server side from both machines on login to be enlightening. Other alternatives I can think of is authenticating illenseer (via 'net use' or some other mechanism of your choosing) when you connect with 'ssh' or moving to a snapshot to take advantages of improvements there. You can also try forcing 'ssh-host-config' to create the 'sshd_server' on your XP box and use that user instead to run 'ssd' there. Maybe whatever magic you're experiencing on AMD64 will transfer to SMITHFIELD. Please let us know if you find something here that explains the different behavior you see on these two machines. BTW, I am assuming that you're using 'whoami' from Windows on both of these machines. If not, then we know why you see the difference reported by these machines. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: OpenSSH and user environment: Maybe not initialized correctly
No, I don't see allot that clarifies things for me here, but thanks for sending it. :-) No problem - you arw elcome. - I might have been helpful... I do see that FI-WIN and AMD64 don't have '/bin/sh' but I don't think that's significant in your case (though you should reinstall the 'bash' package to fix this). There is a sh. See: $ ll /bin/sh lrwxrwxrwx 1 illenseer None 8 Nov 10 2006 /bin/sh - bash.exe I'm actually surprised that you get AMD to report your user name with pubkey authentication. We maybe do misunderstand (or I do...): On amd64 I do NOT get the correct user name. (And also my MPIEXEC uses the wrong user name...) I'm not aware of anything in the current Cygwin release that would allow one to authenticate with Windows using pubkey authentication, which is why I suggested password authentication as an alternative (I know it's hardly the same thing). Unfortunately I cannot switch to interactive password authentication. So that is not a workarund... :-( You might find comparing debugging output from the server side from both machines on login to be enlightening. Other alternatives I can think of is authenticating illenseer (via 'net use' or some other mechanism of your choosing) when you connect with 'ssh' or moving to a snapshot to take advantages of improvements there. You can also try forcing 'ssh-host-config' to create the 'sshd_server' on your XP box and use that user instead to run 'ssd' there. Maybe whatever magic you're experiencing on AMD64 will transfer to SMITHFIELD. Can you explain more detailed what you are thinking of, please? - I do not quite get your point or yur ideas/suggestions... Please let us know if you find something here that explains the different behavior you see on these two machines. I will dig around if time permitts and if I find something I will inform you. BTW, I am assuming that you're using 'whoami' from Windows on both of these machines. If not, then we know why you see the difference reported by these machines. ;-) on FI-WIN: which whoami = /usr/bin/whoami on AMD64: ssh amd64 which whoami = /cygdrive/c/WINDOWS/system32/whoami on SMITHFIELD: ssh smithfield which whoami = /usr/bin/whoami And I did one additional test: ssh amd64 whoami= amd64\sshd_server ssh amd64 /usr/bin/whoami = illenseer -- 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: OpenSSH and user environment: Maybe not initialized correctly
On Sep 26 18:32, Frank wrote: BTW, I am assuming that you're using 'whoami' from Windows on both of these machines. If not, then we know why you see the difference reported by these machines. ;-) on FI-WIN: which whoami = /usr/bin/whoami on AMD64: ssh amd64 which whoami = /cygdrive/c/WINDOWS/system32/whoami on SMITHFIELD: ssh smithfield which whoami = /usr/bin/whoami And I did one additional test: ssh amd64 whoami= amd64\sshd_server ssh amd64 /usr/bin/whoami = illenseer Using pubkey authentication, the user name Cygwin sees is not the user name Windows sees. This is a problem of how pubkey authentication is achieved, and in which logon session the processes are running. The strange Windows behaviour is a long-standing bug (present in NT 4 already), IMHO, which never got fixed (still present in Vista). This has been discussed many many times on this list. Please search the mailing list archives. If you want Windows having the same idea of the user name as Cygwin, you must either use password authentication, or you can take the risk using the Cygwin developer snapshots and install the cyglsa DLL. There's a /usr/bin/cyglsa-config script which helps you to install it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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: cygpath -u doesn't seem to convert spaces properly
Thanks, Jerome Williams, Gerald S (Jerry) wrote: Brian Dessent wrote: $ cd $ttt bash: cd: /cygdrive/c/Program: No such file or directory Yes, that's wrong. [...] It's got nothing to do with cygpath and everything to do with proper portable scripting practice. Quite true. When you're using bash or sh, you must *quote your arguments* if they could possibly contain spaces or other word separators. So learn to do it. Seriously, take a few minutes and try it: $ mkdir a b c $ ABC=a b c bash: cd: a: No such file or directory $ cd $ABC ... etc. If you don't want to have to quote variable expansions all the time, use another shell. I know that zsh, at least, doesn't require you to quote them. That being said, you still should learn how to quote in a regular POSIX shell. Portable shell scripts should really start with #!/bin/sh, after all. -gsw -- 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: Bash -c without exiting
patrickinminneapolis wrote: I modified Cygwin.bat to the following, bash --login -i -c 'cd /cygdrive/c exec bash' and it still exits. I think you can get the effect you want by changing your home directory in /etc/passwd to /cygdrive/c -- 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: setup.exe deleted some files
I'm adapting to all the changes since B20. I have adopted the following changes in the way I do things: 1) make sure my backups are *really* working before any upgrades 2) institute protected programs; by linking items in /bin to /localbin 3) now that I better understand setup, go with the flo 4) put locally written pgms into /localbin to leave /bin cygwin only I thank you all for your replies to this thread. Now that I'm retired I have more time to deal with problems changes. - Paul McFerrin Christopher Faylor wrote: On Tue, Sep 25, 2007 at 08:32:26AM -0400, Larry Hall (Cygwin) wrote: Paul McFerrin wrote: Can you really *expect* that someone running B20 for 5+ years can remember from which package to select so you will not lose a particular program that you've been using for years. Heck I didn't even know it was part of the linux util package. I never used a Linus system before. The cal command was introduced back in SVR2 days (~1976)! Way before Linux came on the scene! Yes, I'm showing my age. No I don't expect you to remember details of your ancient install. I would expect that you'd recognize that quite allot has likely changed in the interim and that you might need to do a little leg-work to get everything you had back to the way you like it. I don't believe Cygwin is unusual in this respect. Any 6+ year old distribution is going to have changes that may seem a little jarring to those that may be seeking to have everything just the way they had it. Of course, if you feel that these realities don't live up to your expectations, you are free to stick with the versions you have for as long as they do what you want. There's all that plus the fact that B20 didn't actually have packages anyway. That was more-or-less the point of subsequent releases - allowing people to choose what they wanted. cgf -- 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/ -- 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: OpenSSH and user environment: Maybe not initialized correctly
Frank wrote: I do see that FI-WIN and AMD64 don't have '/bin/sh' but I don't think that's significant in your case (though you should reinstall the 'bash' package to fix this). There is a sh. See: $ ll /bin/sh lrwxrwxrwx 1 illenseer None 8 Nov 10 2006 /bin/sh - bash.exe Ah. Well that is wrong. '/bin/sh' should be a copy of '/bin/bash'. I'd still recommend reinstalling the bash package to see if that creates the proper '/bin/sh'. I'm actually surprised that you get AMD to report your user name with pubkey authentication. We maybe do misunderstand (or I do...): On amd64 I do NOT get the correct user name. (And also my MPIEXEC uses the wrong user name...) My bad. I had this reversed. I'm not aware of anything in the current Cygwin release that would allow one to authenticate with Windows using pubkey authentication, which is why I suggested password authentication as an alternative (I know it's hardly the same thing). Unfortunately I cannot switch to interactive password authentication. So that is not a workarund... :-( Yeah, sure. I understand. I expected so much. You might find comparing debugging output from the server side from both machines on login to be enlightening. Other alternatives I can think of is authenticating illenseer (via 'net use' or some other mechanism of your choosing) when you connect with 'ssh' or moving to a snapshot to take advantages of improvements there. You can also try forcing 'ssh-host-config' to create the 'sshd_server' on your XP box and use that user instead to run 'ssd' there. Maybe whatever magic you're experiencing on AMD64 will transfer to SMITHFIELD. Can you explain more detailed what you are thinking of, please? - I do not quite get your point or yur ideas/suggestions... Never mind. You've clarified for me below why you saw what you saw. Please let us know if you find something here that explains the different behavior you see on these two machines. I will dig around if time permitts and if I find something I will inform you. BTW, I am assuming that you're using 'whoami' from Windows on both of these machines. If not, then we know why you see the difference reported by these machines. ;-) on FI-WIN: which whoami = /usr/bin/whoami on AMD64: ssh amd64 which whoami = /cygdrive/c/WINDOWS/system32/whoami on SMITHFIELD: ssh smithfield which whoami = /usr/bin/whoami And I did one additional test: ssh amd64 whoami= amd64\sshd_server ssh amd64 /usr/bin/whoami = illenseer Ah-ha! Well that explains the different results then. There is no magic going on here. You are the user that runs 'sshd' then, as expected, as far as Windows is concerned. Corinna's response is all you need. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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/
configuration problem: ssh working but not sftp
Why does ssh work but not sftp? What is wrong with my configuration? sftp works OK in the other direction, from sony06 to dell03. [EMAIL PROTECTED] ~/cygarc $ sftp sony06 Connecting to sony06... Received message too long 1920298606 [EMAIL PROTECTED] ~/cygarc $ ssh sony06 Last login: Wed Sep 26 20:05:06 2007 from dell03 Fanfare!!! You are successfully logged in to this server!!! -- 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: configuration problem: ssh working but not sftp
On Wed, 26 Sep 2007, Charles D. Russell wrote: Why does ssh work but not sftp? What is wrong with my configuration? sftp works OK in the other direction, from sony06 to dell03. [EMAIL PROTECTED] ~/cygarc $ sftp sony06 Connecting to sony06... Received message too long 1920298606 [EMAIL PROTECTED] ~/cygarc $ ssh sony06 Last login: Wed Sep 26 20:05:06 2007 from dell03 Fanfare!!! You are successfully logged in to this server!!! When you connect via ssh, you get a login shell. When you connect via sftp, you get a non-login shell, which communicates with the sftp command via standard output. Make sure your non-login shell doesn't print anything (say, from .bashrc). FWIW, 1920298606 in hex is 72756E6E (which also spells runn). Coincidence? ;-) Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! Belief can be manipulated. Only knowledge is dangerous. -- Frank Herbert -- 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: OpenSSH and user environment: Maybe not initialized correctly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Larry Hall (Cygwin) on 9/26/2007 4:05 PM: $ ll /bin/sh lrwxrwxrwx 1 illenseer None 8 Nov 10 2006 /bin/sh - bash.exe Ah. Well that is wrong. '/bin/sh' should be a copy of '/bin/bash'. I'd still recommend reinstalling the bash package to see if that creates the proper '/bin/sh'. A symlink is okay if you only ever invoke /bin/sh via cygwin apps; it only breaks when trying to call sh from native Windows apps, since they don't follow symlinks. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFG+wvH84KuGfSFAYARAiYKAJ9H9iemfZIiPQo/kla05RO6QwMslACgruCB I7luz4xUNAXRLAL6rhB6NdY= =opkl -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/
[ANNOUNCEMENT] Updated [experimental]: bash-3.2.25-17
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A new release of bash, 3.2.25-17, has been uploaded for experimental use
(3.2.25-16 remains current for now).
NEWS:
=
This is a minor patch release. It fixes a bug in (times file) | cat,
introduced in -11. It incorporates a patch that retries up to 4 times
over the course of 15 seconds if fork() fails with EAGAIN. It also
updates the postinstall script to guarantee that /dev/std{in,out,err} and
/dev/fd exist. Based on user response, I may be convinced to fold in the
rest of Igor's create_devices.sh [see
http://cygwin.com/cygwin-ug-net/using-specialnames.html] into the bash
postinstall, as it admittedly looks a bit weird when 'ls /dev' shows
/dev/stdin but not /dev/null (rest assured, all the devices still exist,
even if a listing of /dev does not show them).
Based on how the postinstall behaves, I will either promote this version
to current, or else spin 3.2.25-18 to correct the issues, in a couple of
weeks.
There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux. Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by default.
2. d2u is your friend. You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file. If you absolutely
must use files with \r\n line endings, consider mounting the directory
where those files live as a text mount. However, text mounts are not as
well tested or supported on the cygwin mailing list, so you may encounter
other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific shell option, named igncr
to force bash to ignore \r, independently of cygwin's mount style. As of
bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files. I hope to convince the upstream bash maintainer to accept
this patch into the future bash 4.0 even on Linux, rather than keeping it
a cygwin-specific patch, but only time will tell. There are several ways
to activate this option:
4a. For a single affected script, add this line just after the she-bang:
(set -o igncr) 2/dev/null set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the shopt, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired. Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it. It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks the
current state of 'set -o igncr'. If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
5. You can also experiment with the IFS variable for controlling how bash
will treat \r during variable expansion.
6. Normally, cygwin treats DOS-style paths as binary only. This release
of bash includes a hack to check the underlying mount point of files, even
when passed as DOS style paths, but other cygwin tools do not. You are
better off learning how to use POSIX-style paths.
7. There are varying levels of speed at which bash operates. The fastest
is on a binary mount with igncr disabled (the default behavior). Next
would be text mounts with igncr disabled and no \r in the underlying file.
Next would be binary mounts with igncr enabled. And the slowest that bash
will operate is on text mounts with igncr enabled.
8. If you don't like how bash behaves, then propose a patch, rather than
proposing idle ideas. This turn of events has already been talked to
death on the mailing lists by people with many ideas, but few patches.
9. If you forget to read this release announcement, the best you can
expect when you complain to the list is a link back to this email.
Remember, you must not have any bash or /bin/sh instances running when you
upgrade the bash package. This release requires cygwin-1.5.24-1 or
later; and it requires libreadline6-5.2.7-9. See also the upstream
documentation in /usr/share/doc/bash-3.2.25/.
DESCRIPTION:
Bash is an sh-compatible shell that incorporates useful features from the
Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE
POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional
improvements over sh for both programming and interactive use. In
addition, most sh scripts can be run by Bash without modification.
As of the bash 3.0 series, cygwin /bin/sh defaults to
Re: OpenSSH and user environment: Maybe not initialized correctly
Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Larry Hall (Cygwin) on 9/26/2007 4:05 PM: $ ll /bin/sh lrwxrwxrwx 1 illenseer None 8 Nov 10 2006 /bin/sh - bash.exe Ah. Well that is wrong. '/bin/sh' should be a copy of '/bin/bash'. I'd still recommend reinstalling the bash package to see if that creates the proper '/bin/sh'. A symlink is okay if you only ever invoke /bin/sh via cygwin apps; it only breaks when trying to call sh from native Windows apps, since they don't follow symlinks. I know. I'm being pedantic but unless the OP has a firm reason for wanting a link here, I still like to point folks to the path of greatest Cygwin bliss. ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 _ A: Yes. Q: Are you sure? A: Because it reverses the logical flow of conversation. Q: Why is top posting annoying in email? -- 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: configuration problem: ssh working but not sftp
Igor Peshansky wrote: On Wed, 26 Sep 2007, Charles D. Russell wrote: Why does ssh work but not sftp? What is wrong with my configuration? sftp works OK in the other direction, from sony06 to dell03. [EMAIL PROTECTED] ~/cygarc $ sftp sony06 Connecting to sony06... Received message too long 1920298606 [EMAIL PROTECTED] ~/cygarc $ ssh sony06 Last login: Wed Sep 26 20:05:06 2007 from dell03 Fanfare!!! You are successfully logged in to this server!!! When you connect via ssh, you get a login shell. When you connect via sftp, you get a non-login shell, which communicates with the sftp command via standard output. Make sure your non-login shell doesn't print anything (say, from .bashrc). Yes, echo from .bashrc was the problem. FWIW, 1920298606 in hex is 72756E6E (which also spells runn). Coincidence? ;-) No. 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/
Updated [experimental]: bash-3.2.25-17
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
A new release of bash, 3.2.25-17, has been uploaded for experimental use
(3.2.25-16 remains current for now).
NEWS:
=
This is a minor patch release. It fixes a bug in (times file) | cat,
introduced in -11. It incorporates a patch that retries up to 4 times
over the course of 15 seconds if fork() fails with EAGAIN. It also
updates the postinstall script to guarantee that /dev/std{in,out,err} and
/dev/fd exist. Based on user response, I may be convinced to fold in the
rest of Igor's create_devices.sh [see
http://cygwin.com/cygwin-ug-net/using-specialnames.html] into the bash
postinstall, as it admittedly looks a bit weird when 'ls /dev' shows
/dev/stdin but not /dev/null (rest assured, all the devices still exist,
even if a listing of /dev does not show them).
Based on how the postinstall behaves, I will either promote this version
to current, or else spin 3.2.25-18 to correct the issues, in a couple of
weeks.
There are a few things you should be aware of before using this version:
1. When using binary mounts, cygwin programs try to emulate Linux. Bash
on Linux does not understand \r\n line endings, but interprets the \r
literally, which leads to syntax errors or odd variable assignments.
Therefore, you will get the same behavior on Cygwin binary mounts by default.
2. d2u is your friend. You can use it to convert any problematic script
into binary line endings.
3. Cygwin text mounts automatically work with either line ending style,
because the \r is stripped before bash reads the file. If you absolutely
must use files with \r\n line endings, consider mounting the directory
where those files live as a text mount. However, text mounts are not as
well tested or supported on the cygwin mailing list, so you may encounter
other problems with other cygwin tools in those directories.
4. This version of bash has a cygwin-specific shell option, named igncr
to force bash to ignore \r, independently of cygwin's mount style. As of
bash-3.2.3-5, it controls regular scripts, command substitution, and
sourced files. I hope to convince the upstream bash maintainer to accept
this patch into the future bash 4.0 even on Linux, rather than keeping it
a cygwin-specific patch, but only time will tell. There are several ways
to activate this option:
4a. For a single affected script, add this line just after the she-bang:
(set -o igncr) 2/dev/null set -o igncr; # comment is needed
4b. For a single script, invoke bash explicitly with the shopt, as in
'bash -o igncr ./myscript' rather than the simpler './myscript'.
4c. To affect all scripts, export the environment variable BASH_ENV,
pointing to a file that sets the shell option as desired. Bash will
source this file on startup for every script.
4d. Added in the bash-3.2-2 release: export the environment variable
SHELLOPTS with igncr included in it. It is read-only from within bash,
but you can set it before invoking bash; once in bash, it auto-tracks the
current state of 'set -o igncr'. If exported, then all bash child
processes inherit the same option settings; with the exception added in
3.2.9-11 that certain interactive options are not inherited in
non-interactive use.
5. You can also experiment with the IFS variable for controlling how bash
will treat \r during variable expansion.
6. Normally, cygwin treats DOS-style paths as binary only. This release
of bash includes a hack to check the underlying mount point of files, even
when passed as DOS style paths, but other cygwin tools do not. You are
better off learning how to use POSIX-style paths.
7. There are varying levels of speed at which bash operates. The fastest
is on a binary mount with igncr disabled (the default behavior). Next
would be text mounts with igncr disabled and no \r in the underlying file.
Next would be binary mounts with igncr enabled. And the slowest that bash
will operate is on text mounts with igncr enabled.
8. If you don't like how bash behaves, then propose a patch, rather than
proposing idle ideas. This turn of events has already been talked to
death on the mailing lists by people with many ideas, but few patches.
9. If you forget to read this release announcement, the best you can
expect when you complain to the list is a link back to this email.
Remember, you must not have any bash or /bin/sh instances running when you
upgrade the bash package. This release requires cygwin-1.5.24-1 or
later; and it requires libreadline6-5.2.7-9. See also the upstream
documentation in /usr/share/doc/bash-3.2.25/.
DESCRIPTION:
Bash is an sh-compatible shell that incorporates useful features from the
Korn shell (ksh) and C shell (csh). It is intended to conform to the IEEE
POSIX P1003.2/ISO 9945.2 Shell and Tools standard. It offers functional
improvements over sh for both programming and interactive use. In
addition, most sh scripts can be run by Bash without modification.
As of the bash 3.0 series, cygwin /bin/sh defaults to
