Date: Sat, 30 Jul 2005 00:05:20 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 590 ************************************************** Friday 29 July 2005 Number 590 ************************************************** Subjects for today 1 Re: Drive letters in *nix ports : Dave Saville" 2 Re: Drive letters in *nix ports : Illya Vaes 3 Re: Drive letters in *nix ports : Yuri Dario" 4 Re: Drive letters in *nix ports : Andreas Buening 5 Re: Drive letters in *nix ports : Knut St. Osmundsen" 6 Re: Drive letters in *nix ports : John Poltorak 7 CPAN - again... : John Poltorak 8 Re: Drive letters in *nix ports : Paul Smedley **= Email 1 ==========================** Date: Thu, 28 Jul 2005 16:53:23 +0100 (BST) From: "Dave Saville" Subject: Re: Drive letters in *nix ports On Thu, 28 Jul 2005 11:57:21 +0200, illya at vaeshiep.demon.nl wrote: >Quoting Paul Smedley : >>>> /* Define on systems for which file names may have a so-called >>>> `drive letter' >>>> prefix, define this to compute the length of that prefix, including the >>>> colon. */ >>>> #define FILE_SYSTEM_ACCEPTS_DRIVE_LETTER_PREFIX 1 >>> Then the length should be _2_ ('C' AND the colon ':'). >> I thought the same thing at first - but checked configure for >> dos/windows - and it's set to 1 on those playforms. > >In that case the comment is broken :-) > > Er it says define to compute length. It does not say it *is* the length - I would guess it is just a true/false switch for later on. -- Regards Dave Saville **= Email 2 ==========================** Date: Thu, 28 Jul 2005 20:53:02 CET From: Illya Vaes Subject: Re: Drive letters in *nix ports ** Reply to note from "Dave Saville" Thu, 28 Jul 2005 16:53:23 +0100 (BST) >>Quoting Paul Smedley : >>>>> /* Define on systems for which file names may have a so-called >>>>> `drive letter' >>>>> prefix, define this to compute the length of that prefix, including the >>>>> colon. */ >>>>> #define FILE_SYSTEM_ACCEPTS_DRIVE_LETTER_PREFIX 1 >>>> Then the length should be _2_ ('C' AND the colon ':'). >>> I thought the same thing at first - but checked configure for >>> dos/windows - and it's set to 1 on those playforms. >>In that case the comment is broken :-) >Er it says define to compute length. It does not say it *is* the length - I >would guess it is just a true/false switch for later on. Ah, I see what you (and the comment) mean(s)... Sorry, being dense. **= Email 3 ==========================** Date: Thu, 28 Jul 2005 22:23:23 +0200 (CDT) From: "Yuri Dario" Subject: Re: Drive letters in *nix ports Hi, >#define FILE_SYSTEM_ACCEPTS_DRIVE_LETTER_PREFIX 1 with gcc3.3.5 rc1 the behaviour of chdir has been changed to be the same of chdir2; maybe this could lead to problems in drive name splitting. Bye, Yuri Dario /* * member of TeamOS/2 - Italy * http://www.os2power.com/yuri * http://www.teamos2.it */ **= Email 4 ==========================** Date: Thu, 28 Jul 2005 22:32:19 +0200 From: Andreas Buening Subject: Re: Drive letters in *nix ports Paul Smedley wrote: > Dave Yeo wrote: > > Did you try the EMX solution? These may be slightly different under Innotek_libc and the code will most likely still need tweeking, see the EMX Developers Guide. > > #define getcwd _getcwd2 > > #define chdir _chdir2 > > Yeah I tried adding them to config.h - and got an error as follows: > U:/USR/include/stdlib.h:443: error: conflicting types for `_getcwd2' > U:/USR/include/stdlib.h:381: error: previous declaration of `_getcwd2' You'll have to define it _after_ you've included the headers because getcwd() and _getcwd2() have a different signature. Bye, Andreas **= Email 5 ==========================** Date: Thu, 28 Jul 2005 23:16:33 +0200 From: "Knut St. Osmundsen" Subject: Re: Drive letters in *nix ports Andreas Buening wrote: > Paul Smedley wrote: > >> Dave Yeo wrote: > > >>> Did you try the EMX solution? These may be slightly different >>> under Innotek_libc and the code will most likely still need >>> tweeking, see the EMX Developers Guide. #define getcwd _getcwd2 >>> #define chdir _chdir2 As already mentioned, getcwd == _getcwd2 and chdir == _chdir2 in LIBC. _getcwdux will give you a path without a drive letter in it is sometimes useful to redefine getcwd to this. chdir will change drive as well, use _chdir_os2 to avoid changing the drive letter. >> Yeah I tried adding them to config.h - and got an error as follows: >> U:/USR/include/stdlib.h:443: error: conflicting types for >> `_getcwd2' U:/USR/include/stdlib.h:381: error: previous declaration >> of `_getcwd2' > > > You'll have to define it _after_ you've included the headers because > getcwd() and _getcwd2() have a different signature. I will add #ifdef's around getcwd (and chdir) so you can redefine it without getting this problem. It is also possible to override it by providing a wrapper implementation in some source which is linked into all the binaries (this will also work for staticly linked LIBC): int getcwd(char *buf, size_t bufsize){return _getcwdux(buf, bufsize);} Kind Regards, knut **= Email 6 ==========================** Date: Fri, 29 Jul 2005 10:43:29 +0100 From: John Poltorak Subject: Re: Drive letters in *nix ports On Thu, Jul 28, 2005 at 10:32:19PM +0200, Andreas Buening wrote: > Paul Smedley wrote: > > Dave Yeo wrote: > > > > Did you try the EMX solution? These may be slightly different under Innotek_libc and the code will most likely still need tweeking, see the EMX Developers Guide. > > > #define getcwd _getcwd2 > > > #define chdir _chdir2 > > > > Yeah I tried adding them to config.h - and got an error as follows: > > U:/USR/include/stdlib.h:443: error: conflicting types for `_getcwd2' > > U:/USR/include/stdlib.h:381: error: previous declaration of `_getcwd2' > > You'll have to define it _after_ you've included the headers because > getcwd() and _getcwd2() have a different signature. Have you tried building the latest version of tar (using gcc 2.8.1) ? I would really like to drop GTAK as far as my build environment goes because of it's inherent limitations. > Bye, > Andreas -- John **= Email 7 ==========================** Date: Fri, 29 Jul 2005 10:48:57 +0100 From: John Poltorak Subject: CPAN - again... I've spent many hours trying to get the Perl CPAN module working without success, and wondered if anyone else could provide a clue as to why WGET is not retrieving files correctly. It would appear that the WGET command line which is built up is introducing errors but I can't figure out what is wrong. I could do with some help from any Perl gurus. -- John **= Email 8 ==========================** Date: Fri, 29 Jul 2005 20:28:41 +0930 From: Paul Smedley Subject: Re: Drive letters in *nix ports Hi All, Knut St. Osmundsen wrote: > Andreas Buening wrote: >> Paul Smedley wrote: >> >>> Dave Yeo wrote: >> >> >>>> Did you try the EMX solution? These may be slightly different >>>> under Innotek_libc and the code will most likely still need >>>> tweeking, see the EMX Developers Guide. #define getcwd _getcwd2 >>>> #define chdir _chdir2 > > As already mentioned, getcwd == _getcwd2 and chdir == _chdir2 in LIBC. > _getcwdux will give you a path without a drive letter in it is sometimes > useful to redefine getcwd to this. chdir will change drive as well, use > _chdir_os2 to avoid changing the drive letter. > >>> Yeah I tried adding them to config.h - and got an error as follows: >>> U:/USR/include/stdlib.h:443: error: conflicting types for >>> `_getcwd2' U:/USR/include/stdlib.h:381: error: previous declaration >>> of `_getcwd2' >> >> >> You'll have to define it _after_ you've included the headers because >> getcwd() and _getcwd2() have a different signature. > > I will add #ifdef's around getcwd (and chdir) so you can redefine it > without getting this problem. It is also possible to override it by > providing a wrapper implementation in some source which is linked into > all the binaries (this will also work for staticly linked LIBC): > > int getcwd(char *buf, size_t bufsize){return _getcwdux(buf, bufsize);} FWIW - using the --force-local switch on tar makes the problem go away.. from the help - 'archive file is local even if has a colon' so I just created an untar.cmd with: at tar -xvf %1 --force-local I'm sure that some of the suggested solutions are more elegant - but this is working :) and it works fine - and no LONGLINK errors :) Cheers, Paul.