Re: zsh and line breaks

Re: zsh and line breaks

[Oliver Kiddle]

"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

Re: zsh and line breaks

[Peter A. Castro]

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

Re: zsh and line breaks

[Oliver Kiddle]

"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

Re: zsh and line breaks

[Peter A. Castro]

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

Re: zsh and line breaks

[Oliver Kiddle]

"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

Re: zsh and line breaks

[Peter A. Castro]

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

RE: zsh and line breaks

[Dave Korn]

> -----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....

RE: zsh and line breaks

[Peter A. Castro]

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

Re: zsh and line breaks

[Peter A. Castro]

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

Re: zsh and line breaks

[Bart Schaefer]

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.

Re: zsh and line breaks

[Peter Stephenson]

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

Re: zsh and line breaks

[Peter A. Castro]

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

Re: zsh and line breaks

[Peter Stephenson]

"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
**********************************************************************

Re: zsh and line breaks

[Peter A. Castro]

[-- 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=}

Re: zsh and line breaks

[Clint Adams]

> -TEXI2HTML = texi2html -expand info -split chapter
> +TEXI2HTML = texi2html -expandinfo -split_chapter

Don't do that; -expandinfo was obsoleted nearly 4 years ago.

Re: zsh and line breaks

[Peter A. Castro]

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

Re: zsh and line breaks

[Peter Stephenson]

"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
**********************************************************************

Re: zsh and line breaks

[Peter A. Castro]

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

Re: zsh and line breaks

[Clint Adams]

> 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.

Re: zsh and line breaks

[Peter A. Castro]

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

Re: zsh and line breaks

[Felix Rosencrantz]

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/

Re: zsh and line breaks

[Peter A. Castro]

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

Re: zsh and line breaks

[Clint Adams]

>                   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.

Re: zsh and line breaks

[Peter A. Castro]

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

Re: zsh and line breaks

[Clint Adams]

> 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?

Re: zsh and line breaks

[Peter A. Castro]

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

Re: zsh and line breaks

[Clint Adams]

> 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.

Patch for 4.2.3 building on Cygwin

[Peter A. Castro]

[-- 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

Re: Patch for 4.2.3 building on Cygwin

[Peter Stephenson]

"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
**********************************************************************

Re: Patch for 4.2.3 building on Cygwin

[Peter A. Castro]

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

Re: Patch for 4.2.3 building on Cygwin

[Peter Stephenson]

"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
**********************************************************************

Re: Patch for 4.2.3 building on Cygwin

[Bart Schaefer]

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.

Re: Patch for 4.2.3 building on Cygwin

[Peter Stephenson]

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.

**********************************************************************