Date: Thu, 11 Nov 2004 00:04:21 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 444 ************************************************** Wednesday 10 November 2004 Number 444 ************************************************** Subjects for today 1 Re: Updated tar needed : John Poltorak 2 Re: Updated tar needed : Robert Henschel 3 Re: Updated tar needed : John Poltorak 4 Re: Updated tar needed : Yuri Dario" 5 Re: Updated tar needed : Robert Henschel 6 Re: Updated tar needed : John Poltorak 7 Re: Updated tar needed : Yuri Dario" 8 Re: Updated tar needed : John Poltorak 9 Re: Updated tar needed : Yuri Dario" 10 Re: Updated tar needed : T.Sikora" 11 Re: Updated tar needed : John Poltorak 12 Re: Updated tar needed : John Poltorak 13 Re: Updated tar needed : Yuri Dario" 14 Re: Updated tar needed : Yuri Dario" 15 Re: Removing RO during 'tar -x' : Steven Levine" 16 Re: Large file support in Python : Knut St. Osmundsen" 17 Re: Removing RO during 'tar -x' : John Poltorak 18 Re: -lsocket problem : Knut St. Osmundsen" 19 Re: Updated tar needed : Steve Wendt 20 Re: -lsocket problem : John Poltorak 21 Re: Large file support in Python : John Poltorak 22 Re: Removing RO during 'tar -x' : Steven Levine" 23 Re: Large file support in Python : Paul Smedley 24 Re: -lsocket problem : Henry Sobotka 25 Re: -lsocket problem : Knut St. Osmundsen" 26 Re: Large file support in Python : Knut St. Osmundsen" 27 Re: Removing RO during 'tar -x' : Dave Saville" 28 Re: Large file support in Python : Andrew MacIntyre 29 Debugging tar : John Poltorak 30 Re: Large file support in Python : Paul Smedley 31 \n conversion with TR : John Poltorak 32 Re: \n conversion with TR : Dave Saville" **= Email 1 ==========================** Date: Tue, 9 Nov 2004 12:44:17 +0000 From: John Poltorak Subject: Re: Updated tar needed On Tue, Nov 09, 2004 at 12:09:41PM +0100, Stefan.Neis at t-online.de wrote: > John Poltorak schrieb: > > > and the > > inability of tar to be able to extract BZIPed files. > > What's the problem with "bzip -dc filename | tar xf -" ? > If you're using a "normal" tar (i.e. non-GNU, e.g. on > any commercial Unix), that's the way you need to do > it anyway. Yes, but it's so much easier to run 'tar zxf' without having to think about the flavour of the compressed file. > > Does anyone know what problems are likely to arise in > > trying to build the most recent GNU version (1.14) ? > > I suppose one can't say much besides "try and see". Well I just did and would you believe it? I managed to create an executable straight out of the box!! I have *NOT* tested it out apart from see whether '--version' and '--help' works. If anyone does want to try it, you can get a copy here:- ftp://213.152.37.92/tar.exe You may also need ftp://213.152.37.92/intl.dll I'd be interested to know if it works for anyone. > > Regards, > Stefan -- John **= Email 2 ==========================** Date: Tue, 09 Nov 2004 14:56:44 +0100 From: Robert Henschel Subject: Re: Updated tar needed John Poltorak wrote: > On Tue, Nov 09, 2004 at 12:09:41PM +0100, Stefan.Neis at t-online.de wrote: > >>John Poltorak schrieb: >> >> >>>and the >>>inability of tar to be able to extract BZIPed files. >> >>What's the problem with "bzip -dc filename | tar xf -" ? >>If you're using a "normal" tar (i.e. non-GNU, e.g. on >>any commercial Unix), that's the way you need to do >>it anyway. > > > Yes, but it's so much easier to run 'tar zxf' without having to think > about the flavour of the compressed file. > > > >>>Does anyone know what problems are likely to arise in >>>trying to build the most recent GNU version (1.14) ? >> >>I suppose one can't say much besides "try and see". > > > Well I just did and would you believe it? I managed to create an > executable straight out of the box!! > > I have *NOT* tested it out apart from see whether '--version' and '--help' > works. > > If anyone does want to try it, you can get a copy here:- > > ftp://213.152.37.92/tar.exe > > You may also need > > ftp://213.152.37.92/intl.dll > > I'd be interested to know if it works for anyone. It dies with an abnormal program termination at the end, but it unpacks the Zope tar archive including the long files! Also a listing of the archive does work. (tar.exe tf ZopeX3-3.0.0.tar >zope.lst ) Very good! Robert -- Robert Henschel -- OS/2 User Group Dresden http://warp5.dyndns.org:8080/OS2Dresden **= Email 3 ==========================** Date: Tue, 9 Nov 2004 14:29:22 +0000 From: John Poltorak Subject: Re: Updated tar needed On Tue, Nov 09, 2004 at 02:56:44PM +0100, Robert Henschel wrote: > > I'd be interested to know if it works for anyone. > It dies with an abnormal program termination at the end, but it unpacks > the Zope tar archive including the long files! Yes, it would be good to stop that happening but it does appear to work. > Also a listing of the archive does work. > (tar.exe tf ZopeX3-3.0.0.tar >zope.lst ) I'm particularly pleased about that! > Very good! It does show that the tools for building open source apps are now pretty usable. Hopefully, things will improve even more once gcc 3.3.4 is released. > Robert > > -- > Robert Henschel > > -- > OS/2 User Group Dresden > http://warp5.dyndns.org:8080/OS2Dresden You're using Zope/Plone! It wouldn't be under OS/2 would it? -- John **= Email 4 ==========================** Date: Tue, 09 Nov 2004 16:05:32 +0100 (CET) From: "Yuri Dario" Subject: Re: Updated tar needed Hi John, >Well I just did and would you believe it? I managed to create an >executable straight out of the box!! >I have *NOT* tested it out apart from see whether '--version' and '--help' does it include support for OS/2 EA and ACL's? does it work with scsi tapes? I'm asking because gtar/gtak features maybe are not included in gnu tar code. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 5 ==========================** Date: Tue, 09 Nov 2004 15:55:42 +0100 From: Robert Henschel Subject: Re: Updated tar needed John Poltorak wrote: > On Tue, Nov 09, 2004 at 02:56:44PM +0100, Robert Henschel wrote: > >>>I'd be interested to know if it works for anyone. >> >>It dies with an abnormal program termination at the end, but it unpacks >>the Zope tar archive including the long files! > > > Yes, it would be good to stop that happening but it does appear to work. > > > >>Also a listing of the archive does work. >>(tar.exe tf ZopeX3-3.0.0.tar >zope.lst ) > > > I'm particularly pleased about that! > > >>Very good! > > > It does show that the tools for building open source apps are now pretty > usable. Hopefully, things will improve even more once gcc 3.3.4 is > released. > > > >>Robert >> >>-- >>Robert Henschel >> >>-- >>OS/2 User Group Dresden >>http://warp5.dyndns.org:8080/OS2Dresden > > > You're using Zope/Plone! It wouldn't be under OS/2 would it? Sure! I am very happy that it is available for OS/2! Thanks to you and Ted and everybody else who helped to make it work under OS/2! Robert -- Robert Henschel -- OS/2 User Group Dresden http://warp5.dyndns.org:8080/OS2Dresden **= Email 6 ==========================** Date: Tue, 9 Nov 2004 15:27:56 +0000 From: John Poltorak Subject: Re: Updated tar needed On Tue, Nov 09, 2004 at 04:05:32PM +0100, Yuri Dario wrote: > Hi John, > > >Well I just did and would you believe it? I managed to create an > >executable straight out of the box!! > >I have *NOT* tested it out apart from see whether '--version' and '--help' > > does it include support for OS/2 EA and ACL's? No. > does it work with scsi tapes? No. We'll need to find a new solution for that. I wonder if it will be possible to utilise aspirout.sys in some way to provide a new tape interface to tar... It would be nice to have an OS/2 version of rmt... > > I'm asking because gtar/gtak features maybe are not included in gnu tar code. They won't be. The GTAK code was never publicly available AFAIK. This will be a PITA unless someone can incorporate the old features into a new tar. > > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.os2power.com/yuri > * http://www.teamos2.it > */ -- John **= Email 7 ==========================** Date: Tue, 09 Nov 2004 17:09:46 +0100 (CET) From: "Yuri Dario" Subject: Re: Updated tar needed Hi, >They won't be. The GTAK code was never publicly available AFAIK. the GTAR code is shipped with gtar258.zip, and there is the code to R/W EA and ACL, plus something else. Since gnu tar evolved from 1.10 to 1.14, I don't think the code changed too much. Regarding GTAK, the full source code was included in earlier releases, and here I have a modified copy of such code (I used it for another backup software). >It would be nice to have an OS/2 version of rmt... some sources are included in gtar, but the readme says other headers are required: maybe they are the same I have here. BTW if you can find an old Hobbes CDROM (pre 1995), I'm quite sure you can find the old archives (I don't have them). Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 8 ==========================** Date: Tue, 9 Nov 2004 16:06:59 +0000 From: John Poltorak Subject: Re: Updated tar needed On Tue, Nov 09, 2004 at 03:27:56PM +0000, John Poltorak wrote: > On Tue, Nov 09, 2004 at 04:05:32PM +0100, Yuri Dario wrote: > > I'm asking because gtar/gtak features maybe are not included in gnu tar code. > > They won't be. The GTAK code was never publicly available AFAIK. Just looking through GTAR258.ZIP, I see a LIB dir under TAR which contains code for using EAs and ACLs. Maybe one of our top coders could look at this and say if it could be incorporated into tar 1.14. Some of our OS/2 features may be salvageable... > > Bye, > > > > Yuri Dario > > > > /* > > * member of TeamOS/2 - Italy > > * http://www.os2power.com/yuri > > * http://www.teamos2.it > > */ -- John **= Email 9 ==========================** Date: Tue, 09 Nov 2004 17:31:20 +0100 (CET) From: "Yuri Dario" Subject: Re: Updated tar needed Hi, >BTW if you can find an old Hobbes CDROM (pre 1995), I'm quite sure you can find the old >archives (I don't have them). do a google search for gtak212b.zip: that was the last version shipping with FULL source code :-) Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 10 ==========================** Date: Tue, 09 Nov 2004 12:10:59 -0500 From: "T.Sikora" Subject: Re: Updated tar needed Yuri Dario wrote: > Hi, > > >>BTW if you can find an old Hobbes CDROM (pre 1995), I'm quite sure you can find the old >>archives (I don't have them). > > > do a google search for gtak212b.zip: that was the last version shipping with FULL source code > :-) > Got it here: ftp://os2ports.com/pub/os2/unix/archivers/ gtar 258 includes the source -- T.Sikora tsikora at ntplx dot net **= Email 11 ==========================** Date: Tue, 9 Nov 2004 16:58:58 +0000 From: John Poltorak Subject: Re: Updated tar needed On Tue, Nov 09, 2004 at 05:31:20PM +0100, Yuri Dario wrote: > Hi, > > >BTW if you can find an old Hobbes CDROM (pre 1995), I'm quite sure you can find the old > >archives (I don't have them). > > do a google search for gtak212b.zip: that was the last version shipping with FULL source code > :-) Thanks. Found it. Isn't Google wonderful? :-)... I wonder if it would be possible to build TAPE using ASPIROUT.SYS instead of one of the other drivers used by GTAK. Do you think it is possible to bring tar 1.14 up to the OS/2 functionality of GTAK/GTAR ? I guess we need to add in the code to access EAs and ACLs and then enable it to access a tape device. Is anyone up to the challenge? ;-) > Bye, > > Yuri Dario > > /* > * member of TeamOS/2 - Italy > * http://www.os2power.com/yuri > * http://www.teamos2.it > */ -- John **= Email 12 ==========================** Date: Tue, 9 Nov 2004 17:01:03 +0000 From: John Poltorak Subject: Re: Updated tar needed On Tue, Nov 09, 2004 at 12:10:59PM -0500, T.Sikora wrote: > Yuri Dario wrote: > > Hi, > > > > > >>BTW if you can find an old Hobbes CDROM (pre 1995), I'm quite sure you can find the old > >>archives (I don't have them). > > > > > > do a google search for gtak212b.zip: that was the last version shipping with FULL source code > > :-) > > > > Got it here: > > ftp://os2ports.com/pub/os2/unix/archivers/ > > gtar 258 includes the source It doesn't include the full source for the TAPE utility. The source it does include is a little obscure - I never managed to get it to build anything. > > > -- > T.Sikora > tsikora at ntplx dot net -- John **= Email 13 ==========================** Date: Tue, 09 Nov 2004 18:23:42 +0100 (CET) From: "Yuri Dario" Subject: Re: Updated tar needed Hi >> do a google search for gtak212b.zip: that was the last version shipping with FULL source >gtar 258 includes the source only tar sources, not the sources for scsi subsystem. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 14 ==========================** Date: Tue, 09 Nov 2004 18:25:24 +0100 (CET) From: "Yuri Dario" Subject: Re: Updated tar needed Hi, >I wonder if it would be possible to build TAPE using ASPIROUT.SYS instead >of one of the other drivers used by GTAK. I think it should not be difficult, scsi access is the same, maybe some different calls. >Do you think it is possible to bring tar 1.14 up to the OS/2 functionality >of GTAK/GTAR ? depends on source changes from 1.10 to 1.14, but as I said, they should not be too much different. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 15 ==========================** Date: Tue, 09 Nov 2004 09:29:43 -0800 From: "Steven Levine" Subject: Re: Removing RO during 'tar -x' In <0028380840.0000051D at pooh>, on 11/09/04 at 07:52 AM, "Dave Saville" said: >Hmm I can't get find to find the right files - so here is an even more >convoluted version :-) >find . -type f | xargs ls -l | cut -c 34- |xargs chmod +w Am I missing something? What's wrong with: find . -type f -exec chmod +w {} ; or the possibly faster: find . -type f | xargs -n50 -s2047 chmod +w These should work on on OS/2 box, but may fail on a unix box because you may find files that you do not have permission to change and xargs will die. This can be avoided with a more selective find or by wrapping the chmod in a while loop. Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.60b #10183 Warp4/FP15/14.093c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 16 ==========================** Date: Tue, 09 Nov 2004 19:57:09 +0100 From: "Knut St. Osmundsen" Subject: Re: Large file support in Python John Poltorak wrote: > On Tue, Nov 09, 2004 at 10:14:43PM +1100, Andrew MacIntyre wrote: > >>On Mon, 8 Nov 2004, John Poltorak wrote: >> >> >>>Can we expect large file support in Python in the near future? >> >>Define "near"... ;-) > > > Within the next three months... > > >>Its a high priority for me to get large file support added, but I've had >>little time or energy over last couple of months to devote to the work >>:-( > > > Yes, I know the feeling. Me too :) Andrew, I were wondering (and I think Adrian (Mr. Netlabs) is too) how tighly the Phython port is tied to EMX, and/or how much OS/2 specific changes has been done. The idea (which was Adrian's, not mine) was get it building with the new libc/gcc, and use the result (once I've fixed any LIBC issues which surfaced) to port the gentoo portage to OS/2. And on the topic, by using the new libc/gcc 64-bit should work automatically. Kind Regards, knut **= Email 17 ==========================** Date: Tue, 9 Nov 2004 18:48:41 +0000 From: John Poltorak Subject: Re: Removing RO during 'tar -x' On Tue, Nov 09, 2004 at 09:29:43AM -0800, Steven Levine wrote: > In <0028380840.0000051D at pooh>, on 11/09/04 > at 07:52 AM, "Dave Saville" said: > > >Hmm I can't get find to find the right files - so here is an even more > >convoluted version :-) > > >find . -type f | xargs ls -l | cut -c 34- |xargs chmod +w > > Am I missing something? > > What's wrong with: > > find . -type f -exec chmod +w {} ; Doesn't this update the attributes of every single file from the current directory down? More often than not there won't be any files set RO at all. > or the possibly faster: > > find . -type f | xargs -n50 -s2047 chmod +w > > These should work on on OS/2 box, but may fail on a unix box because you > may find files that you do not have permission to change and xargs will > die. This can be avoided with a more selective find or by wrapping the > chmod in a while loop. Not being a FIND aficionado myself, can you explain the -n and -s parameters to xargs? > Steven > > -- > ---------------------------------------------------------------------- > "Steven Levine" MR2/ICE 2.60b #10183 Warp4/FP15/14.093c_W4 > www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) > ---------------------------------------------------------------------- > -- John **= Email 18 ==========================** Date: Tue, 09 Nov 2004 20:05:40 +0100 From: "Knut St. Osmundsen" Subject: Re: -lsocket problem Henry Sobotka wrote: > John Poltorak wrote: > >> >> Is there a simple way of establishing from nspr4.dll which socket lib >> is was built from? And can anyone suggest a way of checking out that >> library to see if there is a problem with it? > > > Actually, setmozenv.cmd sets LIBRARY_PATH to > %GCCDIR2%/lib/tcpipv4;%GCCDIR2%/lib;%TOOLKIT2%/lib;, and there's a > libsocket.lib in gcc 3.2.2's lib/tcpipv4 so it wouldn't use anything > else unless you're somehow overriding that setting after running > setmozenv.cmd. > > I would suggest running gccenv.cmd and setmozenv.cmd, then "echo > %LIBRARY_PATH%" to make sure it's set properly and, if OK, cd into > nsprpub/pr and run make to rebuild nspr4.dll. > > Before that, you might run chkdll32 on the bad and good nspr4.dll to see > if the output differs in any way. If NSPR4 is not linked with TCPIP32 things should be ok. The generic way of checking which libraries was included are: - Check the ilink map file (ld mapfiles are not useful) - Enable tracing of the linking process using the "-t" option of gcc/ld/emxomfld. The typical trouble you'll see when linking with the wrong library is associated with errno values of EPFNOSUPPORT and EAFNOSUPPORT. Kind Regards, knut **= Email 19 ==========================** Date: Tue, 9 Nov 2004 11:17:28 -0800 (PST) From: Steve Wendt Subject: Re: Updated tar needed On Tue, 9 Nov 2004, John Poltorak wrote: >> What's the problem with "bzip -dc filename | tar xf -" ? > > Yes, but it's so much easier to run 'tar zxf' without having to think > about the flavour of the compressed file. Huh? 'z' is for gzip, while 'j' is for bzip2. **= Email 20 ==========================** Date: Tue, 9 Nov 2004 19:25:21 +0000 From: John Poltorak Subject: Re: -lsocket problem On Tue, Nov 09, 2004 at 08:05:40PM +0100, Knut St. Osmundsen wrote: > If NSPR4 is not linked with TCPIP32 things should be ok. > > The generic way of checking which libraries was included are: > - Check the ilink map file (ld mapfiles are not useful) > - Enable tracing of the linking process using the "-t" option > of gcc/ld/emxomfld. > > The typical trouble you'll see when linking with the wrong library is > associated with errno values of EPFNOSUPPORT and EAFNOSUPPORT. I not too familiar with all these utilities. What can I run against nspr4.dll to show the socket library it is linked with? If I look at the file with a file viewer I can see the embedded path D:\gcc322\lib\libsocket.lib which suggests I am using the correct one. > Kind Regards, > knut -- John **= Email 21 ==========================** Date: Tue, 9 Nov 2004 20:00:58 +0000 From: John Poltorak Subject: Re: Large file support in Python On Tue, Nov 09, 2004 at 07:57:09PM +0100, Knut St. Osmundsen wrote: > Andrew, I were wondering (and I think Adrian (Mr. Netlabs) is too) how > tighly the Phython port is tied to EMX, and/or how much OS/2 specific > changes has been done. The idea (which was Adrian's, not mine) was get > it building with the new libc/gcc, and use the result (once I've fixed > any LIBC issues which surfaced) to port the gentoo portage to OS/2. > And on the topic, by using the new libc/gcc 64-bit should work > automatically. I don't claim to be an authority on Python but just grepping through the tarball would suggest there aren't many references to EMX in the C source files, so if it is easier to wait for large file support through libc than to alter the Python source it's probably better to wait, but it means changing over one's development tools to gcc 3.3.4 and that migration might not be painless... > Kind Regards, > knut -- John **= Email 22 ==========================** Date: Tue, 09 Nov 2004 11:54:21 -0800 From: "Steven Levine" Subject: Re: Removing RO during 'tar -x' In <20041109184841.E84 at warpix.org>, on 11/09/04 at 06:48 PM, John Poltorak said: >Doesn't this update the attributes of every single file from the current >directory down? Yes. That's what I was missing. The start of this thread is long gone from my archives. You only want to change the files in the current directory. tar'ed files almost always have subdirectories. >More often than not there won't be any files set RO at all. True, but it's often faster to ignore this and let the OS sort this out. If you really want to to limit the find to just RO files, you can use the messy: find . -type f ( -perm -u-w -o -perm -g-w -o -perm -o-w ) To limit your selection to the current directory, I usually use something like: ls -l | sed -n '/^d/d;/^..-/p' | cut -c34- | xargs -n50 chmod +w This is from memory, so watch for typos. This is often much faster that find because there's no easy way to keep find out of subdirectories. >Not being a FIND aficionado myself, can you explain the -n and -s >parameters to xargs? Google for xargs man page Steven -- ---------------------------------------------------------------------- "Steven Levine" MR2/ICE 2.60b #10183 Warp4/FP15/14.093c_W4 www.scoug.com irc.fyrelizard.com #scoug (Wed 7pm PST) ---------------------------------------------------------------------- **= Email 23 ==========================** Date: Wed, 10 Nov 2004 07:15:05 +1030 From: Paul Smedley Subject: Re: Large file support in Python Hi Knut, Knut St. Osmundsen wrote: > Andrew, I were wondering (and I think Adrian (Mr. Netlabs) is too) how > tighly the Phython port is tied to EMX, and/or how much OS/2 specific > changes has been done. The idea (which was Adrian's, not mine) was get > it building with the new libc/gcc, and use the result (once I've fixed > any LIBC issues which surfaced) to port the gentoo portage to OS/2. > And on the topic, by using the new libc/gcc 64-bit should work > automatically. I got this mostly compiling with your GCC 3.2.2 a while back - from memory it was dying at linking stage as alarm wasn't implemented yet in libc... Cheers, Paul. **= Email 24 ==========================** Date: Tue, 09 Nov 2004 16:32:09 -0500 From: Henry Sobotka Subject: Re: -lsocket problem OK, I think I see what's happening. If you run gccenv.cmd first and then setmozenv.cmd, LIBRARY_PATH ends up with /lib/tcpipv4 first so its libsocket.lib gets used. If you run setmozenv.cmd first and then gccenv.cmd, the one in /lib comes first. h~ **= Email 25 ==========================** Date: Wed, 10 Nov 2004 01:16:35 +0100 From: "Knut St. Osmundsen" Subject: Re: -lsocket problem John Poltorak wrote: > On Tue, Nov 09, 2004 at 08:05:40PM +0100, Knut St. Osmundsen wrote: > > >>If NSPR4 is not linked with TCPIP32 things should be ok. >> >>The generic way of checking which libraries was included are: >> - Check the ilink map file (ld mapfiles are not useful) >> - Enable tracing of the linking process using the "-t" option >> of gcc/ld/emxomfld. >> >>The typical trouble you'll see when linking with the wrong library is >>associated with errno values of EPFNOSUPPORT and EAFNOSUPPORT. > > > I not too familiar with all these utilities. What can I run against > nspr4.dll to show the socket library it is linked with? > > If I look at the file with a file viewer I can see the embedded path > D:\gcc322\lib\libsocket.lib which suggests I am using the correct one. I didn't follow all of the other threads about building mozilla, but did you change the setup to not defined TCPV40HDRS? If you did lib/libsocket.lib is correct. If you didn't, that's where it goes wrong. The default for mozilla is to define TCPV40HDRS and link with lib/tcpipv4/libsocket.lib. This is because mozilla may actually be used on machines with older tcpip stacks (v4.0). Kind Regards, knut **= Email 26 ==========================** Date: Wed, 10 Nov 2004 01:10:38 +0100 From: "Knut St. Osmundsen" Subject: Re: Large file support in Python Paul Smedley wrote: > Hi Knut, > > Knut St. Osmundsen wrote: > >> Andrew, I were wondering (and I think Adrian (Mr. Netlabs) is too) how >> tighly the Phython port is tied to EMX, and/or how much OS/2 specific >> changes has been done. The idea (which was Adrian's, not mine) was get >> it building with the new libc/gcc, and use the result (once I've fixed >> any LIBC issues which surfaced) to port the gentoo portage to OS/2. >> And on the topic, by using the new libc/gcc 64-bit should work >> automatically. > > > I got this mostly compiling with your GCC 3.2.2 a while back - from > memory it was dying at linking stage as alarm wasn't implemented yet in > libc... > Ah! That's very encouraging. alarm() next on the todo list (after SIGCHLD / wait*()). Kind Regards, knut **= Email 27 ==========================** Date: Wed, 10 Nov 2004 09:03:05 +0000 (GMT) From: "Dave Saville" Subject: Re: Removing RO during 'tar -x' On Tue, 9 Nov 2004 11:18:46 +0000, John Poltorak wrote: >> find . -type f | xargs ls -l | cut -c 34- |xargs chmod +w > >You could make it even more convoluted by inserting "|grep ^^..-" ;-) > >but it could be just the thing I'm looking for, so thanks for coming up >with it. > >It's funny, but I always thought Unix was much slicker with such tasks but >in this case 'dir /a:r /s /b' seems much easier. Sorry I missed the grep when I cut n pasted :-( And to answer another poster's query - using find -exec chmod will run chmod for every file, whilst this way it gets run once with a file list. -- Regards Dave Saville **= Email 28 ==========================** Date: Wed, 10 Nov 2004 21:22:09 +1100 (EST) From: Andrew MacIntyre Subject: Re: Large file support in Python On Tue, 9 Nov 2004, Knut St. Osmundsen wrote: > John Poltorak wrote: > > On Tue, Nov 09, 2004 at 10:14:43PM +1100, Andrew MacIntyre wrote: > > > >>On Mon, 8 Nov 2004, John Poltorak wrote: > >> > >> > >>>Can we expect large file support in Python in the near future? > >> > >>Define "near"... ;-) > > > > > > Within the next three months... > > > > > >>Its a high priority for me to get large file support added, but I've had > >>little time or energy over last couple of months to devote to the work > >>:-( > > > > > > Yes, I know the feeling. > > Me too :) > > Andrew, I were wondering (and I think Adrian (Mr. Netlabs) is too) how > tighly the Phython port is tied to EMX, and/or how much OS/2 specific > changes has been done. The idea (which was Adrian's, not mine) was get > it building with the new libc/gcc, and use the result (once I've fixed > any LIBC issues which surfaced) to port the gentoo portage to OS/2. > And on the topic, by using the new libc/gcc 64-bit should work > automatically. The EMX port of Python sets out to use as much Posix code, and therefore as much of EMX's Posixish libc, as possible. There are of course a number things that EMX has "native" rather than Posix functionality (eg, threads, mutexes), or no support at all. In these cases EMX "native" support is used where available & easily used, and OS/2 API calls otherwise. The only thing that comes to mind as being potentially problematic is the threads support, which uses EMX's "native" threads support and EMX fmutexes. If the Innotek libc includes a viable pthreads lookalike, this may work - I did try Anthony Curtis' pthreads lib (derived from FreeBSD), but wasn't confident in the reliability so stuck with the EMX API code (which is from AndyZ's EMX port of Python 1.5.2, modulo some bug fixes). The Python source itself is large_file ready, and has been for quite some time. I have been working on a shim library that will support large_file access on systems that support it, and delegate to the standard EMX functions on other systems, so that the binary distribution is widely usable on a range of OS versions. If there is already code that emulates the *BSD/Linux largefile API (in Posix/2?) then it should be straightforward to build a large_file enabled Python interpreter - add defines for HAVE_LARGEFILE_SUPPORT and HAVE_FSEEKO/HAVE_FSEEK64 to PC/os2emx/pyconfig.h. I have had in mind to attempt to build the port with the Innotek compiler/libc, but have been deferring until the package was a bit further advanced (and I have more time...). ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac at pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 29 ==========================** Date: Wed, 10 Nov 2004 10:34:24 +0000 From: John Poltorak Subject: Debugging tar How do I set about debugging GNU TAR 1.14 which builds out of the box and runs but core dumps in the process? -- John **= Email 30 ==========================** Date: Wed, 10 Nov 2004 21:32:40 +1030 From: Paul Smedley Subject: Re: Large file support in Python Hi Andrew, Andrew MacIntyre wrote: > I have had in mind to attempt to build the port with the Innotek > compiler/libc, but have been deferring until the package was a bit further > advanced (and I have more time...). To see my experience, check out http://ubb.innotek.de/ultimatebb.php?ubb=get_topic;f=32;t=000018 Cheers/2 Paul. **= Email 31 ==========================** Date: Wed, 10 Nov 2004 12:02:19 +0000 From: John Poltorak Subject: \n conversion with TR Is it possible to convert Unix newlines to CRLF using TR from the GNU Text Utilities? -- John **= Email 32 ==========================** Date: Wed, 10 Nov 2004 12:25:02 +0000 (GMT) From: "Dave Saville" Subject: Re: \n conversion with TR On Wed, 10 Nov 2004 12:02:19 +0000, John Poltorak wrote: >Is it possible to convert Unix newlines to CRLF using TR from the GNU Text >Utilities? Dunno, but: 1) Has no one ported unix2dos and dos2unix? 2) ftp in text mode will fix this. 3) zip can fix it as well. -l convert LF to CR LF (-ll CR LF to LF) 4) Maybe tar too. HTH -- Regards Dave Saville