RE: Similar Bash 3.1.18 CR/LF Problem
Christopher Faylor wrote: You haven't been paying attention, it seems. We've already been over this ground. The performance impact for turning on bash's automatic CRLF handling is profound. That's why we're here. I guess WJM around here. :-) But perhaps I've been paying more attention than you think. If a patch is incorporated into upstream BASH, it's not going to cause performance problems. If it did, it would be rejected. That's something for the upstream maintainers to decide. I may be coming at this from a different angle, to be sure. I'm not really interested in a Cygwin-specific solution--I don't particularly want the ability to write scripts that can't run under Linux. 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: Similar Bash 3.1.18 CR/LF Problem
Eric Blake wrote: But I'm not sure whether making igncr the default in 'bash --posix', aka '/bin/sh', is wise, since POSIX does not permit this behavior. My only concern is that by making igncr cognizant of whether posix behavior is requested, people will start asking 'why does my script work with #!/bin/bash but not #!/bin/sh?'. Ugh... If push does come to shove, I guess I can tell the Windows-centric folks on the team to set SHELL=c:/cygwin/bin/bash.exe so that the Win32 Version of GNU make will execute bash c:\temp\tempscript.sh rather than sh. Just one more thing to get wrong; one more thing for our developer install sheet; one more faq; one more... Seriously though, as long as I can get it to work we'll be happy. -- 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: Similar Bash 3.1.18 CR/LF Problem
On Thu, Oct 05, 2006 at 10:22:11AM -0400, Williams, Gerald S (Jerry) wrote: On Wed, Oct 04, 2006 at 01:06:19PM -0400, Williams, Gerald S (Jerry) wrote: Seriously, I'd have a hard time believing that supporting CRLF endings would noticably impact performance if it were done as part of upstream BASH. Christopher Faylor wrote: You haven't been paying attention, it seems. We've already been over this ground. The performance impact for turning on bash's automatic CRLF handling is profound. That's why we're here. I guess WJM around here. :-) But perhaps I've been paying more attention than you think. If a patch is incorporated into upstream BASH, it's not going to cause performance problems. If it did, it would be rejected. That's something for the upstream maintainers to decide. I was specifically referring to your assertion that you would have a hard time believing that CRLF handling would impact performance. Since bash already has CRLF handling that impacts performance severely I don't see any basis in believing that just getting something included upstream would be a guarantee that there would be no performance problems. But, Eric has weighed in on the subject and if he says that there isn't much impact with his change, I certainly believe him. 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/
Re: Similar Bash 3.1.18 CR/LF Problem
Christopher Faylor cgf-no-personal-reply-please at cygwin.com writes: On Mon, Oct 02, 2006 at 01:14:37PM -0700, Wilks, Dan wrote: cgf wrote: I really am getting a bad feeling that, rather than FIXING THE SCRIPTS, everyone is reverting to using text mode mounts which are not what we generally recommend. ... If you want to continue to use Cygwin tools, you really should investigate converting the generated scripts. ... ... People who have not been entirely clear on what Cygwin is supposed to be or are not willing/able to adapt might be left behind by this and other similar changes. cgf I am another who has been bitten by this change to the behaviour of Cygwin. Obviously I am one who is being left behind. What platform is Cygwin written to run on? How would the Unix community react if someone ported a really nifty tool from the DOS/Windows world to Unix, but its data or script files had to have CR/LF endings for it to work? Ken. -- 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: Similar Bash 3.1.18 CR/LF Problem
On Wed, Oct 04, 2006 at 08:04:55AM +, Ken Wagnitz wrote: Christopher Faylor cgf-no-personal-reply-please at cygwin.com writes: On Mon, Oct 02, 2006 at 01:14:37PM -0700, Wilks, Dan wrote: cgf wrote: I really am getting a bad feeling that, rather than FIXING THE SCRIPTS, everyone is reverting to using text mode mounts which are not what we generally recommend. If you want to continue to use Cygwin tools, you really should investigate converting the generated scripts. People who have not been entirely clear on what Cygwin is supposed to be or are not willing/able to adapt might be left behind by this and other similar changes. I am another who has been bitten by this change to the behaviour of Cygwin. Obviously I am one who is being left behind. What platform is Cygwin written to run on? How would the Unix community react if someone ported a really nifty tool from the DOS/Windows world to Unix, but its data or script files had to have CR/LF endings for it to work? I suspect that people wouldn't use the tool or, if it was really important, they might investigate how they could help improve it by looking at sources and providing patches. However, really for the above analogy to be true, you'd have to throw in the Unix community not being quite clear on what the really nifty tool was supposed to be doing. The dilemma here is that I read other mailing lists besides cygwin where people are trying to use Cygwin but are close to giving up because it is so slow. So, making bash faster for people who are using it correctly is very desirable. In any event, while I'm not particularly interested in hearing case studies, I have a hard time believing that it is completely impossible for you or anyone to add a d2u step to whatever is generating your scripts. If you did that you would actually benefit from the bash speedups. 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/
RE: Similar Bash 3.1.18 CR/LF Problem
Christopher Faylor wrote: The dilemma here is that I read other mailing lists besides cygwin where people are trying to use Cygwin but are close to giving up because it is so slow. So, making bash faster for people who are using it correctly is very desirable. Which is why we need to get the patch in upstream. If you can't make it faster, you can at least make what you're comparing against slower. :-) Seriously, I'd have a hard time believing that supporting CRLF endings would noticably impact performance if it were done as part of upstream BASH. Special-casing Cygwin (especially when you start doing things like checking for DOS paths, examining the first line, etc.) would impact performance, surely. So I agree--don't do that. 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: Similar Bash 3.1.18 CR/LF Problem
On 04 October 2006 18:06, Williams, Gerald S (Jerry) wrote: Seriously, I'd have a hard time believing that supporting CRLF endings would noticably impact performance if it were done as part of upstream BASH. Special-casing Cygwin (especially when you start doing things like checking for DOS paths, examining the first line, etc.) would impact performance, surely. So I agree--don't do that. That's a total non-sequitur. A piece of code will have the same impact, whether it's included directly in the upstream sources, or whether it's a cygwin local patch surrounded by #ifdef __CYGWIN__. cheers, DaveK -- Can't think of a witty .sigline today -- 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: Similar Bash 3.1.18 CR/LF Problem
On Wed, Oct 04, 2006 at 01:06:19PM -0400, Williams, Gerald S (Jerry) wrote: Christopher Faylor wrote: The dilemma here is that I read other mailing lists besides cygwin where people are trying to use Cygwin but are close to giving up because it is so slow. So, making bash faster for people who are using it correctly is very desirable. Which is why we need to get the patch in upstream. If you can't make it faster, you can at least make what you're comparing against slower. :-) Seriously, I'd have a hard time believing that supporting CRLF endings would noticably impact performance if it were done as part of upstream BASH. You haven't been paying attention, it seems. We've already been over this ground. The performance impact for turning on bash's automatic CRLF handling is profound. That's why we're here. 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/
Re: Similar Bash 3.1.18 CR/LF Problem
Christopher Faylor wrote: On Wed, Oct 04, 2006 at 01:06:19PM -0400, Williams, Gerald S (Jerry) wrote: Christopher Faylor wrote: The dilemma here is that I read other mailing lists besides cygwin where people are trying to use Cygwin but are close to giving up because it is so slow. So, making bash faster for people who are using it correctly is very desirable. Which is why we need to get the patch in upstream. If you can't make it faster, you can at least make what you're comparing against slower. :-) Seriously, I'd have a hard time believing that supporting CRLF endings would noticably impact performance if it were done as part of upstream BASH. You haven't been paying attention, it seems. We've already been over this ground. The performance impact for turning on bash's automatic CRLF handling is profound. That's why we're here. But now that this code has been thoroughly chastised and left by itself to think about its bad behavior, it might have better behavior. Eric, shall we turn it back on and see? ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Similar Bash 3.1.18 CR/LF Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Williams, Gerald S (Jerry) on 10/4/2006 11:06 AM: Christopher Faylor wrote: The dilemma here is that I read other mailing lists besides cygwin where people are trying to use Cygwin but are close to giving up because it is so slow. So, making bash faster for people who are using it correctly is very desirable. Which is why we need to get the patch in upstream. If you can't make it faster, you can at least make what you're comparing against slower. :-) There may be precedent - upstream already had a patch for djgpp that stripped \r. But I also heard back from the upstream maintainer that I probably missed the cutoff for bash 3.2, since he has already built the release candidate, so I will have to keep it as a cygwin-local patch for another release cycle. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFJF0e84KuGfSFAYARAi7aAJ9DQuo95G3jCqa29KFAfySImZBfEQCg16Xi meUi+6PMQFaxDjHcCEb4u4Q= =F5Wm -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Similar Bash 3.1.18 CR/LF Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 10/4/2006 5:24 PM: Seriously, I'd have a hard time believing that supporting CRLF endings would noticably impact performance if it were done as part of upstream BASH. You haven't been paying attention, it seems. We've already been over this ground. The performance impact for turning on bash's automatic CRLF handling is profound. That's why we're here. Actually, the performance impact of reading a \r\n file on a binary mount using my igncr option is much less than the performance impact of the pristine sources, seeing as how my patch allows reading a buffer at a time rather than the original reading a character at a time, and I/O time is more of a bottleneck than character filtering once the data is read in. On the other hand, igncr has a slight performance penalty on text mounts, due to the additional branch instruction for every single character read, only to find that text mounts don't produce \r in the first place. And on binary mounts, files with plain \n are slightly penalized by the mere existence of igncr, again because I added a branch instruction in the code path of reading every character. But as long as igncr is present, then I am seriously thinking of turning it on by default on cygwin. And yes, if I do this, then I can remove the special casing of DOS path names (although the speed penalty of calling cygwin_conv_to_posix_path once per file is generally less than the speed penalty of checking whether igncr is set once per character). And we would be back to the behavior of bash-3.1-6 of gracefully handling \r\n by default, except that on binary mounts the performance of 3.1-9 is better than 3.1-6, and that a determined user who _wants_ literal \r can disable the shopt. One of the remaining issues in my mind is the following. I have no problem making igncr the default for bash, since there are no standards stating what bash may or may not do. But I'm not sure whether making igncr the default in 'bash --posix', aka '/bin/sh', is wise, since POSIX does not permit this behavior. My only concern is that by making igncr cognizant of whether posix behavior is requested, people will start asking 'why does my script work with #!/bin/bash but not #!/bin/sh?'. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFJGBg84KuGfSFAYARAvErAJoC9FFPPnk50RzLnJsDGHknEpsPNACfUK4n Pl1ovb1MWm6fPYbD2nwE3hM= =fu4P -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Similar Bash 3.1.18 CR/LF Problem
On Wed, Oct 04, 2006 at 07:17:18PM -0600, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Williams, Gerald S (Jerry) on 10/4/2006 11:06 AM: Christopher Faylor wrote: The dilemma here is that I read other mailing lists besides cygwin where people are trying to use Cygwin but are close to giving up because it is so slow. So, making bash faster for people who are using it correctly is very desirable. Which is why we need to get the patch in upstream. If you can't make it faster, you can at least make what you're comparing against slower. :-) There may be precedent - upstream already had a patch for djgpp that stripped \r. But I also heard back from the upstream maintainer that I probably missed the cutoff for bash 3.2, since he has already built the release candidate, so I will have to keep it as a cygwin-local patch for another release cycle. Am I understanding what this change does correctly? It does not really fix the CRLF problem. Instead it just strips every \r that it finds regardless of whether the \r is before a \n, right? If this is right and you can do this level of surgery on bash's buffers is it harder to detect \r\n because the \n may not be in the current buffer so you don't know when to strip a \r at the end of the buffer? -- 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: Similar Bash 3.1.18 CR/LF Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Christopher Faylor on 10/4/2006 7:58 PM: Am I understanding what this change does correctly? It does not really fix the CRLF problem. Instead it just strips every \r that it finds regardless of whether the \r is before a \n, right? Yes, igncr strips all \r, without looking whether it precedes \n. I modeled it after the igncr option of stty; isn't that the way terminals behave when they have igncr turned on? In other words, the shopt makes bash treat files more like terminals. If this is right and you can do this level of surgery on bash's buffers is it harder to detect \r\n because the \n may not be in the current buffer so you don't know when to strip a \r at the end of the buffer? Correct, but this was also what the existing upstream djgpp code did - blindly stripping \r without trying to read ahead to see if there is \n. Is it worth me trying to change the behavior to be more like fopen(rt), where the \r is stripped only if it precedes \n? Remember, text modes never see \r\n to begin with, \r seldom appears alone, and it is possible to turn the shopt off if it does the wrong thing. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFJHSI84KuGfSFAYARAmExAKC3s38MfY3Yx/tIc8VeiZ2Zstu2YgCfaJlh Cn//tYOTdxPcKTpLjzoIQHQ= =Tuvh -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: Similar Bash 3.1.18 CR/LF Problem
I really am getting a bad feeling that, rather than FIXING THE SCRIPTS, everyone is reverting to using text mode mounts which are not what we generally recommend. cgf As much as I would love to work in a pure cygwin environment it's not always possible. In our particular case the scripts are generated by the Win32 port of gnu's make. It really wants to put a cr/lf on the end of the shell script it makes and invoke sh passing it the DOS pathname of that script. I'd love to be able to use cygwin's make, but it's just not practical. -- 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: Similar Bash 3.1.18 CR/LF Problem
On Mon, Oct 02, 2006 at 01:14:37PM -0700, Wilks, Dan wrote: cgf wrote: I really am getting a bad feeling that, rather than FIXING THE SCRIPTS, everyone is reverting to using text mode mounts which are not what we generally recommend. As much as I would love to work in a pure cygwin environment it's not always possible. In our particular case the scripts are generated by the Win32 port of gnu's make. It really wants to put a cr/lf on the end of the shell script it makes and invoke sh passing it the DOS pathname of that script. I'd love to be able to use cygwin's make, but it's just not practical. If you want to continue to use Cygwin tools, you really should investigate converting the generated scripts. This shouldn't be that big a deal. We're not talking about controlling the space shuttle reentry here. We're talking about running u2d. Unfortunately, this change is butting up against the most basic core goal of the Cygwin project. If we can vastly improve the speed of bash for people who are using Cygwin the way it was meant to be used then we will definitely do that. People who have not been entirely clear on what Cygwin is supposed to be or are not willing/able to adapt might be left behind by this and other similar changes. 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/
Re: Similar Bash 3.1.18 CR/LF Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to mwoehlke on 9/29/2006 12:14 PM: Wilks, Dan wrote: So we just got the short-end? A long(?) standing behavior of cygwin and DOS paths and a recent change to bash that eliminates support for \r's. I guess we were living on the edge of something that wasn't supposed to work at all and didn't even know it. :/ We'll try to figure out some workaround for our environment. I just wish going pure cygwin was an option. Well, as we like to say here, http://cygwin.com/acronyms/#PTC. Since Eric is currently amenable to adding a shopt to bash, you have the option of implementing it yourself and submitting the patch for upstream consideration. I also mentioned that I am toying with the idea of a cygwin-specific patch that converts all script path to posix before opening them (a'la cygwin_conv_to_full_posix_path in sys/cygwin.h); at which point DOS paths to a text mode mount would inherit text mode behavior, but DOS paths to a binary mode mount would still remain binary. At any rate, I hope to post bash-3.1-9 next week with something a little nicer for ignoring \r and working with DOS paths, without too much of a penalty to people like me that avoid \r and use POSIX paths at all costs in the first place. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFHpBu84KuGfSFAYARApmFAJ9SvfJCj+VsUrDzra+lbhEgAH/4pwCdHOxu 1Z3Mw6Y50tYCb8q22nrLnqs= =M9in -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Similar Bash 3.1.18 CR/LF Problem
On Sat, Sep 30, 2006 at 09:42:39AM -0600, Eric Blake wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to mwoehlke on 9/29/2006 12:14 PM: Wilks, Dan wrote: So we just got the short-end? A long(?) standing behavior of cygwin and DOS paths and a recent change to bash that eliminates support for \r's. I guess we were living on the edge of something that wasn't supposed to work at all and didn't even know it. :/ We'll try to figure out some workaround for our environment. I just wish going pure cygwin was an option. Well, as we like to say here, http://cygwin.com/acronyms/#PTC. Since Eric is currently amenable to adding a shopt to bash, you have the option of implementing it yourself and submitting the patch for upstream consideration. I also mentioned that I am toying with the idea of a cygwin-specific patch that converts all script path to posix before opening them (a'la cygwin_conv_to_full_posix_path in sys/cygwin.h); at which point DOS paths to a text mode mount would inherit text mode behavior, but DOS paths to a binary mode mount would still remain binary. At any rate, I hope to post bash-3.1-9 next week with something a little nicer for ignoring \r and working with DOS paths, without too much of a penalty to people like me that avoid \r and use POSIX paths at all costs in the first place. If you are not going to support CRLF line endings, I really don't see any point in going overboard in trying to support MS-DOS path names. I really am getting a bad feeling that, rather than FIXING THE SCRIPTS, everyone is reverting to using text mode mounts which are not what we generally recommend. 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/
Re: Similar Bash 3.1.18 CR/LF Problem
On Thu, 28 Sep 2006, Eric Blake wrote: According to Wilks, Dan on 9/28/2006 3:59 PM: That was my guess. But since this was the cygwin installer run off of the cygwin site I thought I'd mention it, if for no other reason than tracking purposes. Maybe there's a problem with the installer / postinstall script when downgrading? Or perhaps that's intended behavior. It was just surprising. It's intended behavior; the postinstall script was not written with downgrades in mind (I may rethink that for my next release; but, it won't help you, because downgrading to 3.1-8 or earlier will not have this patch). And... it didn't run again when re-upgrading just bash to the new (broken) version so we had to manually copy bash.exe to sh.exe. What makes you think the current version is broken? In my opinion, it works just fine. However, your discovery that using Windows paths instead of POSIX paths makes cygwin revert to binary file opens on text mounts is rather interesting. I don't know if cygwin1.dll is at fault for that strange behavior. It may be possible for me to patch bash to always convert script names to POSIX before opening them, so that you would get the right mount behavior, but I'm not looking forward to such a hack. IIRC, Cygwin explicitly treats out-of-mount (Win32) paths as binary. 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! Las! je suis sot... -Mais non, tu ne l'es pas, puisque tu t'en rends compte. But no -- you are no fool; you call yourself a fool, there's proof enough in that! -- Rostand, Cyrano de Bergerac -- 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: Similar Bash 3.1.18 CR/LF Problem
Igor Peshansky wrote: On Thu, 28 Sep 2006, Eric Blake wrote: According to Wilks, Dan on 9/28/2006 3:59 PM: That was my guess. But since this was the cygwin installer run off of the cygwin site I thought I'd mention it, if for no other reason than tracking purposes. Maybe there's a problem with the installer / postinstall script when downgrading? Or perhaps that's intended behavior. It was just surprising. It's intended behavior; the postinstall script was not written with downgrades in mind (I may rethink that for my next release; but, it won't help you, because downgrading to 3.1-8 or earlier will not have this patch). And... it didn't run again when re-upgrading just bash to the new (broken) version so we had to manually copy bash.exe to sh.exe. What makes you think the current version is broken? In my opinion, it works just fine. However, your discovery that using Windows paths instead of POSIX paths makes cygwin revert to binary file opens on text mounts is rather interesting. I don't know if cygwin1.dll is at fault for that strange behavior. It may be possible for me to patch bash to always convert script names to POSIX before opening them, so that you would get the right mount behavior, but I'm not looking forward to such a hack. IIRC, Cygwin explicitly treats out-of-mount (Win32) paths as binary. Igor Yes, that's fits my recollection as well. Since both of us recall this, there's no need for anyone to check the source. Two IIRCs means we must be right! ;-) -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Similar Bash 3.1.18 CR/LF Problem
IIRC, Cygwin explicitly treats out-of-mount (Win32) paths as binary. Igor Yes, that's fits my recollection as well. Since both of us recall this, there's no need for anyone to check the source. Two IIRCs means we must be right! ;-) :) That's how my rulebook works too. So we just got the short-end? A long(?) standing behavior of cygwin and DOS paths and a recent change to bash that eliminates support for \r's. I guess we were living on the edge of something that wasn't supposed to work at all and didn't even know it. :/ We'll try to figure out some workaround for our environment. I just wish going pure cygwin was an option. Thanks for the insights. -- 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: Similar Bash 3.1.18 CR/LF Problem
Wilks, Dan wrote: So we just got the short-end? A long(?) standing behavior of cygwin and DOS paths and a recent change to bash that eliminates support for \r's. I guess we were living on the edge of something that wasn't supposed to work at all and didn't even know it. :/ We'll try to figure out some workaround for our environment. I just wish going pure cygwin was an option. Well, as we like to say here, http://cygwin.com/acronyms/#PTC. Since Eric is currently amenable to adding a shopt to bash, you have the option of implementing it yourself and submitting the patch for upstream consideration. -- Matthew My preferred shell is Christian. It's Bourne Again. -- 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/
Similar Bash 3.1.18 CR/LF Problem
Apologies that this is being written the day after without real output. I'm now at my desk without easy access to the machine in question. But... We've been using Cygwin with text-mode mounts for a long time without any problems. A new engineer started the other day, installed a brand-spanking-new cygwin and came to me with problems running a build. Without going into details of the build system, after a few hours I discovered that (all examples are from a cmd shell), foo.sh contains the single line date; datecrlf C: cd temp C:\temp sh foo.sh -- works C:\temp sh C:/temp/foo.sh - fails C:\temp sh C:\temp\foo.sh - fails The failures were of a form where the first command on a line works but the second generates an error. Removing the trailing eol on the on-line shell script allows the scripts to work regardless of how they're specified on the sh command line. Sorry, I don't remember trying sh /cygdrive/c/temp/foo.sh but if I did it also failed because I know the only way I could get it to work was w/o any path component. Mounts are as follows... C:\OE\trunk\rt\binmount C:\cygwin\bin on /usr/bin type system (textmode) C:\cygwin\lib on /usr/lib type system (textmode) C:\cygwin on / type system (textmode) c: on /cygdrive/c type system (textmode,noumount) h: on /cygdrive/h type system (textmode,noumount) i: on /cygdrive/i type system (textmode,noumount) r: on /cygdrive/r type system (textmode,noumount) s: on /cygdrive/s type system (textmode,noumount) u: on /cygdrive/u type system (textmode,noumount) Oh, and when we downloaded just bash 3.1.6(17?) it didn't overwrite the old sh. Dan -- 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: Similar Bash 3.1.18 CR/LF Problem
Wilks, Dan wrote: Apologies that this is being written the day after without real output. I'm now at my desk without easy access to the machine in question. But... We've been using Cygwin with text-mode mounts for a long time without any problems. A new engineer started the other day, installed a brand-spanking-new cygwin and came to me with problems running a build. Without going into details of the build system, after a few hours I discovered that (all examples are from a cmd shell), foo.sh contains the single line date; datecrlf C: cd temp C:\temp sh foo.sh -- works C:\temp sh C:/temp/foo.sh - fails C:\temp sh C:\temp\foo.sh - fails The failures were of a form where the first command on a line works but the second generates an error. Removing the trailing eol on the on-line shell script allows the scripts to work regardless of how they're specified on the sh command line. Sorry, I don't remember trying sh /cygdrive/c/temp/foo.sh but if I did it also failed because I know the only way I could get it to work was w/o any path component. What about bash all variations. Mounts are as follows... C:\OE\trunk\rt\binmount C:\cygwin\bin on /usr/bin type system (textmode) C:\cygwin\lib on /usr/lib type system (textmode) C:\cygwin on / type system (textmode) c: on /cygdrive/c type system (textmode,noumount) h: on /cygdrive/h type system (textmode,noumount) i: on /cygdrive/i type system (textmode,noumount) r: on /cygdrive/r type system (textmode,noumount) s: on /cygdrive/s type system (textmode,noumount) u: on /cygdrive/u type system (textmode,noumount) Oh, and when we downloaded just bash 3.1.6(17?) it didn't overwrite the old sh. That suggests the postinstall script didn't run for some reason. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Similar Bash 3.1.18 CR/LF Problem
Apologies that this is being written the day after without real output. I'm now at my desk without easy access to the machine in question. But... We've been using Cygwin with text-mode mounts for a long time without any problems. A new engineer started the other day, installed a brand-spanking-new cygwin and came to me with problems running a build. Without going into details of the build system, after a few hours I discovered that (all examples are from a cmd shell), foo.sh contains the single line date; datecrlf C: cd temp C:\temp sh foo.sh -- works C:\temp sh C:/temp/foo.sh - fails C:\temp sh C:\temp\foo.sh - fails The failures were of a form where the first command on a line works but the second generates an error. Removing the trailing eol on the on-line shell script allows the scripts to work regardless of how they're specified on the sh command line. Sorry, I don't remember trying sh /cygdrive/c/temp/foo.sh but if I did it also failed because I know the only way I could get it to work was w/o any path component. What about bash all variations. Bash fails in exactly the same way that sh does. I was able to get the real output that I should have gotten originally. :) -rwxr-x---+ 1 ahuddles mkgroup-l-d 461824 Sep 14 03:21 bash.exe -rwxr-x---+ 1 ahuddles mkgroup-l-d 461824 Sep 28 13:20 sh.exe C:\Tempmount C:\cygwin\bin on /usr/bin type system (textmode) C:\cygwin\lib on /usr/lib type system (textmode) C:\cygwin on / type system (textmode) c: on /cygdrive/c type system (textmode,noumount) h: on /cygdrive/h type system (textmode,noumount) i: on /cygdrive/i type system (textmode,noumount) r: on /cygdrive/r type system (textmode,noumount) s: on /cygdrive/s type system (textmode,noumount) u: on /cygdrive/u type system (textmode,noumount) C:\Tempod -c foo.sh 000 d a t e ; d a t e \r \n 014 C:\Tempod -t x1 foo.sh 000 64 61 74 65 3b 20 64 61 74 65 0d 0a 014 C:\Tempsh foo.sh Thu Sep 28 13:21:46 PDT 2006 Thu Sep 28 13:21:46 PDT 2006 C:\Tempsh c:/Temp/foo.sh Thu Sep 28 13:21:52 PDT 2006 : command not founde 1: date C:\Tempsh c:\Temp\foo.sh Thu Sep 28 13:21:58 PDT 2006 : command not founde 1: date C:\Tempsh /cygdrive/c/Temp/foo.sh Thu Sep 28 13:22:07 PDT 2006 Thu Sep 28 13:22:08 PDT 2006 C:\Tempbash foo.sh Thu Sep 28 13:22:12 PDT 2006 Thu Sep 28 13:22:12 PDT 2006 C:\Tempbash c:/Temp/foo.sh Thu Sep 28 13:22:17 PDT 2006 : command not founde 1: date C:\Tempbash c:\Temp\foo.sh Thu Sep 28 13:22:23 PDT 2006 : command not founde 1: date C:\Tempbash /cygdrive/c/Temp/foo.sh Thu Sep 28 13:22:36 PDT 2006 Thu Sep 28 13:22:36 PDT 2006 Oh, and when we downloaded just bash 3.1.6(17?) it didn't overwrite the old sh. That suggests the postinstall script didn't run for some reason. That was my guess. But since this was the cygwin installer run off of the cygwin site I thought I'd mention it, if for no other reason than tracking purposes. Maybe there's a problem with the installer / postinstall script when downgrading? Or perhaps that's intended behavior. It was just surprising. And... it didn't run again when re-upgrading just bash to the new (broken) version so we had to manually copy bash.exe to sh.exe. -- 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: Similar Bash 3.1.18 CR/LF Problem
Wilks, Dan wrote: Apologies that this is being written the day after without real output. I'm now at my desk without easy access to the machine in question. But... We've been using Cygwin with text-mode mounts for a long time without any problems. A new engineer started the other day, installed a brand-spanking-new cygwin and came to me with problems running a build. Without going into details of the build system, after a few hours I discovered that (all examples are from a cmd shell), foo.sh contains the single line date; datecrlf C: cd temp C:\temp sh foo.sh -- works C:\temp sh C:/temp/foo.sh - fails C:\temp sh C:\temp\foo.sh - fails The failures were of a form where the first command on a line works but the second generates an error. Removing the trailing eol on the on-line shell script allows the scripts to work regardless of how they're specified on the sh command line. Sorry, I don't remember trying sh /cygdrive/c/temp/foo.sh but if I did it also failed because I know the only way I could get it to work was w/o any path component. What about bash all variations. Bash fails in exactly the same way that sh does. I was able to get the real output that I should have gotten originally. :) -rwxr-x---+ 1 ahuddles mkgroup-l-d 461824 Sep 14 03:21 bash.exe -rwxr-x---+ 1 ahuddles mkgroup-l-d 461824 Sep 28 13:20 sh.exe C:\Tempmount C:\cygwin\bin on /usr/bin type system (textmode) C:\cygwin\lib on /usr/lib type system (textmode) C:\cygwin on / type system (textmode) c: on /cygdrive/c type system (textmode,noumount) h: on /cygdrive/h type system (textmode,noumount) i: on /cygdrive/i type system (textmode,noumount) r: on /cygdrive/r type system (textmode,noumount) s: on /cygdrive/s type system (textmode,noumount) u: on /cygdrive/u type system (textmode,noumount) C:\Tempod -c foo.sh 000 d a t e ; d a t e \r \n 014 C:\Tempod -t x1 foo.sh 000 64 61 74 65 3b 20 64 61 74 65 0d 0a 014 C:\Tempsh foo.sh Thu Sep 28 13:21:46 PDT 2006 Thu Sep 28 13:21:46 PDT 2006 C:\Tempsh c:/Temp/foo.sh Thu Sep 28 13:21:52 PDT 2006 : command not founde 1: date C:\Tempsh c:\Temp\foo.sh Thu Sep 28 13:21:58 PDT 2006 : command not founde 1: date C:\Tempsh /cygdrive/c/Temp/foo.sh Thu Sep 28 13:22:07 PDT 2006 Thu Sep 28 13:22:08 PDT 2006 C:\Tempbash foo.sh Thu Sep 28 13:22:12 PDT 2006 Thu Sep 28 13:22:12 PDT 2006 C:\Tempbash c:/Temp/foo.sh Thu Sep 28 13:22:17 PDT 2006 : command not founde 1: date C:\Tempbash c:\Temp\foo.sh Thu Sep 28 13:22:23 PDT 2006 : command not founde 1: date C:\Tempbash /cygdrive/c/Temp/foo.sh Thu Sep 28 13:22:36 PDT 2006 Thu Sep 28 13:22:36 PDT 2006 Ah, so POSIX paths do work. That makes sense, given your mounts. The moral to the story is that if you want text files to work transparently with your text mounts, use POSIX paths so the mount points and attributes are respected. Using DOS path notation bypasses the mount table so all bets are off. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 216 Dalton Rd. (508) 893-9889 - FAX Holliston, MA 01746 -- 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: Similar Bash 3.1.18 CR/LF Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 *There is NO bash 3.1.18* - just 3.1.17 release 8 According to Wilks, Dan on 9/28/2006 11:30 AM: Apologies that this is being written the day after without real output. I'm now at my desk without easy access to the machine in question. But... We've been using Cygwin with text-mode mounts for a long time without any problems. A new engineer started the other day, installed a brand-spanking-new cygwin and came to me with problems running a build. Without going into details of the build system, after a few hours I discovered that (all examples are from a cmd shell), foo.sh contains the single line date; datecrlf C: cd temp C:\temp sh foo.sh -- works C:\temp sh C:/temp/foo.sh - fails C:\temp sh C:\temp\foo.sh - fails The failures were of a form where the first command on a line works but the second generates an error. Sounds like the \r is being interpreted literally. Use POSIX paths, not Windows paths, if you want your mount point settings to be honored. Oh, and when we downloaded just bash 3.1.6(17?) it didn't overwrite the old sh. Get your versions right. That would be bash 3.1.17 release 6. The bash postinstall script is designed for upgrades only. If /bin/sh is newer in timestamp than the newly installed /bin/bash, no upgrade occurs. This is a feature. However, it makes downgrades a little awkward. To successfully downgrade, you need to manually 'cp /bin/bash.exe /bin/sh.exe'. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] volunteer cygwin bash maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFHIwE84KuGfSFAYARAv+kAJ9v/8vLVWzSPMIyVG8DNDIkj029kACg0/b5 2LYcIxc6xmZ08EpX0lg+T44= =UTDB -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Similar Bash 3.1.18 CR/LF Problem
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Wilks, Dan on 9/28/2006 3:59 PM: That was my guess. But since this was the cygwin installer run off of the cygwin site I thought I'd mention it, if for no other reason than tracking purposes. Maybe there's a problem with the installer / postinstall script when downgrading? Or perhaps that's intended behavior. It was just surprising. It's intended behavior; the postinstall script was not written with downgrades in mind (I may rethink that for my next release; but, it won't help you, because downgrading to 3.1-8 or earlier will not have this patch). And... it didn't run again when re-upgrading just bash to the new (broken) version so we had to manually copy bash.exe to sh.exe. What makes you think the current version is broken? In my opinion, it works just fine. However, your discovery that using Windows paths instead of POSIX paths makes cygwin revert to binary file opens on text mounts is rather interesting. I don't know if cygwin1.dll is at fault for that strange behavior. It may be possible for me to patch bash to always convert script names to POSIX before opening them, so that you would get the right mount behavior, but I'm not looking forward to such a hack. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] volunteer cygwin bash maintainer -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFHI2Y84KuGfSFAYARAjexAJ9uP5w9/+OaWfZdt5ld8WAJUe04tACgif8X 6dEv5L8ILFOuqmHLIm5RyBw= =HO9/ -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/
