Date: Wed, 10 Nov 2004 00:04:17 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 443 ************************************************** Tuesday 09 November 2004 Number 443 ************************************************** Subjects for today 1 Re: invalid use of undefined type `struct re_pattern_buffer' : John Poltorak 2 LongLink in tar files : John Poltorak 3 GCC 3.3.5 / alpha 3 - delayed : Knut St. Osmundsen" 4 Re: Removing RO during 'tar -x' : Dave Saville" 5 Large file support in Python : John Poltorak 6 Re: -lsocket problem : Henry Sobotka 7 Re: Removing RO during 'tar -x' : Dave Saville" 8 Updated tar needed : John Poltorak 9 Re: Updated tar needed : Stefan.Neis at t-online.de 10 Re: Removing RO during 'tar -x' : John Poltorak 11 Re: Large file support in Python : Andrew MacIntyre 12 Re: Large file support in Python : Andrew MacIntyre 13 Re: Large file support in Python : John Poltorak **= Email 1 ==========================** Date: Mon, 8 Nov 2004 13:37:44 +0000 From: John Poltorak Subject: Re: invalid use of undefined type `struct re_pattern_buffer' On Sun, Nov 07, 2004 at 05:26:56PM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > Not sure where this structure should be defined... > > It's in regex.h and diff.h includes regex.h. If you don't have regex.h > in the same src directory, you should be getting a "no such file" warning. I have a regex.h in /usr/include which originates from glibc. In the lib directory of diffutils (2.8.1) there is a regex.hin (no regex.h). I think regex.hin gets copied as regex.h under some circumstanes probably determine by configure. I had '--without-included-regex which must have caused this problem. I'll try again but without that parameter this time. > h~ -- John **= Email 2 ==========================** Date: Mon, 8 Nov 2004 14:42:07 +0000 From: John Poltorak Subject: LongLink in tar files What exactly are the LongLink entries shown in tar files? They appear when running 'tar tf' but there is no such file on extraction. I know there are restrictions in tar v1.10 which do not allow long directory names to be extracted correctly, but is there any way to grab the full name out of the tar archive somehow. I just don't get the point of these ././ at LongLink entries apart from marking the position of files whose names have been truncated. -- John **= Email 3 ==========================** Date: Mon, 08 Nov 2004 17:22:50 +0100 From: "Knut St. Osmundsen" Subject: GCC 3.3.5 / alpha 3 - delayed Hi, I hoped to get a new build out this weekend but didn't manage to finish it in time I'm afraid. Had to stop halfway thru the wait/waitpid/waitid/SIGCHLD implementation. Given my work schedule this week, I doubt I will get a chance to do anything before the weekend. On the bright side, I'll kick out the timebomb once I've done the above mentioned wait stuff. Kind Regards, knut **= Email 4 ==========================** Date: Mon, 08 Nov 2004 18:55:08 +0000 (GMT) From: "Dave Saville" Subject: Re: Removing RO during 'tar -x' >> ls -lR |grep ^^..-|cut -c 34-|xargs chmod +w > >Whilst the first part will identify the correct files it won't provide the >same output as:- > >dir /a:r /s /b > >No path information is available to chmod. Maybe there are addition >parameters available to ls... Sorry. Use the find -perm someone posted earlier instead of the ls and figure out what the cut needs to be if anything. -- Regards Dave Saville **= Email 5 ==========================** Date: Mon, 8 Nov 2004 20:47:07 +0000 From: John Poltorak Subject: Large file support in Python Can we expect large file support in Python in the near future? -- John **= Email 6 ==========================** Date: Mon, 08 Nov 2004 21:50:51 -0500 From: Henry Sobotka Subject: Re: -lsocket problem 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. h~ **= Email 7 ==========================** Date: Tue, 09 Nov 2004 07:52:08 +0000 (GMT) From: "Dave Saville" Subject: Re: Removing RO during 'tar -x' On Mon, 08 Nov 2004 18:55:08 +0000 (GMT), Dave Saville wrote: >>> ls -lR |grep ^^..-|cut -c 34-|xargs chmod +w >> >>Whilst the first part will identify the correct files it won't provide the >>same output as:- >> >>dir /a:r /s /b >> >>No path information is available to chmod. Maybe there are addition >>parameters available to ls... > >Sorry. > >Use the find -perm someone posted earlier instead of the ls and >figure out what the cut needs to be if anything. 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 -- Regards Dave Saville **= Email 8 ==========================** Date: Tue, 9 Nov 2004 10:51:14 +0000 From: John Poltorak Subject: Updated tar needed It is becoming increasingly difficult to work with the OS/2 port of tar for two reasons I'm aware of - the limit of of pathnames being 100 characters - this makes porting the latest Zope impossible, and the inability of tar to be able to extract BZIPed files. It looks like we won't be able to get hold of the source for the ported version so we'll have to forget about things like support for EAs and ACLs and whatever other OS/2 specific features are available. Does anyone know what problems are likely to arise in trying to build the most recent GNU version (1.14) ? -- John **= Email 9 ==========================** Date: Tue, 09 Nov 2004 12:09:41 +0100 (CET) From: Stefan.Neis at t-online.de Subject: Re: Updated tar needed 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. > 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". Regards, Stefan **= Email 10 ==========================** Date: Tue, 9 Nov 2004 11:18:46 +0000 From: John Poltorak Subject: Re: Removing RO during 'tar -x' On Tue, Nov 09, 2004 at 07:52:08AM +0000, Dave Saville wrote: > On Mon, 08 Nov 2004 18:55:08 +0000 (GMT), Dave Saville wrote: > > >>> ls -lR |grep ^^..-|cut -c 34-|xargs chmod +w > >> > >>Whilst the first part will identify the correct files it won't provide the > >>same output as:- > >> > >>dir /a:r /s /b > >> > >>No path information is available to chmod. Maybe there are addition > >>parameters available to ls... > > > >Sorry. > > > >Use the find -perm someone posted earlier instead of the ls and > >figure out what the cut needs to be if anything. > > 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 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. > -- > Regards > > Dave Saville > -- John **= Email 11 ==========================** Date: Tue, 9 Nov 2004 22:14:43 +1100 (EST) From: Andrew MacIntyre Subject: Re: Large file support in Python On Mon, 8 Nov 2004, John Poltorak wrote: > Can we expect large file support in Python in the near future? Define "near"... ;-) 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 :-( ------------------------------------------------------------------------- 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 12 ==========================** Date: Tue, 9 Nov 2004 22:14:43 +1100 (EST) From: Andrew MacIntyre Subject: Re: Large file support in Python On Mon, 8 Nov 2004, John Poltorak wrote: > Can we expect large file support in Python in the near future? Define "near"... ;-) 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 :-( ------------------------------------------------------------------------- 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 13 ==========================** Date: Tue, 9 Nov 2004 12:21:20 +0000 From: John Poltorak Subject: Re: Large file support in Python 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. > ------------------------------------------------------------------------- > 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 -- John