Re: new package offering: zsh
On Sun, May 26, 2002 at 07:10:00PM -0700, Peter A. Castro wrote: On Fri, 24 May 2002, Christopher Faylor wrote: If you are going to be a maintainer, I'd request that you subscribe to the non-digest version of cygwin-apps. The traffic is really not that great. Hmm. We should make this a requirement in the package maintainer's guide. The thing I like about digests is it bundles list mail together and makes it easier to follow a topic. But, if you feel maintainer's should be on the regular list for more expedient responses, I guess I can deal with that. Mind you, the Cygwin Package Contributors Guide does say that subscribing to digest is ok. Not any more. If it's using termcap then it needs a termcap dependency for /etc/termcap. (D'oh!) Ok, I've corrected the setup.hint to have a depenency on the termcap package. Thanks. Ok, so, the package is ready for upload: http://www.fruitbat.org/Cygwin/zsh/setup.hint http://www.fruitbat.org/Cygwin/zsh/zsh-4.0.4-1.tar.bz2 http://www.fruitbat.org/Cygwin/zsh/zsh-4.0.4-1-src.tar.bz2 http://www.fruitbat.org/Cygwin/index.html Um, do I need to send a specific email to Robert or will he upload it by virtue of reading this on the list? I've uploaded it to sources.redhat.com. You can send out an announcement anytime. Thanks very much for making this available. cgf
Re: new package offering: zsh
On Thu, 23 May 2002, Charles Wilson wrote: Peter A. Castro wrote: On Wed, 22 May 2002, Charles Wilson wrote: No -- if zsh can handle cr+lf internally, then let it do so. Explicitly open function files in binary mode -- this will override the textmode mount which sets the default read mode. zsh uses the open() call, not fopen(). There is no binary vs. text mode to specify. Theoretically, open() should be opening the file in binary mode already (ie: no text translation/interpretation), yet the data read in clearly is being cooked under some scenarios. No, if I understand how things are work here, I believe the carriage control processing is being done at the filesystem level, which is below open() and beyond my control. But, like I said, if this causes enough trouble for people, I'll update the code to be more relaxed on the size checking. You can use the O_BINARY flag in open() calls -- but since some platforms don't define it, you must include something like #ifndef O_BINARY #define O_BINARY 0 #endif somewhere in zsh's header files open() will still obey the default mount mode settings of the underlying cygwin system; that is, if the file is on a text mount, it will be opened using CR/LF--LF translation. If the file is on a binary mount, it will be opened in O_BINARY mode. include O_BINARY in your open call to force binary mode on the file. I'll give this a try, as it has the virtue of making the stream read in as-is and is an attribute of the open() call. Also, Egor Duda suggested using setmode(), but I don't see a manpage for this function (but did find the prototype in io.h). But, an ounce of experience is worth a pound of theory...all I've got is theory. :-) You are wise beyond your ears :-) --Chuck -- Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED] Cats are just autistic Dogs -- Dr. Tony Attwood
Re: new package offering: zsh
On 23 May 2002 [EMAIL PROTECTED] wrote: Hi All, There were some messages/questions that were only on the list (I get the digest version), so I appologize for not responding more promptly. I did want to respond to people and get a final resolution on zsh. From: Christopher Faylor [EMAIL PROTECTED] On Wed, May 22, 2002 at 06:32:07PM -0500, Matthew Smith wrote: I'll vote yes for this, but I do have a question: have you dealt with binary/text issues specific to the windows platform in your port? zsh has historically had pretty strong cygwin support so I don't think this will be an issue. I would be thrilled to have this in the distribution. I've been using my own version of zsh for years and have been meaning to submit it as a package. I even went as far as incorporating it into mknetrel. I'd be happy to have some other victi, er, person to deal with the inevitable questions, though. I'm willing to handle issues with zsh, and in particular, this port of zsh. As I've said, I really enjoy hacking on it, and I feel it's a shell worth of inclusion in Cygwin. Why else would I have offered it? (well, besides the fact that I'm a bit loony, but that's completely besides the point... :) One minor question: isn't there a libncurses requirement for zsh? And maybe a libintl-1? Funny you should mention that. Actually, only the Zle modules cares about screen attributes and control, and it is it's own terminal manager (using termio for the line control). It does link with termcap, but it's a static link, so no runtime needed, really. Also, there doesn't appear to be a need for libintl (at least I didn't see it in any of the links). cgf From: Charles Wilson [EMAIL PROTECTED] You can use the O_BINARY flag in open() calls -- but since some platforms don't define it, you must include something like #ifndef O_BINARY #define O_BINARY 0 #endif somewhere in zsh's header files open() will still obey the default mount mode settings of the underlying cygwin system; that is, if the file is on a text mount, it will be opened using CR/LF--LF translation. If the file is on a binary mount, it will be opened in O_BINARY mode. include O_BINARY in your open call to force binary mode on the file. But, an ounce of experience is worth a pound of theory...all I've got is theory. :-) --Chuck Now, as to the use of O_BINARY. Is it the general concensus that this change should be investigated before the package will be accepted or would people like to give it a try while I experiment with it? -- Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED] Cats are just autistic Dogs -- Dr. Tony Attwood
Re: new package offering: zsh
On Wed, 22 May 2002, Charles Wilson wrote: No -- if zsh can handle cr+lf internally, then let it do so. Explicitly open function files in binary mode -- this will override the textmode mount which sets the default read mode. zsh uses the open() call, not fopen(). There is no binary vs. text mode to specify. Theoretically, open() should be opening the file in binary mode already (ie: no text translation/interpretation), yet the data read in clearly is being cooked under some scenarios. No, if I understand how things are work here, I believe the carriage control processing is being done at the filesystem level, which is below open() and beyond my control. But, like I said, if this causes enough trouble for people, I'll update the code to be more relaxed on the size checking. That way, number of bytes reported by stat() will equal the number of bytes reported by read(). The buffer thus filled will contain cr+lf -- but supposedly zsh can deal with that... --Chuck Matthew Smith wrote: This sounds perfectly reasonable to me. cheers, -Matt I know of one issue concerning loading of functions. Is there another you had in mind? For the most part, zsh handles cr+lf as if it were lf implicitly. For loading functions, the code assumes a binary mode, ie: the number of bytes reported by stat() of a file is the number of bytes reported back from read() after reading in the whole file. On a filesystem mounted in textmode, this isn't always true and can cause the function to not load. I really feel this is a filesystem attribute issue, but if it's annoying enough for people, I'll loosen the size matching restrictions. A workaround for now is to strip your functions of all Carriage-Returns, thus only have linefeeds in the file. -- Peter A. Castro [EMAIL PROTECTED] or [EMAIL PROTECTED] Cats are just autistic Dogs -- Dr. Tony Attwood
Re: new package offering: zsh
I'll vote yes for this, but I do have a question: have you dealt with binary/text issues specific to the windows platform in your port? cheers, -Matt Hi All, In doing porting work for another project, I ended up porting zsh (my favorite shell) to Cygwin, so I might as well offer it as a package. I will be an active maintainer of zsh as I use this shell on a regular bases on many systems. Here's the setup.hint and all the URLs:
Re: new package offering: zsh
On Wed, May 22, 2002 at 06:32:07PM -0500, Matthew Smith wrote: I'll vote yes for this, but I do have a question: have you dealt with binary/text issues specific to the windows platform in your port? zsh has historically had pretty strong cygwin support so I don't think this will be an issue. I would be thrilled to have this in the distribution. I've been using my own version of zsh for years and have been meaning to submit it as a package. I even went as far as incorporating it into mknetrel. I'd be happy to have some other victi, er, person to deal with the inevitable questions, though. One minor question: isn't there a libncurses requirement for zsh? And maybe a libintl-1? cgf
Re: new package offering: zsh
This sounds perfectly reasonable to me. cheers, -Matt I know of one issue concerning loading of functions. Is there another you had in mind? For the most part, zsh handles cr+lf as if it were lf implicitly. For loading functions, the code assumes a binary mode, ie: the number of bytes reported by stat() of a file is the number of bytes reported back from read() after reading in the whole file. On a filesystem mounted in textmode, this isn't always true and can cause the function to not load. I really feel this is a filesystem attribute issue, but if it's annoying enough for people, I'll loosen the size matching restrictions. A workaround for now is to strip your functions of all Carriage-Returns, thus only have linefeeds in the file.
Re: new package offering: zsh
No -- if zsh can handle cr+lf internally, then let it do so. Explicitly open function files in binary mode -- this will override the textmode mount which sets the default read mode. That way, number of bytes reported by stat() will equal the number of bytes reported by read(). The buffer thus filled will contain cr+lf -- but supposedly zsh can deal with that... --Chuck Matthew Smith wrote: This sounds perfectly reasonable to me. cheers, -Matt I know of one issue concerning loading of functions. Is there another you had in mind? For the most part, zsh handles cr+lf as if it were lf implicitly. For loading functions, the code assumes a binary mode, ie: the number of bytes reported by stat() of a file is the number of bytes reported back from read() after reading in the whole file. On a filesystem mounted in textmode, this isn't always true and can cause the function to not load. I really feel this is a filesystem attribute issue, but if it's annoying enough for people, I'll loosen the size matching restrictions. A workaround for now is to strip your functions of all Carriage-Returns, thus only have linefeeds in the file.
