* Re: zsh and line breaks [not found] ` <Pine.LNX.4.53.0403291441160.5939@gremlin.fruitbat.org> @ 2004-03-30 9:32 ` Oliver Kiddle 2004-03-30 18:54 ` Peter A. Castro 0 siblings, 1 reply; 33+ messages in thread From: Oliver Kiddle @ 2004-03-30 9:32 UTC (permalink / raw) To: Peter A. Castro; +Cc: zzapper, zsh-workers, cygwin "Peter A. Castro" wrote: > > I run zsh on Cygwin, unlike bash zsh gets very upset if it sees dos > > returns. I have to run dos2unix on my zsh scripts. > > > > I haven't seen an explanation for this > > Hmm... I'll have to look into this. I thought I'd corrected this for > Cygwin... Are those corrections likely to be limited to the Cygwin package for zsh? I don't use Cygwin myself but from a quick search, it looks like there is an O_TEXT flag to open which we could use (a couple of places in init.c would cover scripts I think). Wouldn't work where the script comes from stdin, though. Does that perhaps help? Oliver ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-03-30 9:32 ` zsh and line breaks Oliver Kiddle @ 2004-03-30 18:54 ` Peter A. Castro 2004-03-31 12:45 ` Oliver Kiddle 0 siblings, 1 reply; 33+ messages in thread From: Peter A. Castro @ 2004-03-30 18:54 UTC (permalink / raw) To: Oliver Kiddle; +Cc: zzapper, zsh-workers, cygwin On Tue, 30 Mar 2004, Oliver Kiddle wrote: > "Peter A. Castro" wrote: > > > I run zsh on Cygwin, unlike bash zsh gets very upset if it sees dos > > > returns. I have to run dos2unix on my zsh scripts. > > > > > > I haven't seen an explanation for this > > Hmm... I'll have to look into this. I thought I'd corrected this for > > Cygwin... > > Are those corrections likely to be limited to the Cygwin package for > zsh? Yes. Currently, my changes are Cygwin specific and really don't apply to the other platforms. > I don't use Cygwin myself but from a quick search, it looks like there > is an O_TEXT flag to open which we could use (a couple of places in > init.c would cover scripts I think). Wouldn't work where the script > comes from stdin, though. Does that perhaps help? I'm aware of O_TEXT and I thought I'd changed all of the places where files are opened already, but I just checked my patches and those changes are gone! AARRGGHH!! Ok, I'll re-edit and get that back in. Going through stdin or via piped fds may be an issue still. Anyway, thanks for the thought! > Oliver -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-03-30 18:54 ` Peter A. Castro @ 2004-03-31 12:45 ` Oliver Kiddle 2004-03-31 17:53 ` Peter A. Castro 0 siblings, 1 reply; 33+ messages in thread From: Oliver Kiddle @ 2004-03-31 12:45 UTC (permalink / raw) To: Peter A. Castro; +Cc: zzapper, zsh-workers, cygwin "Peter A. Castro" wrote: > > Are those corrections likely to be limited to the Cygwin package for > > zsh? > > Yes. Currently, my changes are Cygwin specific and really don't apply to > the other platforms. It is easy for us to add `#ifdef __CYGWIN__' around changes or #define O_TEXT to zero on other systems so if you do correct the problem, please send the changes back to us. > I'm aware of O_TEXT and I thought I'd changed all of the places where > files are opened already, but I just checked my patches and those changes > are gone! AARRGGHH!! Ok, I'll re-edit and get that back in. Going > through stdin or via piped fds may be an issue still. Anyway, thanks for > the thought! It seems there is a setmode() function declared in io.h which will allow the mode to be changed on any already open file descriptors. Oliver ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-03-31 12:45 ` Oliver Kiddle @ 2004-03-31 17:53 ` Peter A. Castro 2004-04-01 9:09 ` Oliver Kiddle 0 siblings, 1 reply; 33+ messages in thread From: Peter A. Castro @ 2004-03-31 17:53 UTC (permalink / raw) To: Oliver Kiddle; +Cc: zzapper, zsh-workers, cygwin On Wed, 31 Mar 2004, Oliver Kiddle wrote: > "Peter A. Castro" wrote: > > > Are those corrections likely to be limited to the Cygwin package for > > > zsh? > > > > Yes. Currently, my changes are Cygwin specific and really don't apply to > > the other platforms. > > It is easy for us to add `#ifdef __CYGWIN__' around changes or #define > O_TEXT to zero on other systems so if you do correct the problem, > please send the changes back to us. There are about 43 open() calls which I've updated with the O_TEXT option. Having all those ifdef's seemed rather ugly (makes the code hard to look at, expectially when they are within a few lines of each other) so I took a more "elegent" approach, though you may want to revise it if it doesn't meet your style requirements :) > > I'm aware of O_TEXT and I thought I'd changed all of the places where > > files are opened already, but I just checked my patches and those changes > > are gone! AARRGGHH!! Ok, I'll re-edit and get that back in. Going > > through stdin or via piped fds may be an issue still. Anyway, thanks for > > the thought! > > It seems there is a setmode() function declared in io.h which will > allow the mode to be changed on any already open file descriptors. Yep, I'm experimenting with this right now. As it stands, tests which print out to a file and then cat it back in (currently A04redirect and E01options) produce a diff, but don't otherwise seem to have any problems. > Oliver -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-03-31 17:53 ` Peter A. Castro @ 2004-04-01 9:09 ` Oliver Kiddle 2004-04-01 21:20 ` Peter A. Castro 0 siblings, 1 reply; 33+ messages in thread From: Oliver Kiddle @ 2004-04-01 9:09 UTC (permalink / raw) To: Peter A. Castro; +Cc: zzapper, zsh-workers, cygwin "Peter A. Castro" wrote: > > It is easy for us to add `#ifdef __CYGWIN__' around changes or #define > > O_TEXT to zero on other systems so if you do correct the problem, > > please send the changes back to us. > > There are about 43 open() calls which I've updated with the O_TEXT > option. Having all those ifdef's seemed rather ugly (makes the code hard > to look at, expectially when they are within a few lines of each other) > so I took a more "elegent" approach, though you may want to revise it if > it doesn't meet your style requirements :) I can believe that adding ifdef's to all is ugly. That's what I meant by "#define O_TEXT to zero on other systems" - just one thought on a possible more "elegant" approach. > Yep, I'm experimenting with this right now. As it stands, tests which > print out to a file and then cat it back in (currently A04redirect and > E01options) produce a diff, but don't otherwise seem to have any > problems. Are the diffs just the line endings? From what I understand, the reported problems were with text files used as input to the shell (i.e. scripts, sourced files, autoloaded functions and stdin). Quite whether it is also right for redirected output, I wouldn't know. Oliver ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-01 9:09 ` Oliver Kiddle @ 2004-04-01 21:20 ` Peter A. Castro 2004-04-02 9:49 ` Dave Korn 2004-04-03 1:23 ` Peter A. Castro 0 siblings, 2 replies; 33+ messages in thread From: Peter A. Castro @ 2004-04-01 21:20 UTC (permalink / raw) To: Oliver Kiddle; +Cc: zsh-workers, cygwin On Thu, 1 Apr 2004, Oliver Kiddle wrote: Warning: this is long!! > "Peter A. Castro" wrote: > > > It is easy for us to add `#ifdef __CYGWIN__' around changes or #define > > > O_TEXT to zero on other systems so if you do correct the problem, > > > please send the changes back to us. > > > > There are about 43 open() calls which I've updated with the O_TEXT > > option. Having all those ifdef's seemed rather ugly (makes the code hard > > to look at, expectially when they are within a few lines of each other) > > so I took a more "elegent" approach, though you may want to revise it if > > it doesn't meet your style requirements :) > > I can believe that adding ifdef's to all is ugly. That's what I meant > by "#define O_TEXT to zero on other systems" - just one thought on a > possible more "elegant" approach. I might as well describe what I've done so you can give it a thumbs up or down. In system.h I've added a #define in the #ifdef __CYGWIN__ section of: #define ORO_TEXT | O_TEXT And for the #else case: #define ORO_TEXT Then in code which needs it I have modified it to look like this: if ((fd = open(name, O_RDONLY ORO_TEXT)) < 0) { It's really just utilizing the macro ability of the compiler, and it's a style judgement call. I don't have a problem with it, obviously, but others might look at it and wonder how it could possible compile if they didn't look in system.h first. If you think that might present confusion, then I'll change it to be explicitly "| OR_TEXT" and have #define O_TEXT to be 0 if not defined at all. Any thoughts on this? > > Yep, I'm experimenting with this right now. As it stands, tests which > > print out to a file and then cat it back in (currently A04redirect and > > E01options) produce a diff, but don't otherwise seem to have any > > problems. > > Are the diffs just the line endings? From what I understand, the > reported problems were with text files used as input to the shell (i.e. > scripts, sourced files, autoloaded functions and stdin). Quite whether > it is also right for redirected output, I wouldn't know. The primary problem is with running scripts with CR/LFs. That gets fixed with adding O_TEXT everywhere. A secondary problem is with redirected input and/or output which is processed by the shell. I've been reviewing this problem and I think maybe I've been attacking it incorrectly. I had though that adding O_TEXT everywhere would solve this problem. However, the environment is complicating things :) Here's the deal: Cygwin can "mount" a part of the native Windows filesystem into the virtual Cygwin filesystem with an attribute of textmode or binmode. The meaning of this is on textmode mounts, files opened as "text files" (ie: not as a binary file), will have CR/LF translation performed on them (ie: reads will remove CR and writes will write CR/LF). On binmode mounts, files opened as "text files" will retain their line terminators, so no translation is performed on either reads or writes. So where the file located in the filesystem determines the default handling of translation when opened as a text file. This is for normal unix style coding of opens without any O_TEXT or O_BINARY cruft. Now, adding an explicit O_TEXT or O_BINARY forces one mode or the other, ignoring the filesystem mount attributes. The problem is, I don't want to force the mode, at least not on writes. See, if the user has his files on a textmode mounted filesystem, he'll be expecting files written to it to have CR/LFs. If his files are on a binmode mounted filesystem, he'll be expecting files written to not have any CRs. But, zsh, internally, can't handle CRs (unless I hack the parser...no, don't want to do that!), so I need to ensure that all opened files for read are forced via O_TEXT (ie: strip off CRs), while allowing opened files for write to default to the filesystem mode. The trouble is, there are several places in the code where files are opened as Read/Write! This gets more complicated when, say, a user opens normal scripts/files on a binmode mount, but /tmp (the place zsh makes temp files) is mounted in textmode! I need to analyse the code a little more to determine just what the RW files that zsh opens are used for. If it's purely internal usage and never provide as input or output to external programs via pipes or redirection, then I can make it O_BINARY and that should solve things. But, if not... well... I'm not sure how to handle it (yet)... First the analyse. I'd remember going through this same exercise a while back with 4.0 of Zsh, and remember that I had the same issues and decided it would be better to simply tell people to keep their mounts consistent with their data files. Now, however, I really want to fix this to work correctly. Thanks for listening. Any suggestions are welcome. > Oliver -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: zsh and line breaks 2004-04-01 21:20 ` Peter A. Castro @ 2004-04-02 9:49 ` Dave Korn 2004-04-02 16:59 ` Peter A. Castro 2004-04-03 1:23 ` Peter A. Castro 1 sibling, 1 reply; 33+ messages in thread From: Dave Korn @ 2004-04-02 9:49 UTC (permalink / raw) To: zsh-workers, cygwin > -----Original Message----- > From: cygwin-owner On Behalf Of Peter A. Castro > Sent: 01 April 2004 22:21 > In system.h I've added a #define in the #ifdef > __CYGWIN__ section of: > #define ORO_TEXT | O_TEXT > And for the #else case: > #define ORO_TEXT > > Then in code which needs it I have modified it to look like this: > > if ((fd = open(name, O_RDONLY ORO_TEXT)) < 0) { > > It's really just utilizing the macro ability of the compiler, > and it's a > style judgement call. I don't have a problem with it, obviously, but > others might look at it and wonder how it could possible > compile if they > didn't look in system.h first. If you think that might present > confusion, then I'll change it to be explicitly "| OR_TEXT" and have > #define O_TEXT to be 0 if not defined at all. > > Any thoughts on this? It's pretty reasonable but as you say could be confusing. Here's another approach that might seem nicer because it's kind of function-like: #ifdef __CYGWIN__ #define MAYBE_ADD_O_TEXT_FLAG(x) (O_TEXT | (x)) #else #define MAYBE_ADD_O_TEXT_FLAG(x) (x) #endif Then say if ((fd = open(name, MAYBE_ADD_O_TEXT_FLAG(O_RDONLY))) < 0) { You might well want to choose a better name for the function-like macro than that, but I think the pattern is slightly clearer. > The primary problem is with running scripts with CR/LFs. > That gets fixed > with adding O_TEXT everywhere. A secondary problem is with redirected > input and/or output which is processed by the shell. > > I've been reviewing this problem and I think maybe I've been > attacking it > incorrectly. I had though that adding O_TEXT everywhere > would solve this > problem. However, the environment is complicating things :) > > Here's the deal: > So where the file located in the filesystem > determines > the default handling of translation when opened as a text file. > This is for normal unix style coding of opens without any O_TEXT or > O_BINARY cruft. > > Now, adding an explicit O_TEXT or O_BINARY forces one mode or > the other, > ignoring the filesystem mount attributes. The problem is, I > don't want > to force the mode, > > Thanks for listening. Any suggestions are welcome. Doesn't the POSIX standard specify something about shells should open stdin, stdout and stderr in textmode? IOW, aren't you obliged to force the mode? cheers, DaveK -- Can't think of a witty .sigline today.... ^ permalink raw reply [flat|nested] 33+ messages in thread
* RE: zsh and line breaks 2004-04-02 9:49 ` Dave Korn @ 2004-04-02 16:59 ` Peter A. Castro 0 siblings, 0 replies; 33+ messages in thread From: Peter A. Castro @ 2004-04-02 16:59 UTC (permalink / raw) To: Dave Korn; +Cc: zsh-workers, cygwin On Fri, 2 Apr 2004, Dave Korn wrote: Hi Dave, > > -----Original Message----- > > From: cygwin-owner On Behalf Of Peter A. Castro > > Sent: 01 April 2004 22:21 > > > In system.h I've added a #define in the #ifdef > > __CYGWIN__ section of: > > #define ORO_TEXT | O_TEXT > > And for the #else case: > > #define ORO_TEXT > > > > Then in code which needs it I have modified it to look like this: > > > > if ((fd = open(name, O_RDONLY ORO_TEXT)) < 0) { > > > > It's really just utilizing the macro ability of the compiler, > > and it's a > > style judgement call. I don't have a problem with it, obviously, but > > others might look at it and wonder how it could possible > > compile if they > > didn't look in system.h first. If you think that might present > > confusion, then I'll change it to be explicitly "| OR_TEXT" and have > > #define O_TEXT to be 0 if not defined at all. > > > > Any thoughts on this? > > It's pretty reasonable but as you say could be confusing. Here's another > approach that might seem nicer because it's kind of function-like: > > #ifdef __CYGWIN__ > #define MAYBE_ADD_O_TEXT_FLAG(x) (O_TEXT | (x)) > #else > #define MAYBE_ADD_O_TEXT_FLAG(x) (x) > #endif > > Then say > > if ((fd = open(name, MAYBE_ADD_O_TEXT_FLAG(O_RDONLY))) < 0) { > > You might well want to choose a better name for the function-like macro than > that, but I think the pattern is slightly clearer. It's always interesting to see how people solve the same problem using a different style. Yes, I'd though of using a wrapper macro, but decided I didn't want to change mainline code that much. I'm really looking for something that's pretty non-intrusive. Corinna just emailed a possible solution, which may be the best yet because it works at a lower level and wouldn't require all of those 43 open calls to be changed! > > The primary problem is with running scripts with CR/LFs. > > That gets fixed > > with adding O_TEXT everywhere. A secondary problem is with redirected > > input and/or output which is processed by the shell. > > > > I've been reviewing this problem and I think maybe I've been > > attacking it > > incorrectly. I had though that adding O_TEXT everywhere > > would solve this > > problem. However, the environment is complicating things :) > > > > Here's the deal: > > > So where the file located in the filesystem > > determines > > the default handling of translation when opened as a text file. > > This is for normal unix style coding of opens without any O_TEXT or > > O_BINARY cruft. > > > > Now, adding an explicit O_TEXT or O_BINARY forces one mode or > > the other, > > ignoring the filesystem mount attributes. The problem is, I > > don't want > > to force the mode, > > > > Thanks for listening. Any suggestions are welcome. > > Doesn't the POSIX standard specify something about shells should open > stdin, stdout and stderr in textmode? IOW, aren't you obliged to force the > mode? The posix standard specifies a textmode should be used, but says nothing about what really constitues a "textmode". Textmode means adding line termination according to the platform definitions. However, in the case of Cygwin, I believe we are supposed to honor the mode of the filesystem as much as possible, which means sometimes line termination has CRs and sometimes it doesn't. One thing is for sure: reading script files directly must remove CRs. Everthing else is up for discussion :) I'm going to experiment with Corinna's idea and see what happens first. If that doesn't work, I'll have to continue my analysis of what the code does with those opened files. > cheers, > DaveK -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-01 21:20 ` Peter A. Castro 2004-04-02 9:49 ` Dave Korn @ 2004-04-03 1:23 ` Peter A. Castro 2004-04-03 20:35 ` Bart Schaefer 1 sibling, 1 reply; 33+ messages in thread From: Peter A. Castro @ 2004-04-03 1:23 UTC (permalink / raw) To: Oliver Kiddle; +Cc: zsh-workers, cygwin On Thu, 1 Apr 2004, Peter A. Castro wrote: > On Thu, 1 Apr 2004, Oliver Kiddle wrote: > > Warning: this is long!! Well, this time it's short!! :) > > "Peter A. Castro" wrote: > > > > It is easy for us to add `#ifdef __CYGWIN__' around changes or #define > > > > O_TEXT to zero on other systems so if you do correct the problem, > > > > please send the changes back to us. > > > > > > There are about 43 open() calls which I've updated with the O_TEXT > > > option. Having all those ifdef's seemed rather ugly (makes the code hard > > > to look at, expectially when they are within a few lines of each other) > > > so I took a more "elegent" approach, though you may want to revise it if > > > it doesn't meet your style requirements :) > > > > I can believe that adding ifdef's to all is ugly. That's what I meant > > by "#define O_TEXT to zero on other systems" - just one thought on a > > possible more "elegant" approach. Ok, forget about adding O_TEXT to the open() calls. It's not necessary. Thanks to Corinna from the Cygwin list, I have a better solution. It's very Cygwin specific, but very inobtrusive to the mainline code which is something I really like about this fix. I've tested it using both binmode and textmode mounted filesystems and it passes the Test suite with flying colors! So, now I need a ruling on just where to put this fix. Due to how the fix works, it can't be placed in DLL code. It must be linked into the main exe. Now, I know that main.c is basically just a platform wrapper for calling zsh_main(). My question is, to the zsh developers, would it be acceptable to put code into main.c or should I persue adding a seperate source file which will have to be part of MAIN_OBJS. I know I'll have to hack zsh.mdd to add it as a dependency and get the various prototype files created correctly, but I'm willing to do that. But, do I really need to make it a separate source file or can I add it to main? The fix consists of a special Cygwin function which is coded and linked into the main. The function, itself, is very small and basically is a hook in Cygwin to allow various internal variables to be set before the program main gets control. My version sets textmode related things for file I/O. So, again, this is a style/placement question. Put it in main.c or make it a separate source file (which will only be used by the Cygwin port or possible can be a place for other ports to put such code)? > Thanks for listening. Any suggestions are welcome. > > Oliver -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-03 1:23 ` Peter A. Castro @ 2004-04-03 20:35 ` Bart Schaefer 2004-04-04 19:29 ` Peter Stephenson 0 siblings, 1 reply; 33+ messages in thread From: Bart Schaefer @ 2004-04-03 20:35 UTC (permalink / raw) To: zsh-workers On Apr 2, 5:23pm, Peter A. Castro wrote: } } On Thu, 1 Apr 2004, Peter A. Castro wrote: } } So, now I need a ruling on just where to put this fix. Due to how the } fix works, it can't be placed in DLL code. It must be linked into the } main exe. Now, I know that main.c is basically just a platform wrapper } for calling zsh_main(). My question is, to the zsh developers, would it } be acceptable to put code into main.c or should I persue adding a } seperate source file which will have to be part of MAIN_OBJS. I don't know that I can give you a "ruling" but in my opinion it would be fine to put this in main.c, appropriately #ifdef'd. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-03 20:35 ` Bart Schaefer @ 2004-04-04 19:29 ` Peter Stephenson 2004-04-05 16:19 ` Peter A. Castro 0 siblings, 1 reply; 33+ messages in thread From: Peter Stephenson @ 2004-04-04 19:29 UTC (permalink / raw) To: zsh-workers, cygwin Bart Schaefer wrote: > On Apr 2, 5:23pm, Peter A. Castro wrote: > } > } On Thu, 1 Apr 2004, Peter A. Castro wrote: > } > } So, now I need a ruling on just where to put this fix. > > I don't know that I can give you a "ruling" but in my opinion it would be > fine to put this in main.c, appropriately #ifdef'd. I agree, there's nothing magic about main.c. The only reason it's short is because usually it's convenient for as much stuff as possible to be in zsh.dll, on systems where that needs to exist. Your case is exactly the opposite, so main.c is fine. -- Peter Stephenson <pws@pwstephenson.fsnet.co.uk> Work: pws@csr.com Web: http://www.pwstephenson.fsnet.co.uk ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-04 19:29 ` Peter Stephenson @ 2004-04-05 16:19 ` Peter A. Castro 2004-04-05 17:40 ` Peter Stephenson 0 siblings, 1 reply; 33+ messages in thread From: Peter A. Castro @ 2004-04-05 16:19 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-workers On Sun, 4 Apr 2004, Peter Stephenson wrote: > Bart Schaefer wrote: > > On Apr 2, 5:23pm, Peter A. Castro wrote: > > } > > } On Thu, 1 Apr 2004, Peter A. Castro wrote: > > } > > } So, now I need a ruling on just where to put this fix. > > > > I don't know that I can give you a "ruling" but in my opinion it would be > > fine to put this in main.c, appropriately #ifdef'd. > > I agree, there's nothing magic about main.c. The only reason it's short > is because usually it's convenient for as much stuff as possible to be > in zsh.dll, on systems where that needs to exist. Your case is exactly > the opposite, so main.c is fine. Excellent! Ok, that's decided. So, how/where do I submit code changes? -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-05 16:19 ` Peter A. Castro @ 2004-04-05 17:40 ` Peter Stephenson 2004-04-05 22:08 ` Peter A. Castro 0 siblings, 1 reply; 33+ messages in thread From: Peter Stephenson @ 2004-04-05 17:40 UTC (permalink / raw) To: Peter A. Castro; +Cc: zsh-workers "Peter A. Castro" wrote: > Excellent! Ok, that's decided. So, how/where do I submit code changes? Submit the context diffs or unidiffs to the list. If you're going to be doing this a lot and would like access to the CVS archive at Sourceforge, mail me with your Sourceforge user name. pws ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-05 17:40 ` Peter Stephenson @ 2004-04-05 22:08 ` Peter A. Castro 2004-04-05 23:08 ` Clint Adams ` (3 more replies) 0 siblings, 4 replies; 33+ messages in thread From: Peter A. Castro @ 2004-04-05 22:08 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: TEXT/PLAIN, Size: 1100 bytes --] On Mon, 5 Apr 2004, Peter Stephenson wrote: > "Peter A. Castro" wrote: > > Excellent! Ok, that's decided. So, how/where do I submit code changes? > > Submit the context diffs or unidiffs to the list. If you're going to be > doing this a lot and would like access to the CVS archive at > Sourceforge, mail me with your Sourceforge user name. Ok, see attached diff of the following files. These are primarily Cygwin specific fixes, but some could be considdered generic: Doc/Makefile.in - A little correction to the texi2html command args and a fix to the install.html target to use sdir. Src/builtin.c - Prevent from constructing "//path". Src/exec.c - change read to use actual length instead of stat'd length. Src/main.c - added Cygwin premain hook to deal with Text related I/O. Src/system.h - add #include of <sys/cygwin.h>. configure - change DLLD & DLLDFLAGS to not use dllwrap configure.ac - change DLLD & DLLDFLAGS to not use dllwrap -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood [-- Attachment #2: zsh420cygwin.patch --] [-- Type: TEXT/PLAIN, Size: 7281 bytes --] diff -urN -x .build -x .inst -x .sinst zsh-4.2.0-orig/Doc/Makefile.in zsh-4.2.0/Doc/Makefile.in --- zsh-4.2.0-orig/Doc/Makefile.in 2003-10-25 10:38:19.000000000 -0700 +++ zsh-4.2.0/Doc/Makefile.in 2004-04-05 12:17:29.724238400 -0700 @@ -40,7 +40,7 @@ MAKEINFO = makeinfo TEXI2DVI = texi2dvi DVIPS = dvips -TEXI2HTML = texi2html -expand info -split chapter +TEXI2HTML = texi2html -expandinfo -split_chapter .SUFFIXES: .yo .1 @@ -303,7 +303,7 @@ # install HTML manual install.html: html ${SHELL} $(sdir_top)/mkinstalldirs $(DESTDIR)$(htmldir) - for file in zsh*.html; do \ + for file in ${sdir}/zsh*.html; do \ $(INSTALL_DATA) $$file $(DESTDIR)$(htmldir) || exit 1; \ done .PHONY: install.html diff -urN -x .build -x .inst -x .sinst zsh-4.2.0-orig/Src/builtin.c zsh-4.2.0/Src/builtin.c --- zsh-4.2.0-orig/Src/builtin.c 2004-03-18 03:31:40.000000000 -0800 +++ zsh-4.2.0/Src/builtin.c 2004-04-05 12:17:30.014656000 -0700 @@ -927,7 +927,9 @@ * DOS style names with drives in them */ static char buf[PATH_MAX]; +#ifndef _SYS_CYGWIN_H void cygwin_conv_to_posix_path(const char *, char *); +#endif cygwin_conv_to_posix_path(dest, buf); dest = buf; @@ -1031,7 +1033,15 @@ /* handle directory prefix */ if (pfix && *pfix) { if (*pfix == '/') +#ifdef __CYGWIN__ +/* NB: Don't turn "/"+"bin" into "//"+"bin" by mistake! "//bin" may * + * not be what user really wants (probably wants "/bin"), but * + * "//bin" could be valid too (see fixdir())! This is primarily for * + * handling CDPATH correctly. */ + buf = tricat(pfix, ( pfix[1] == '\0' ? "" : "/" ), dest); +#else buf = tricat(pfix, "/", dest); +#endif else { int pfl = strlen(pfix); dlen = strlen(pwd); diff -urN -x .build -x .inst -x .sinst zsh-4.2.0-orig/Src/exec.c zsh-4.2.0/Src/exec.c --- zsh-4.2.0-orig/Src/exec.c 2004-03-18 03:48:42.000000000 -0800 +++ zsh-4.2.0/Src/exec.c 2004-04-05 12:17:30.204929600 -0700 @@ -3662,6 +3662,7 @@ { char **pp, buf[PATH_MAX]; off_t len; + off_t rlen; char *d; Eprog r; int fd; @@ -3681,12 +3682,12 @@ if ((len = lseek(fd, 0, 2)) != -1) { d = (char *) zalloc(len + 1); lseek(fd, 0, 0); - if (read(fd, d, len) == len) { + if ((rlen = read(fd, d, len)) >= 0) { char *oldscriptname = scriptname; close(fd); - d[len] = '\0'; - d = metafy(d, len, META_REALLOC); + d[rlen] = '\0'; + d = metafy(d, rlen, META_REALLOC); scriptname = dupstring(s); r = parse_string(d); diff -urN -x .build -x .inst -x .sinst zsh-4.2.0-orig/Src/main.c zsh-4.2.0/Src/main.c --- zsh-4.2.0-orig/Src/main.c 2000-08-02 11:01:51.000000000 -0700 +++ zsh-4.2.0/Src/main.c 2004-04-05 12:17:30.445275200 -0700 @@ -30,6 +30,62 @@ #include "zsh.mdh" #include "main.pro" +/* + * Support for Cygwin binary/text mode filesystems. + * Peter A. Castro <doctor@fruitbat.org> + * + * This deserves some explaination, because it uses Cygwin specific + * runtime functions. + * + * Cygwin supports the notion of binary or text mode access to files + * based on the mount attributes of the filesystem. If a file is on + * a binary mounted filesystem, you get exactly what's in the file, CRLF's + * and all. If it's on a text mounted filesystem, Cygwin will strip out + * the CRs. This presents a problem because zsh code doesn't allow for + * CRLF's as line terminators. So, we must force all open files to be + * in text mode reguardless of the underlying filesystem attributes. + * However, we only want to do this for reading, not writing as we still + * want to write files in the mode of the filesystem. To do this, + * we have two options: augment all {f}open() calls to have O_TEXT added to + * the list of file mode options, or have the Cygwin runtime do it for us. + * I choose the latter. :) + * + * Cygwin's runtime provides pre-execution hooks which allow you to set + * various attributes for the process which effect how the process functions. + * One of these attributes controls how files are opened. I've set + * it up so that all files opened RDONLY will have the O_TEXT option set, + * thus forcing line termination manipulation. This seems to solve the + * problem (at least the Test suite runs clean :). + * + * Note: this may not work in later implementations. This will override + * all mode options passed into open(). Cygwin (really Windows) doesn't + * support all that much in options, so for now this is OK, but later on + * it may not, in which case O_TEXT will have to be added to all opens calls + * appropriately. + * + * This function is actually a hook in the Cygwin runtime which + * is called before the main of a program. Because it's part of the program + * pre-startup, it must be located in the program main and not in a DLL. + * It must also be made an export so the linker resolves this function to + * our code instead of the default Cygwin stub routine. + */ + +/**/ +#ifdef __CYGWIN__ +/**/ +mod_export void +cygwin_premain0 (int argc, char **argv, void *myself) +{ + static struct __cygwin_perfile pf[] = + { + {"", O_RDONLY | O_TEXT}, + {NULL, 0} + }; + cygwin_internal (CW_PERFILE, pf); +} +/**/ +#endif /* __CYGWIN__ */ + /**/ int main(int argc, char **argv) diff -urN -x .build -x .inst -x .sinst zsh-4.2.0-orig/Src/system.h zsh-4.2.0/Src/system.h --- zsh-4.2.0-orig/Src/system.h 2004-02-24 05:02:12.000000000 -0800 +++ zsh-4.2.0/Src/system.h 2004-04-05 12:17:30.655577600 -0700 @@ -675,6 +675,7 @@ #endif #ifdef __CYGWIN__ +# include <sys/cygwin.h> # define IS_DIRSEP(c) ((c) == '/' || (c) == '\\') #else # define IS_DIRSEP(c) ((c) == '/') diff -urN -x .build -x .inst -x .sinst zsh-4.2.0-orig/configure zsh-4.2.0/configure --- zsh-4.2.0-orig/configure 2004-03-15 11:10:03.000000000 -0800 +++ zsh-4.2.0/configure 2004-04-05 12:17:31.016096000 -0700 @@ -13547,8 +13547,10 @@ zsh_cv_shared_environ="${zsh_cv_shared_environ=yes}" elif test "$host_os" = cygwin; then DL_EXT="${DL_EXT=dll}" - DLLD="${DLLD=dllwrap}" - DLLDFLAGS="${DLLDFLAGS=--export-all-symbols}" +##DLLD="${DLLD=dllwrap}" + DLLD="${DLLD=$CC}" +##DLLDFLAGS="${DLLDFLAGS=--export-all-symbols}" + DLLDFLAGS=${DLLDFLAGS=-shared -Wl,--export-all-symbols} zsh_cv_func_dlsym_needs_underscore=no DLLDFLAGS=${DLLDFLAGS=} EXTRA_LDFLAGS=${EXTRA_LDFLAGS=} diff -urN -x .build -x .inst -x .sinst zsh-4.2.0-orig/configure.ac zsh-4.2.0/configure.ac --- zsh-4.2.0-orig/configure.ac 2004-03-15 11:08:25.000000000 -0800 +++ zsh-4.2.0/configure.ac 2004-04-05 12:17:31.226398400 -0700 @@ -1934,8 +1934,10 @@ zsh_cv_shared_environ="${zsh_cv_shared_environ=yes}" elif test "$host_os" = cygwin; then DL_EXT="${DL_EXT=dll}" - DLLD="${DLLD=dllwrap}" - DLLDFLAGS="${DLLDFLAGS=--export-all-symbols}" +##DLLD="${DLLD=dllwrap}" + DLLD="${DLLD=$CC}" +##DLLDFLAGS="${DLLDFLAGS=--export-all-symbols}" + DLLDFLAGS=${DLLDFLAGS=-shared -Wl,--export-all-symbols} zsh_cv_func_dlsym_needs_underscore=no DLLDFLAGS=${DLLDFLAGS=} EXTRA_LDFLAGS=${EXTRA_LDFLAGS=} ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-05 22:08 ` Peter A. Castro @ 2004-04-05 23:08 ` Clint Adams 2004-04-05 23:25 ` Peter A. Castro 2004-04-06 9:43 ` Peter Stephenson ` (2 subsequent siblings) 3 siblings, 1 reply; 33+ messages in thread From: Clint Adams @ 2004-04-05 23:08 UTC (permalink / raw) To: Peter A. Castro; +Cc: zsh-workers > -TEXI2HTML = texi2html -expand info -split chapter > +TEXI2HTML = texi2html -expandinfo -split_chapter Don't do that; -expandinfo was obsoleted nearly 4 years ago. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-05 23:08 ` Clint Adams @ 2004-04-05 23:25 ` Peter A. Castro 2004-04-07 21:10 ` Clint Adams 0 siblings, 1 reply; 33+ messages in thread From: Peter A. Castro @ 2004-04-05 23:25 UTC (permalink / raw) To: zsh-workers On Mon, 5 Apr 2004, Clint Adams wrote: > > -TEXI2HTML = texi2html -expand info -split chapter > > +TEXI2HTML = texi2html -expandinfo -split_chapter > > Don't do that; -expandinfo was obsoleted nearly 4 years ago. Maybe so, but that's the only form which works for the Cygwin version of texi2html :/ Ok, so remove that change. I'll maintain my Cygwin specific port of that change separately. But, please consider the other change (sdir related). -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-05 23:25 ` Peter A. Castro @ 2004-04-07 21:10 ` Clint Adams 2004-04-08 1:16 ` Peter A. Castro 0 siblings, 1 reply; 33+ messages in thread From: Clint Adams @ 2004-04-07 21:10 UTC (permalink / raw) To: Peter A. Castro; +Cc: zsh-workers > Maybe so, but that's the only form which works for the Cygwin version of > texi2html :/ Cygwin might want to upgrade. texi2html is switching to GNU-style long options (e.g. --expand) too. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-07 21:10 ` Clint Adams @ 2004-04-08 1:16 ` Peter A. Castro 2004-04-09 5:00 ` Felix Rosencrantz 0 siblings, 1 reply; 33+ messages in thread From: Peter A. Castro @ 2004-04-08 1:16 UTC (permalink / raw) To: zsh-workers; +Cc: cygwin On Wed, 7 Apr 2004, Clint Adams wrote: > > Maybe so, but that's the only form which works for the Cygwin version of > > texi2html :/ > > Cygwin might want to upgrade. texi2html is switching to GNU-style long > options (e.g. --expand) too. "That's not my department" said Wernher Von Braun :-} Seriously, I'm not the maintainer for that (tetex), but I'll suggest it. -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-08 1:16 ` Peter A. Castro @ 2004-04-09 5:00 ` Felix Rosencrantz 2004-04-09 16:26 ` Peter A. Castro 0 siblings, 1 reply; 33+ messages in thread From: Felix Rosencrantz @ 2004-04-09 5:00 UTC (permalink / raw) To: Peter A. Castro, zsh-workers It would be great if the cygwin version of zsh could be built straight out of the zsh cvs repository. (Or at least with minimal patching.) Are there any additional resources in the cygwin port that are not included in the cvs tree? I know of at least one script, mkzsh, that is missing from cvs. -FR. __________________________________ Do you Yahoo!? Yahoo! Small Business $15K Web Design Giveaway http://promotions.yahoo.com/design_giveaway/ ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-09 5:00 ` Felix Rosencrantz @ 2004-04-09 16:26 ` Peter A. Castro 0 siblings, 0 replies; 33+ messages in thread From: Peter A. Castro @ 2004-04-09 16:26 UTC (permalink / raw) To: Felix Rosencrantz; +Cc: zsh-workers On Thu, 8 Apr 2004, Felix Rosencrantz wrote: Hi Felix, > It would be great if the cygwin version of zsh could be built straight out of > the zsh cvs repository. (Or at least with minimal patching.) Yes, it would still have to have some patching, but it would be minor now that my more significant code changes have been accepted into source. > Are there any additional resources in the cygwin port that are not > included in the cvs tree? I know of at least one script, mkzsh, that is > missing from cvs. Hmmm... I have thought about doing this, but time and resources are an issue right now. In a few more weeks, I hope to have had some hardware reconfiguration done and be in a better position to actually do this in an automated fashion. But, for the moment, I can't really accommodate you. Sorry. Reguarding scripts... mkzsh was just something I literally threw together on a sunday afternoon, along with a few Cygwin command completion scripts. They are only intended for Cygwin and unuseful for other platforms, so I have not deemed them worth enough to submit to source and maintain them separately, like I maintain the Cygwin build script. I see you've contributed (much improved) versions of some of those completion scripts, and I encourage you to continue in that vein. If you feel they should be contributed... well... convince me why they should. :) > -FR. -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-05 22:08 ` Peter A. Castro 2004-04-05 23:08 ` Clint Adams @ 2004-04-06 9:43 ` Peter Stephenson 2004-04-06 22:25 ` Peter A. Castro 2004-04-15 5:03 ` Clint Adams 2005-01-31 5:07 ` Patch for 4.2.3 building on Cygwin Peter A. Castro 3 siblings, 1 reply; 33+ messages in thread From: Peter Stephenson @ 2004-04-06 9:43 UTC (permalink / raw) To: zsh-workers "Peter A. Castro" wrote: > Ok, see attached diff of the following files. These are primarily Cygwin > specific fixes, but some could be considdered generic: > > Doc/Makefile.in - A little correction to the texi2html command > args and a fix to the install.html target to use sdir. > Src/builtin.c - Prevent from constructing "//path". > Src/exec.c - change read to use actual length instead of stat'd length. > Src/main.c - added Cygwin premain hook to deal with Text related I/O. > Src/system.h - add #include of <sys/cygwin.h>. > configure - change DLLD & DLLDFLAGS to not use dllwrap > configure.ac - change DLLD & DLLDFLAGS to not use dllwrap Thanks, I've committed this apart from the texi2html hunk. It's possible opening all files in text mode will cause problems elsewhere, e.g. on file descriptors passed to external programmes, but the text/binary problem is inescapable; we probably need to wait and see. We can always invent grotesqueries like <#myfile.bin if it becomes necessary. -- Peter Stephenson <pws@csr.com> Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-06 9:43 ` Peter Stephenson @ 2004-04-06 22:25 ` Peter A. Castro 0 siblings, 0 replies; 33+ messages in thread From: Peter A. Castro @ 2004-04-06 22:25 UTC (permalink / raw) To: zsh-workers On Tue, 6 Apr 2004, Peter Stephenson wrote: > "Peter A. Castro" wrote: > > Ok, see attached diff of the following files. These are primarily Cygwin > > specific fixes, but some could be considdered generic: > > > > Doc/Makefile.in - A little correction to the texi2html command > > args and a fix to the install.html target to use sdir. > > Src/builtin.c - Prevent from constructing "//path". > > Src/exec.c - change read to use actual length instead of stat'd length. > > Src/main.c - added Cygwin premain hook to deal with Text related I/O. > > Src/system.h - add #include of <sys/cygwin.h>. > > configure - change DLLD & DLLDFLAGS to not use dllwrap > > configure.ac - change DLLD & DLLDFLAGS to not use dllwrap > > Thanks, I've committed this apart from the texi2html hunk. Thanks, Peter :) > It's possible opening all files in text mode will cause problems > elsewhere, e.g. on file descriptors passed to external programmes, but > the text/binary problem is inescapable; we probably need to wait and > see. We can always invent grotesqueries like <#myfile.bin if it becomes > necessary. If it's any consolation, only files which are opened only as O_RDONLY are massaged to be opened with the special O_TEXT attribute. All O_WRONLY and O_RDWR are left alone, which I hope, will produce the correct semantic. Since shells are primarily dealing with textual data I feel this is a sufficient trade-off. I will, of course, be following this issue and report if there are any problems (which I'll probably have to fix, since I opened this can'o'worms myself :) But, as you say, time will tell. -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-05 22:08 ` Peter A. Castro 2004-04-05 23:08 ` Clint Adams 2004-04-06 9:43 ` Peter Stephenson @ 2004-04-15 5:03 ` Clint Adams 2004-04-15 6:43 ` Peter A. Castro 2005-01-31 5:07 ` Patch for 4.2.3 building on Cygwin Peter A. Castro 3 siblings, 1 reply; 33+ messages in thread From: Clint Adams @ 2004-04-15 5:03 UTC (permalink / raw) To: Peter A. Castro; +Cc: zsh-workers > args and a fix to the install.html target to use sdir. Wait, why are you doing this? It breaks the install target completely for VPATH builds. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-15 5:03 ` Clint Adams @ 2004-04-15 6:43 ` Peter A. Castro 2004-04-15 10:35 ` Clint Adams 0 siblings, 1 reply; 33+ messages in thread From: Peter A. Castro @ 2004-04-15 6:43 UTC (permalink / raw) To: Clint Adams; +Cc: zsh-workers On Thu, 15 Apr 2004, Clint Adams wrote: Greetings Clint, > > args and a fix to the install.html target to use sdir. > > Wait, why are you doing this? It breaks the install target completely > for VPATH builds. I fail to see how. Make may be able to resolve the source and target files implicitly from VPATH, reguardless of the current directory at the time, but the shell code it executes for commands does not use VPATH and breaks when run from a build directory which is not the same as the source directory. Here's the diff lines from Doc/Makefile.in: install.html: html ${SHELL} $(sdir_top)/mkinstalldirs $(DESTDIR)$(htmldir) - for file in zsh*.html; do \ + for file in ${sdir}/zsh*.html; do \ $(INSTALL_DATA) $$file $(DESTDIR)$(htmldir) || exit 1; \ done The use of the shell wildcard (zsh*.html) makes the shell do a pattern match against the list of files in the directory in which it is run. If I was building from a work directory (say zsh-4.2.0/.build/Doc) and installing into a destination root other that "/" (say zsh-4.2.0/.inst) make executes this bit of shell code and it fails to find any zsh*.html files because make isn't currently in that directory (it's in .build/Doc). Prepending ${sdir} ensures the zsh*.html files are addressable to the shell code. Another solution would be to have a static list, like the list of man pages in the MAN macro, but even then, the shell code references the files using $(sdir). So how, exactly, does this break VPATH? Can you give me an example? I'll try and correct it, but I don't yet see how it's broken. -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-15 6:43 ` Peter A. Castro @ 2004-04-15 10:35 ` Clint Adams 2004-04-15 16:57 ` Peter A. Castro 0 siblings, 1 reply; 33+ messages in thread From: Clint Adams @ 2004-04-15 10:35 UTC (permalink / raw) To: Peter A. Castro; +Cc: zsh-workers > The use of the shell wildcard (zsh*.html) makes the shell do a pattern > match against the list of files in the directory in which it is run. If > I was building from a work directory (say zsh-4.2.0/.build/Doc) and > installing into a destination root other that "/" (say zsh-4.2.0/.inst) > make executes this bit of shell code and it fails to find any zsh*.html > files because make isn't currently in that directory (it's in > .build/Doc). Prepending ${sdir} ensures the zsh*.html files are Yes, and the html files are generated in the build directory, so it won't find them in ${sdir}. > So how, exactly, does this break VPATH? Can you give me an example? > I'll try and correct it, but I don't yet see how it's broken. Is Cygwin texi2html outputting to your source directory? ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-15 10:35 ` Clint Adams @ 2004-04-15 16:57 ` Peter A. Castro 2004-04-15 18:14 ` Clint Adams 0 siblings, 1 reply; 33+ messages in thread From: Peter A. Castro @ 2004-04-15 16:57 UTC (permalink / raw) To: Clint Adams; +Cc: zsh-workers On Thu, 15 Apr 2004, Clint Adams wrote: > > The use of the shell wildcard (zsh*.html) makes the shell do a pattern > > match against the list of files in the directory in which it is run. If > > I was building from a work directory (say zsh-4.2.0/.build/Doc) and > > installing into a destination root other that "/" (say zsh-4.2.0/.inst) > > make executes this bit of shell code and it fails to find any zsh*.html > > files because make isn't currently in that directory (it's in > > .build/Doc). Prepending ${sdir} ensures the zsh*.html files are > > Yes, and the html files are generated in the build directory, so it > won't find them in ${sdir}. Ah! Now I see what's going on. I've been applying the -doc tar over the source directory which gives me the .html files in the source dir and not in the build dir, and since they are the same date or newer as the zsh.texi source, no processing of it into html is done. Hmmm... Ok, this is will break a full build (sans -doc), I see that now. So, you are correct, the ${sdir} reference should be removed. Sorry! And, thanks for pointing it out! I'll have to decide what I want to do for the Cygwin port, but certainly this should be corrected in cvs. So, what's the procedure? Do I need to submit a patch to undo my original patch or can someone with cvs access (Peter S?) simply back that part of the patch out? > > So how, exactly, does this break VPATH? Can you give me an example? > > I'll try and correct it, but I don't yet see how it's broken. > > Is Cygwin texi2html outputting to your source directory? Well, this has been part of the problem. See texi2html is "back-level" for cygwin, so I end up having to change the makefile to specify different options for texi2html to actually work. I'd gotten around that by just overlaying the -doc tar (plus it was faster than regenerating it), but I completely forgot about the fact that the man and html files are generated and should rightly be created in the build dir, not the source dir. I'll update my build process for Cygwin to do the right thing. In the mean time, that change in cvs should be backed out. -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: zsh and line breaks 2004-04-15 16:57 ` Peter A. Castro @ 2004-04-15 18:14 ` Clint Adams 0 siblings, 0 replies; 33+ messages in thread From: Clint Adams @ 2004-04-15 18:14 UTC (permalink / raw) To: Peter A. Castro; +Cc: zsh-workers > zsh.texi source, no processing of it into html is done. Hmmm... Ok, this > is will break a full build (sans -doc), I see that now. So, you are > correct, the ${sdir} reference should be removed. Sorry! And, thanks > for pointing it out! Presumably it would be useful to handle both situations, though I'm not sure how. > I'll have to decide what I want to do for the Cygwin port, but certainly > this should be corrected in cvs. So, what's the procedure? Do I need to > submit a patch to undo my original patch or can someone with cvs access > (Peter S?) simply back that part of the patch out? I'll just revert it. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Patch for 4.2.3 building on Cygwin 2004-04-05 22:08 ` Peter A. Castro ` (2 preceding siblings ...) 2004-04-15 5:03 ` Clint Adams @ 2005-01-31 5:07 ` Peter A. Castro 2005-01-31 11:37 ` Peter Stephenson 3 siblings, 1 reply; 33+ messages in thread From: Peter A. Castro @ 2005-01-31 5:07 UTC (permalink / raw) To: zsh-workers [-- Attachment #1: Type: TEXT/PLAIN, Size: 1263 bytes --] Cygwin updates against zsh-4.2.3. See attached diffs: configure.ac - check for iconv.h - check for libiconv() if cygwin - call 'pcre-config --libs' to get LIBS if using pcre Src/utils.c - added if defined(HAVE_ICONV_H) to #if's which test for HAVE_ICONV or HAVE_LIBICONV Notes: Added iconv.h header to header check list. This is really just for completeness. iconv() in Cygwin is really libiconv() (iconv.h does a "#define iconv libiconv"). However the AC_CHECK_LIB() macro doesn't know to include iconv.h. I played with coding a custom conf test to #include iconv.h but ran into prototype issues and decided it was simpler to just look for the real function instead using AC_CHECK_LIB. pcre's libs should be obtained by running pcre-config. This isn't really a cygwin-ism, but more of a generic pcre issue. FIFO's in Cygwin are implemented using Windows' underlying named pipes implementation and are somewhat buggy (like Windows, itself :). Until this is resolved, it makes more sense to disable their usage. I'll track this issue and send updates when things are working properly. Thanks! -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood [-- Attachment #2: zsh423cygwin.patch --] [-- Type: TEXT/PLAIN, Size: 2971 bytes --] diff -urN -x .build -x .inst -x .sinst zsh-4.2.3-orig/Src/utils.c zsh-4.2.3/Src/utils.c --- zsh-4.2.3-orig/Src/utils.c 2005-01-12 02:56:16.000000000 -0800 +++ zsh-4.2.3/Src/utils.c 2005-01-22 21:37:58.765625000 -0800 @@ -35,7 +35,7 @@ #else # ifdef HAVE_LANGINFO_H # include <langinfo.h> -# if defined(HAVE_ICONV) || defined(HAVE_LIBICONV) +# if defined(HAVE_ICONV_H) || defined(HAVE_ICONV) || defined(HAVE_LIBICONV) # include <iconv.h> # endif # endif @@ -3521,7 +3521,7 @@ size_t count; #else unsigned int wval; -# if defined(HAVE_NL_LANGINFO) && defined(CODESET) && (defined(HAVE_ICONV) || defined(HAVE_LIBICONV)) +# if defined(HAVE_NL_LANGINFO) && defined(CODESET) && (defined(HAVE_ICONV_H) || defined(HAVE_ICONV) || defined(HAVE_LIBICONV)) iconv_t cd; char inbuf[4]; size_t inbytes, outbytes; @@ -3642,7 +3642,7 @@ t += ucs4toutf8(t, wval); continue; } else { -# if defined(HAVE_ICONV) || defined(HAVE_LIBICONV) +# if defined(HAVE_ICONV_H) || defined(HAVE_ICONV) || defined(HAVE_LIBICONV) inbytes = 4; outbytes = 6; inptr = inbuf; diff -urN -x .build -x .inst -x .sinst zsh-4.2.3-orig/configure.ac zsh-4.2.3/configure.ac --- zsh-4.2.3-orig/configure.ac 2005-01-12 02:55:06.000000000 -0800 +++ zsh-4.2.3/configure.ac 2005-01-29 11:53:24.187500000 -0800 @@ -1,4 +1,3 @@ -dnl dnl configure.ac: Configure template for zsh. dnl Process this file with autoconf to produce a configure script. dnl @@ -529,7 +528,7 @@ locale.h errno.h stdio.h stdlib.h unistd.h sys/capability.h \ utmp.h utmpx.h sys/types.h pwd.h grp.h poll.h sys/mman.h \ netinet/in_systm.h pcre.h langinfo.h wchar.h stddef.h \ - sys/stropts.h) + sys/stropts.h iconv.h) if test $dynamic = yes; then AC_CHECK_HEADERS(dlfcn.h) AC_CHECK_HEADERS(dl.h) @@ -727,11 +726,17 @@ AC_CHECK_LIB(socket, socket) -AC_CHECK_LIB(iconv, iconv) +dnl AC_CHECK_LIB(iconv, iconv) + +if test "$host_os" = cygwin; then +dnl cygwin iconv() is really libiconv() +AC_CHECK_LIB(iconv, libiconv) +fi if test x$enable_pcre = xyes; then dnl pcre-config should probably be employed here -AC_SEARCH_LIBS(pcre_compile, pcre) +dnl AC_SEARCH_LIBS(pcre_compile, pcre) + LIBS="`pcre-config --libs` $LIBS" fi dnl --------------------- @@ -1633,7 +1638,11 @@ dnl ----------- AC_CACHE_CHECK(if named FIFOs work, zsh_cv_sys_fifo, -[AC_TRY_RUN([ +[if test "$host_os" = cygwin; then +dnl for now, fifos no worky in cygwin +zsh_cv_sys_fifo=no +else +AC_TRY_RUN([ #include <fcntl.h> #include <signal.h> main() @@ -1663,7 +1672,8 @@ ], zsh_cv_sys_fifo=yes, zsh_cv_sys_fifo=no, - zsh_cv_sys_fifo=yes)]) + zsh_cv_sys_fifo=yes) +fi]) AH_TEMPLATE([HAVE_FIFOS], [Define to 1 if system has working FIFOs.]) if test $zsh_cv_sys_fifo = yes; then ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Patch for 4.2.3 building on Cygwin 2005-01-31 5:07 ` Patch for 4.2.3 building on Cygwin Peter A. Castro @ 2005-01-31 11:37 ` Peter Stephenson 2005-01-31 20:48 ` Peter A. Castro 0 siblings, 1 reply; 33+ messages in thread From: Peter Stephenson @ 2005-01-31 11:37 UTC (permalink / raw) To: Peter A. Castro, zsh-workers "Peter A. Castro" wrote: > Cygwin updates against zsh-4.2.3. See attached diffs: Thanks, we've already made some rearranagements and included a FIFO patch with the same effect, so the following is the change against the head of the main line. Did you really mean to remove the test AC_CHECK_LIB(iconv, iconv) for all systems other than Cygwin? As far as I can see if iconv really is a separate library it will find the header, compile in the code, and then fail to link. However, I may be missing something. Index: configure.ac =================================================================== RCS file: /cvsroot/zsh/zsh/configure.ac,v retrieving revision 1.24 diff -u -r1.24 configure.ac --- configure.ac 27 Jan 2005 12:01:10 -0000 1.24 +++ configure.ac 31 Jan 2005 11:08:56 -0000 @@ -529,7 +529,7 @@ locale.h errno.h stdio.h stdlib.h unistd.h sys/capability.h \ utmp.h utmpx.h sys/types.h pwd.h grp.h poll.h sys/mman.h \ netinet/in_systm.h pcre.h langinfo.h wchar.h stddef.h \ - sys/stropts.h) + sys/stropts.h iconv.h) if test $dynamic = yes; then AC_CHECK_HEADERS(dlfcn.h) AC_CHECK_HEADERS(dl.h) @@ -727,11 +727,17 @@ AC_CHECK_LIB(socket, socket) -AC_CHECK_LIB(iconv, iconv) +dnl AC_CHECK_LIB(iconv, iconv) + +if test "$host_os" = cygwin; then +dnl cygwin iconv() is really libiconv() +AC_CHECK_LIB(iconv, libiconv) +fi if test x$enable_pcre = xyes; then dnl pcre-config should probably be employed here -AC_SEARCH_LIBS(pcre_compile, pcre) +dnl AC_SEARCH_LIBS(pcre_compile, pcre) + LIBS="`pcre-config --libs` $LIBS" fi dnl --------------------- Index: Src/system.h =================================================================== RCS file: /cvsroot/zsh/zsh/Src/system.h,v retrieving revision 1.26 diff -u -r1.26 system.h --- Src/system.h 26 Jan 2005 18:37:31 -0000 1.26 +++ Src/system.h 31 Jan 2005 11:08:56 -0000 @@ -700,7 +700,7 @@ #else # ifdef HAVE_LANGINFO_H # include <langinfo.h> -# if defined(HAVE_ICONV) || defined(HAVE_LIBICONV) +# if defined(HAVE_ICONV_H) || defined(HAVE_ICONV) || defined(HAVE_LIBICONV) # include <iconv.h> # endif # endif Index: Src/utils.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/utils.c,v retrieving revision 1.71 diff -u -r1.71 utils.c --- Src/utils.c 14 Jan 2005 13:05:22 -0000 1.71 +++ Src/utils.c 31 Jan 2005 11:08:57 -0000 @@ -3510,7 +3510,7 @@ size_t count; #else unsigned int wval; -# if defined(HAVE_NL_LANGINFO) && defined(CODESET) && (defined(HAVE_ICONV) || defined(HAVE_LIBICONV)) +# if defined(HAVE_NL_LANGINFO) && defined(CODESET) && (defined(HAVE_ICONV_H) || defined(HAVE_ICONV) || defined(HAVE_LIBICONV)) iconv_t cd; char inbuf[4]; size_t inbytes, outbytes; @@ -3631,7 +3631,7 @@ t += ucs4toutf8(t, wval); continue; } else { -# if defined(HAVE_ICONV) || defined(HAVE_LIBICONV) +# if defined(HAVE_ICONV_H) || defined(HAVE_ICONV) || defined(HAVE_LIBICONV) inbytes = 4; outbytes = 6; inptr = inbuf; -- Peter Stephenson <pws@csr.com> Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Patch for 4.2.3 building on Cygwin 2005-01-31 11:37 ` Peter Stephenson @ 2005-01-31 20:48 ` Peter A. Castro 2005-02-01 10:53 ` Peter Stephenson 0 siblings, 1 reply; 33+ messages in thread From: Peter A. Castro @ 2005-01-31 20:48 UTC (permalink / raw) To: Peter Stephenson; +Cc: zsh-workers On Mon, 31 Jan 2005, Peter Stephenson wrote: > "Peter A. Castro" wrote: > > Cygwin updates against zsh-4.2.3. See attached diffs: > > Thanks, we've already made some rearranagements and included a FIFO > patch with the same effect, so the following is the change against the > head of the main line. Great! > Did you really mean to remove the test > > AC_CHECK_LIB(iconv, iconv) > > for all systems other than Cygwin? As far as I can see if iconv really > is a separate library it will find the header, compile in the code, and > then fail to link. However, I may be missing something. Argh! Wrong patch! Sorry! I'd made several attempts at hacking configure.ac and somehow included the wrong hunk in the patch. So, keep the AC_CHECK_LIB(iconv, iconv) and just add the check for AC_CHECK_LIB(iconv, libiconv) if $host_os=cygwin. Very sorry! -- Peter A. Castro <doctor@fruitbat.org> or <Peter.Castro@oracle.com> "Cats are just autistic Dogs" -- Dr. Tony Attwood ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Patch for 4.2.3 building on Cygwin 2005-01-31 20:48 ` Peter A. Castro @ 2005-02-01 10:53 ` Peter Stephenson 2005-02-01 16:03 ` Bart Schaefer 0 siblings, 1 reply; 33+ messages in thread From: Peter Stephenson @ 2005-02-01 10:53 UTC (permalink / raw) To: Peter A. Castro; +Cc: zsh-workers "Peter A. Castro" wrote: > So, keep the AC_CHECK_LIB(iconv, iconv) and just add the check for > AC_CHECK_LIB(iconv, libiconv) if $host_os=cygwin. OK, I've committed it on the main line with that change. pws ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com ********************************************************************** ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Patch for 4.2.3 building on Cygwin 2005-02-01 10:53 ` Peter Stephenson @ 2005-02-01 16:03 ` Bart Schaefer 2005-02-01 18:04 ` Peter Stephenson 0 siblings, 1 reply; 33+ messages in thread From: Bart Schaefer @ 2005-02-01 16:03 UTC (permalink / raw) To: zsh-workers On Feb 1, 10:53am, Peter Stephenson wrote: } Subject: Re: Patch for 4.2.3 building on Cygwin } } "Peter A. Castro" wrote: } > So, keep the AC_CHECK_LIB(iconv, iconv) and just add the check for } > AC_CHECK_LIB(iconv, libiconv) if $host_os=cygwin. } } OK, I've committed it on the main line with that change. And I've applied the diffs to the zsh-4_2-patches branch as well. Please check that I got it right, as I changed utils.c directly rather than move the whole iconv section into system.h as has been done on the main line. ^ permalink raw reply [flat|nested] 33+ messages in thread
* Re: Patch for 4.2.3 building on Cygwin 2005-02-01 16:03 ` Bart Schaefer @ 2005-02-01 18:04 ` Peter Stephenson 0 siblings, 0 replies; 33+ messages in thread From: Peter Stephenson @ 2005-02-01 18:04 UTC (permalink / raw) To: zsh-workers Bart Schaefer wrote: > And I've applied the diffs to the zsh-4_2-patches branch as well. Please > check that I got it right, as I changed utils.c directly rather than move > the whole iconv section into system.h as has been done on the main line. It should be identical to the original patch to utils.c, which it seems to be. pws ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ********************************************************************** ^ permalink raw reply [flat|nested] 33+ messages in thread
end of thread, other threads:[~2005-02-01 18:05 UTC | newest] Thread overview: 33+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <s38u10erwrz.fsf@ackusativ.ling.uu.se> [not found] ` <1vvf60l9i7n4nlobcroik2le5ofe6v2rn4@4ax.com> [not found] ` <Pine.LNX.4.53.0403291441160.5939@gremlin.fruitbat.org> 2004-03-30 9:32 ` zsh and line breaks Oliver Kiddle 2004-03-30 18:54 ` Peter A. Castro 2004-03-31 12:45 ` Oliver Kiddle 2004-03-31 17:53 ` Peter A. Castro 2004-04-01 9:09 ` Oliver Kiddle 2004-04-01 21:20 ` Peter A. Castro 2004-04-02 9:49 ` Dave Korn 2004-04-02 16:59 ` Peter A. Castro 2004-04-03 1:23 ` Peter A. Castro 2004-04-03 20:35 ` Bart Schaefer 2004-04-04 19:29 ` Peter Stephenson 2004-04-05 16:19 ` Peter A. Castro 2004-04-05 17:40 ` Peter Stephenson 2004-04-05 22:08 ` Peter A. Castro 2004-04-05 23:08 ` Clint Adams 2004-04-05 23:25 ` Peter A. Castro 2004-04-07 21:10 ` Clint Adams 2004-04-08 1:16 ` Peter A. Castro 2004-04-09 5:00 ` Felix Rosencrantz 2004-04-09 16:26 ` Peter A. Castro 2004-04-06 9:43 ` Peter Stephenson 2004-04-06 22:25 ` Peter A. Castro 2004-04-15 5:03 ` Clint Adams 2004-04-15 6:43 ` Peter A. Castro 2004-04-15 10:35 ` Clint Adams 2004-04-15 16:57 ` Peter A. Castro 2004-04-15 18:14 ` Clint Adams 2005-01-31 5:07 ` Patch for 4.2.3 building on Cygwin Peter A. Castro 2005-01-31 11:37 ` Peter Stephenson 2005-01-31 20:48 ` Peter A. Castro 2005-02-01 10:53 ` Peter Stephenson 2005-02-01 16:03 ` Bart Schaefer 2005-02-01 18:04 ` Peter Stephenson
Code repositories for project(s) associated with this public inbox https://git.vuxu.org/mirror/zsh/ This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).