From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sun, 5 Jan 2003 04:47:24 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 4 ************************************************** Saturday 04 January 2003 Number 4 ************************************************** Subjects for today 1 Re: gcc and Mozilla : Kenn Yuill" 2 Re: gcc and Mozilla : Kenn Yuill" 3 ZopeBook.inf : Ted Sikora 4 ZopeBook.inf : Ted Sikora 5 Perl build hang : John Poltorak 6 Perl build hang : John Poltorak 7 Re: Drive letters : John Poltorak 8 Re: Drive letters : John Poltorak 9 Re: bpbatch : Ken Ames 10 Re: bpbatch : Ken Ames 11 Re: Drive letters : John Poltorak 12 Re: Drive letters : John Poltorak 13 Re: bpbatch : Ken Ames 14 Re: bpbatch : Ken Ames 15 Re: INETD & BOOTPD : John Poltorak 16 Re: INETD & BOOTPD : John Poltorak 17 Python scripts : John Poltorak 18 Python scripts : John Poltorak 19 realtime chat : Ken Ames 20 realtime chat : Ken Ames 21 bpbatch : John Poltorak 22 bpbatch : John Poltorak 23 Re: header problems? : Stefan Neis 24 Re: header problems? : Stefan Neis 25 Re: gcc and Mozilla : Stefan Neis 26 Re: gcc and Mozilla : Stefan Neis 27 Re: bpbatch : John Poltorak 28 Re: bpbatch : John Poltorak 29 Re: INETD & BOOTPD : Nicholas Sheppard 30 Re: INETD & BOOTPD : Nicholas Sheppard 31 Re: Perl build hang : John Poltorak 32 Re: Perl build hang : John Poltorak 33 Re: Perl build hang : Stefan Neis 34 Re: Perl build hang : Stefan Neis 35 Re: Perl build hang : Lyn St George" 36 Re: Perl build hang : Lyn St George" 37 Re: Drive letters : Nicholas Sheppard 38 Re: Drive letters : Nicholas Sheppard 39 Re: shadow-4.0.3 passwords : Thomas Hoffmann 40 Re: shadow-4.0.3 passwords : Thomas Hoffmann 41 [Fwd: failure notice]was: R : Thomas Hoffmann 42 [Fwd: failure notice]was: R : Thomas Hoffmann **= Email 1 ==========================** Date: Sun, 5 Jan 2003 04:14:33 -0500 From: "Kenn Yuill" Subject: Re: gcc and Mozilla ** Reply to message from John Poltorak on Sat, 4 Jan 2003 21:34:28 +0000 Hello John, Excuse my intrusion, but I could not resist a comment on your apt and amusing comparison of cats and OS/2 enthusiasts. Herding cats is nigh to impossible, but enticing them is often successful, or to paraphrase a line from "Field of Dreams", if you articulate it well, they will come. Now, back to the regularly scheduled subjects of substance ...... __________________ Quoted Excerpts Below __________________  I think 'prioritising' goals for a disparate group of OS/2 enthusiasts is  like herding cats :-)... -- Ciao, Kenn Have a safe, peaceful & prosperous 2003! __________________________________________________________ Always act as if life is a joyous journey. Kenn Yuill Warp 4.5 IBM Java 1.18 Polarbar Team Tester Links Browser __________________________________________________________ - A Thought for Today - 05 Jan 2003 Indecision is the key to flexibility. - Chuck McKinnis, Covenant Sol'ns **= Email 2 ==========================** Date: Sun, 5 Jan 2003 04:14:33 -0500 From: "Kenn Yuill" Subject: Re: gcc and Mozilla ** Reply to message from John Poltorak on Sat, 4 Jan 2003 21:34:28 +0000 Hello John, Excuse my intrusion, but I could not resist a comment on your apt and amusing comparison of cats and OS/2 enthusiasts. Herding cats is nigh to impossible, but enticing them is often successful, or to paraphrase a line from "Field of Dreams", if you articulate it well, they will come. Now, back to the regularly scheduled subjects of substance ...... __________________ Quoted Excerpts Below __________________  I think 'prioritising' goals for a disparate group of OS/2 enthusiasts is  like herding cats :-)... -- Ciao, Kenn Have a safe, peaceful & prosperous 2003! __________________________________________________________ Always act as if life is a joyous journey. Kenn Yuill Warp 4.5 IBM Java 1.18 Polarbar Team Tester Links Browser __________________________________________________________ - A Thought for Today - 05 Jan 2003 Indecision is the key to flexibility. - Chuck McKinnis, Covenant Sol'ns **= Email 3 ==========================** Date: Sun, 05 Jan 2003 08:19:21 -0500 From: Ted Sikora Subject: ZopeBook.inf Jeff converted The Zope Book to .inf format ftp://os2ports.com/pub/os2/unix/internet/Zope/ZopeBook-inf.zip It's also included in an updated bin Zope261b1-os2emx-030105.zip ftp://os2ports.com/pub/os2/unix/internet/Zope/Zope261b1-os2emx-030105.zip -- Ted Sikora tsikora at ntplx.net **= Email 4 ==========================** Date: Sun, 05 Jan 2003 08:19:21 -0500 From: Ted Sikora Subject: ZopeBook.inf Jeff converted The Zope Book to .inf format ftp://os2ports.com/pub/os2/unix/internet/Zope/ZopeBook-inf.zip It's also included in an updated bin Zope261b1-os2emx-030105.zip ftp://os2ports.com/pub/os2/unix/internet/Zope/Zope261b1-os2emx-030105.zip -- Ted Sikora tsikora at ntplx.net **= Email 5 ==========================** Date: Sun, 5 Jan 2003 09:54:57 +0000 From: John Poltorak Subject: Perl build hang I have built Perl successfully many times in the past using a stndard build script, but now, for some reason all attempts result in a hand when running through the tests. The hang always takes place at this point:- ext/IO/lib/IO/t/io_sock..............accept failed: Connection timed out at ../ext/IO/lib/IO/t/io_sock.t line 61. ------------------------------------------------------------------ $port = $listen->sockport; if($pid = fork()) { $sock = $listen->accept() or die "accept failed: $!"; <====== line 61 print "ok 2\n"; $sock->autoflush(1); print $sock->getline(); print $sock "ok 4\n"; $sock->close; waitpid($pid,0); print "ok 5\n"; } elsif(defined $pid) { ------------------------------------------------------------------ Can anyone suggest why this is happening? AFAICT, I am using exactly the same environment as I was when this did not happen, and the same thing also happens on another test machine. -- John **= Email 6 ==========================** Date: Sun, 5 Jan 2003 09:54:57 +0000 From: John Poltorak Subject: Perl build hang I have built Perl successfully many times in the past using a stndard build script, but now, for some reason all attempts result in a hand when running through the tests. The hang always takes place at this point:- ext/IO/lib/IO/t/io_sock..............accept failed: Connection timed out at ../ext/IO/lib/IO/t/io_sock.t line 61. ------------------------------------------------------------------ $port = $listen->sockport; if($pid = fork()) { $sock = $listen->accept() or die "accept failed: $!"; <====== line 61 print "ok 2\n"; $sock->autoflush(1); print $sock->getline(); print $sock "ok 4\n"; $sock->close; waitpid($pid,0); print "ok 5\n"; } elsif(defined $pid) { ------------------------------------------------------------------ Can anyone suggest why this is happening? AFAICT, I am using exactly the same environment as I was when this did not happen, and the same thing also happens on another test machine. -- John **= Email 7 ==========================** Date: Sun, 5 Jan 2003 10:42:59 +0000 From: John Poltorak Subject: Re: Drive letters On Sat, Jan 04, 2003 at 04:32:27AM -0500, Henry Sobotka wrote: Long time no post, Henry. I was worried that you may have strayed :-)... > Nonetheless, I think a UNIX-OS/2 system that maps drive letters to their > UNIX-world /dev/ equivalent would be the way to go as opposed to > arbitrary or user-defined naming. Drive letters represent real locations > on hardware that UNIX-OS/2 can and should respect For instance, if John > builds Perl with prefix=/usr/bin, '/' should mean "c:/" or "k:/" or > "z:/" or wherever he mounted '/' for him, and ditto for the user who > downloads his distribution. Just as it's really an abbreviaion for some > "/dev/*/" mount point in the UNIX world. The problem of incorporating drive letters into a Unix-like environment on OS/2 will remain until someone produces a little bit of magic to simplify the whole process and I'm sure there are only a few peole who can produce such magic - I'm certainly not one of them. However absence of this magic should not prevent us from carrying on with bringing UnixOS/2 uptodate using our existing crude methods of handling drive letters by incorporating hard coded paths which use prefix=c:/usr. Whilst this is awkward, it does work from any drive, even though it will not necessarily work for everyone. However they do have the option to rebuild using their preferred %UNIXROOT% drive. Maybe we can come up with a way for the installer to patch %UNIXROOT% so that any hardcoded paths are altered during the install... In general, I don't see drive letters to be a major hurdle, apart from their use within PASSWD where the ':' delimiter has two meanings, so an alternative has to be chosen. That in itself is not so much of a problem, because we have a means of handling it. Unfortunately we have conflicting solutions both of which have become fairly entrenched because they have been around for such a long time, and we really need to come up with a single standard. It would be nice to be able to use something now without being dependent on some magic in the future, although being able to incorporate future developments would be good. > h~ -- John **= Email 8 ==========================** Date: Sun, 5 Jan 2003 10:42:59 +0000 From: John Poltorak Subject: Re: Drive letters On Sat, Jan 04, 2003 at 04:32:27AM -0500, Henry Sobotka wrote: Long time no post, Henry. I was worried that you may have strayed :-)... > Nonetheless, I think a UNIX-OS/2 system that maps drive letters to their > UNIX-world /dev/ equivalent would be the way to go as opposed to > arbitrary or user-defined naming. Drive letters represent real locations > on hardware that UNIX-OS/2 can and should respect For instance, if John > builds Perl with prefix=/usr/bin, '/' should mean "c:/" or "k:/" or > "z:/" or wherever he mounted '/' for him, and ditto for the user who > downloads his distribution. Just as it's really an abbreviaion for some > "/dev/*/" mount point in the UNIX world. The problem of incorporating drive letters into a Unix-like environment on OS/2 will remain until someone produces a little bit of magic to simplify the whole process and I'm sure there are only a few peole who can produce such magic - I'm certainly not one of them. However absence of this magic should not prevent us from carrying on with bringing UnixOS/2 uptodate using our existing crude methods of handling drive letters by incorporating hard coded paths which use prefix=c:/usr. Whilst this is awkward, it does work from any drive, even though it will not necessarily work for everyone. However they do have the option to rebuild using their preferred %UNIXROOT% drive. Maybe we can come up with a way for the installer to patch %UNIXROOT% so that any hardcoded paths are altered during the install... In general, I don't see drive letters to be a major hurdle, apart from their use within PASSWD where the ':' delimiter has two meanings, so an alternative has to be chosen. That in itself is not so much of a problem, because we have a means of handling it. Unfortunately we have conflicting solutions both of which have become fairly entrenched because they have been around for such a long time, and we really need to come up with a single standard. It would be nice to be able to use something now without being dependent on some magic in the future, although being able to incorporate future developments would be good. > h~ -- John **= Email 9 ==========================** Date: Sun, 05 Jan 2003 11:20:30 -0800 From: Ken Ames Subject: Re: bpbatch hi John, the whole bpbatch can be grabbed at http://cui.unige.ch/info/pc/remote-boot/soft/bpb-exe.zip. there is some readme and text files inside and the bpbatch.org site has some docs as well. I am going to try this out soon as I get some time. hth Ken John Poltorak wrote: >Has anyone com across bpbatch? > >It's supposed to be a bootfile from which Linux can be booted remotely >over bootp and tftp. I'm trying to get it working from an OS/2 server, but >don't really have a clue how it supposed to work. > >For a start I can't find a file called bpbatch even though Google takes me >to www.bpbatch.org and I can easily identify a bpbatch archive, but it >doesn't contain a file called bpbatch! > > >Argghhhh!!!! > > >So what exactly is this file bpbatch? > > >I see an mrbatch which is an ELF binary. Should I use that? > > > > **= Email 10 ==========================** Date: Sun, 05 Jan 2003 11:20:30 -0800 From: Ken Ames Subject: Re: bpbatch hi John, the whole bpbatch can be grabbed at http://cui.unige.ch/info/pc/remote-boot/soft/bpb-exe.zip. there is some readme and text files inside and the bpbatch.org site has some docs as well. I am going to try this out soon as I get some time. hth Ken John Poltorak wrote: >Has anyone com across bpbatch? > >It's supposed to be a bootfile from which Linux can be booted remotely >over bootp and tftp. I'm trying to get it working from an OS/2 server, but >don't really have a clue how it supposed to work. > >For a start I can't find a file called bpbatch even though Google takes me >to www.bpbatch.org and I can easily identify a bpbatch archive, but it >doesn't contain a file called bpbatch! > > >Argghhhh!!!! > > >So what exactly is this file bpbatch? > > >I see an mrbatch which is an ELF binary. Should I use that? > > > > **= Email 11 ==========================** Date: Sun, 5 Jan 2003 11:54:57 +0000 From: John Poltorak Subject: Re: Drive letters On Sun, Jan 05, 2003 at 10:26:58PM +1100, Nicholas Sheppard wrote: > On Sun, 5 Jan 2003, John Poltorak wrote: > I'm re-writing the passwd code for the next release of ipop3d so that it > will be able to read both the $c and c; formats. If there are any others I > can add them, too. I would like to move to the /dev/* format for writing > new entries, however, for the reasons given by various people on this > list. > > I don't know who else is out there writing or maintaining passwd code, or > what they think might be the way forward. Anyone? The people writing the > code are ultimately the ones who are going to be making the decisions. AFAICT the originators of these two formats (I don't think there are any others) were KUR and AZ. KUR no longer uses OS/2 so there is no further maintenance, but I'm not sure what AZ is doing... As long as one person is maintaining passwd handling, we should be able to resolve any problems. > > Nicholas S. > > > |\ Location: Wollongong, Australia | Neither are any wars so furious and > |\ E-mail: nps at zeta.org.au | bloody, or of so long continuance, as > | WWW: http://www.zeta.org.au/~nps | those occasioned by difference in > | ---> Cynicism & Negativity | opinion, especially if it be in things > indifferent. > > - Jonathon Swift -- John **= Email 12 ==========================** Date: Sun, 5 Jan 2003 11:54:57 +0000 From: John Poltorak Subject: Re: Drive letters On Sun, Jan 05, 2003 at 10:26:58PM +1100, Nicholas Sheppard wrote: > On Sun, 5 Jan 2003, John Poltorak wrote: > I'm re-writing the passwd code for the next release of ipop3d so that it > will be able to read both the $c and c; formats. If there are any others I > can add them, too. I would like to move to the /dev/* format for writing > new entries, however, for the reasons given by various people on this > list. > > I don't know who else is out there writing or maintaining passwd code, or > what they think might be the way forward. Anyone? The people writing the > code are ultimately the ones who are going to be making the decisions. AFAICT the originators of these two formats (I don't think there are any others) were KUR and AZ. KUR no longer uses OS/2 so there is no further maintenance, but I'm not sure what AZ is doing... As long as one person is maintaining passwd handling, we should be able to resolve any problems. > > Nicholas S. > > > |\ Location: Wollongong, Australia | Neither are any wars so furious and > |\ E-mail: nps at zeta.org.au | bloody, or of so long continuance, as > | WWW: http://www.zeta.org.au/~nps | those occasioned by difference in > | ---> Cynicism & Negativity | opinion, especially if it be in things > indifferent. > > - Jonathon Swift -- John **= Email 13 ==========================** Date: Sun, 05 Jan 2003 12:03:25 -0800 From: Ken Ames Subject: Re: bpbatch hi John, I believe the actual file is not called bpbatch but rather mrbatch. as I said, I have not had time yet to start setting this up. you should get hold of the linux remoteboot mini howto and read it and also read bpbatch.org docs, all you can find. good luck to you. Ken John Poltorak wrote: >On Sun, Jan 05, 2003 at 11:20:30AM -0800, Ken Ames wrote: > > >>hi John, >> the whole bpbatch can be grabbed at >>http://cui.unige.ch/info/pc/remote-boot/soft/bpb-exe.zip. there is some >>readme and text files inside and the bpbatch.org site has some docs as >>well. I am going to try this out soon as I get some time. hth >> >> > >Ken, > >This is the same file as the one I downloaded from www.bpbatch.org and it >does not contain a file called bpbatch. Here are the contents:- > > > Length EAs ACLs Date Time Name > -------- --- ---- ---- ---- ---- > 2183 0 0 11-02-00 13:19 bpbatch.P > 60093 0 0 11-02-00 13:19 bpbatch.hlp > 191812 0 0 11-02-00 13:19 bpbatch.ovl > 885 0 0 11-02-00 13:19 install > 3563 0 0 11-02-00 13:19 license > 173607 0 0 11-02-00 13:19 mrbatch > 203190 0 0 11-02-00 13:19 mrbatch.exe > 399536 0 0 11-02-00 13:19 mrbatch.sta > 208763 0 0 11-02-00 13:19 mrzip > 210416 0 0 11-02-00 13:19 mrzip.exe > 429816 0 0 11-02-00 13:19 mrzip.sta > 792 0 0 11-02-00 13:19 readme > 13153 0 0 11-02-00 13:19 scard.txt > 8631 0 0 11-02-00 13:19 whatsnew > -------- ----- ----- ------- > 1906440 0 0 14 files > >This is the README:- > >Document: README >Version : $Id: readme,v 1.3 1999/09/09 13:01:53 david Exp $ >---------------------------------------------------------------------------- > >For explanations about this software, please read the > > Linux Remote-Boot mini-Howto : > Configuring Remote-boot Workstations with > Red-Hat Linux, DOS, Windows 3.1, Windows 95 and Windows NT > > http://www.bpbatch.org/ > >bpb_exe[.zip|.tar.gz] contains executables for DOS and Linux (libc6) > > Note: the linux sources have been compiled under RedHat 5.2 > > > > ********************************************************* > Please read the LICENSE file before using this software > ********************************************************* > > > >I have no idea what people mean when they specify bpbatch as bootfile. >Maybe I need to read the mini-Howto... > > > >>Ken >> >> >>John Poltorak wrote: >> >> >> >>>Has anyone com across bpbatch? >>> >>>It's supposed to be a bootfile from which Linux can be booted remotely >>>over bootp and tftp. I'm trying to get it working from an OS/2 server, but >>>don't really have a clue how it supposed to work. >>> >>>For a start I can't find a file called bpbatch even though Google takes me >>>to www.bpbatch.org and I can easily identify a bpbatch archive, but it >>>doesn't contain a file called bpbatch! >>> >>> >>>Argghhhh!!!! >>> >>> >>>So what exactly is this file bpbatch? >>> >>> >>>I see an mrbatch which is an ELF binary. Should I use that? >>> >>> > > > > **= Email 14 ==========================** Date: Sun, 05 Jan 2003 12:03:25 -0800 From: Ken Ames Subject: Re: bpbatch hi John, I believe the actual file is not called bpbatch but rather mrbatch. as I said, I have not had time yet to start setting this up. you should get hold of the linux remoteboot mini howto and read it and also read bpbatch.org docs, all you can find. good luck to you. Ken John Poltorak wrote: >On Sun, Jan 05, 2003 at 11:20:30AM -0800, Ken Ames wrote: > > >>hi John, >> the whole bpbatch can be grabbed at >>http://cui.unige.ch/info/pc/remote-boot/soft/bpb-exe.zip. there is some >>readme and text files inside and the bpbatch.org site has some docs as >>well. I am going to try this out soon as I get some time. hth >> >> > >Ken, > >This is the same file as the one I downloaded from www.bpbatch.org and it >does not contain a file called bpbatch. Here are the contents:- > > > Length EAs ACLs Date Time Name > -------- --- ---- ---- ---- ---- > 2183 0 0 11-02-00 13:19 bpbatch.P > 60093 0 0 11-02-00 13:19 bpbatch.hlp > 191812 0 0 11-02-00 13:19 bpbatch.ovl > 885 0 0 11-02-00 13:19 install > 3563 0 0 11-02-00 13:19 license > 173607 0 0 11-02-00 13:19 mrbatch > 203190 0 0 11-02-00 13:19 mrbatch.exe > 399536 0 0 11-02-00 13:19 mrbatch.sta > 208763 0 0 11-02-00 13:19 mrzip > 210416 0 0 11-02-00 13:19 mrzip.exe > 429816 0 0 11-02-00 13:19 mrzip.sta > 792 0 0 11-02-00 13:19 readme > 13153 0 0 11-02-00 13:19 scard.txt > 8631 0 0 11-02-00 13:19 whatsnew > -------- ----- ----- ------- > 1906440 0 0 14 files > >This is the README:- > >Document: README >Version : $Id: readme,v 1.3 1999/09/09 13:01:53 david Exp $ >---------------------------------------------------------------------------- > >For explanations about this software, please read the > > Linux Remote-Boot mini-Howto : > Configuring Remote-boot Workstations with > Red-Hat Linux, DOS, Windows 3.1, Windows 95 and Windows NT > > http://www.bpbatch.org/ > >bpb_exe[.zip|.tar.gz] contains executables for DOS and Linux (libc6) > > Note: the linux sources have been compiled under RedHat 5.2 > > > > ********************************************************* > Please read the LICENSE file before using this software > ********************************************************* > > > >I have no idea what people mean when they specify bpbatch as bootfile. >Maybe I need to read the mini-Howto... > > > >>Ken >> >> >>John Poltorak wrote: >> >> >> >>>Has anyone com across bpbatch? >>> >>>It's supposed to be a bootfile from which Linux can be booted remotely >>>over bootp and tftp. I'm trying to get it working from an OS/2 server, but >>>don't really have a clue how it supposed to work. >>> >>>For a start I can't find a file called bpbatch even though Google takes me >>>to www.bpbatch.org and I can easily identify a bpbatch archive, but it >>>doesn't contain a file called bpbatch! >>> >>> >>>Argghhhh!!!! >>> >>> >>>So what exactly is this file bpbatch? >>> >>> >>>I see an mrbatch which is an ELF binary. Should I use that? >>> >>> > > > > **= Email 15 ==========================** Date: Sun, 5 Jan 2003 12:46:50 +0000 From: John Poltorak Subject: Re: INETD & BOOTPD On Sun, Jan 05, 2003 at 08:44:46PM +1100, Nicholas Sheppard wrote: > On Sat, 4 Jan 2003, John Poltorak wrote: > > > Yes, I now see the INETD handling has been commented out for EMX, I just > > wondered if it would be possible to cater for being launched from INETD > > in the same way as you made IPOP3D run from INETD on OS/2... > > I expect so. This is the code to do it from ipop3d: > > { > char *s; > int ibmso,emxso; > if ((s = getenv ("INETDSOCKETHANDLE")) && (ibmso = atoi (s))) { > /* connect inetd's socket to stdin and stdout */ > if ((emxso = _impsockhandle (ibmso,0)) >= 0) { > dup2 (emxso,0); > dup2 (emxso,1); > close (emxso); > } > } > } > > Insert that at the top of main() in bootpd.c, Exactly whereabouts? I'm no expert with C and 'top' can mean different things... > Nicholas S. > > |\ Location: Wollongong, Australia | Neither are any wars so furious and > |\ E-mail: nps at zeta.org.au | bloody, or of so long continuance, as > | WWW: http://www.zeta.org.au/~nps | those occasioned by difference in > | ---> Cynicism & Negativity | opinion, especially if it be in things > indifferent. > > - Jonathon Swift -- John **= Email 16 ==========================** Date: Sun, 5 Jan 2003 12:46:50 +0000 From: John Poltorak Subject: Re: INETD & BOOTPD On Sun, Jan 05, 2003 at 08:44:46PM +1100, Nicholas Sheppard wrote: > On Sat, 4 Jan 2003, John Poltorak wrote: > > > Yes, I now see the INETD handling has been commented out for EMX, I just > > wondered if it would be possible to cater for being launched from INETD > > in the same way as you made IPOP3D run from INETD on OS/2... > > I expect so. This is the code to do it from ipop3d: > > { > char *s; > int ibmso,emxso; > if ((s = getenv ("INETDSOCKETHANDLE")) && (ibmso = atoi (s))) { > /* connect inetd's socket to stdin and stdout */ > if ((emxso = _impsockhandle (ibmso,0)) >= 0) { > dup2 (emxso,0); > dup2 (emxso,1); > close (emxso); > } > } > } > > Insert that at the top of main() in bootpd.c, Exactly whereabouts? I'm no expert with C and 'top' can mean different things... > Nicholas S. > > |\ Location: Wollongong, Australia | Neither are any wars so furious and > |\ E-mail: nps at zeta.org.au | bloody, or of so long continuance, as > | WWW: http://www.zeta.org.au/~nps | those occasioned by difference in > | ---> Cynicism & Negativity | opinion, especially if it be in things > indifferent. > > - Jonathon Swift -- John **= Email 17 ==========================** Date: Sun, 5 Jan 2003 15:23:56 +0000 From: John Poltorak Subject: Python scripts Is it possible to make Python scripts run as command files by inserting EXTPROC in the first line and changing the name to *.CMD? With Perl I just need to use this:- extproc perl -x #!perl What do I need to do with this:- ? #!/usr/bin/python -- John **= Email 18 ==========================** Date: Sun, 5 Jan 2003 15:23:56 +0000 From: John Poltorak Subject: Python scripts Is it possible to make Python scripts run as command files by inserting EXTPROC in the first line and changing the name to *.CMD? With Perl I just need to use this:- extproc perl -x #!perl What do I need to do with this:- ? #!/usr/bin/python -- John **= Email 19 ==========================** Date: Sun, 05 Jan 2003 16:51:38 -0800 From: Ken Ames Subject: realtime chat hi, I am wondering if there is an irc channel also for unixOS2, I hope so as I think it would help some things to move faster. anyway, it is just a thought. Sorry if this has already been discussed here. Ken **= Email 20 ==========================** Date: Sun, 05 Jan 2003 16:51:38 -0800 From: Ken Ames Subject: realtime chat hi, I am wondering if there is an irc channel also for unixOS2, I hope so as I think it would help some things to move faster. anyway, it is just a thought. Sorry if this has already been discussed here. Ken **= Email 21 ==========================** Date: Sun, 5 Jan 2003 17:13:19 +0000 From: John Poltorak Subject: bpbatch Has anyone com across bpbatch? It's supposed to be a bootfile from which Linux can be booted remotely over bootp and tftp. I'm trying to get it working from an OS/2 server, but don't really have a clue how it supposed to work. For a start I can't find a file called bpbatch even though Google takes me to www.bpbatch.org and I can easily identify a bpbatch archive, but it doesn't contain a file called bpbatch! Argghhhh!!!! So what exactly is this file bpbatch? I see an mrbatch which is an ELF binary. Should I use that? -- John **= Email 22 ==========================** Date: Sun, 5 Jan 2003 17:13:19 +0000 From: John Poltorak Subject: bpbatch Has anyone com across bpbatch? It's supposed to be a bootfile from which Linux can be booted remotely over bootp and tftp. I'm trying to get it working from an OS/2 server, but don't really have a clue how it supposed to work. For a start I can't find a file called bpbatch even though Google takes me to www.bpbatch.org and I can easily identify a bpbatch archive, but it doesn't contain a file called bpbatch! Argghhhh!!!! So what exactly is this file bpbatch? I see an mrbatch which is an ELF binary. Should I use that? -- John **= Email 23 ==========================** Date: Sun, 5 Jan 2003 19:18:39 +0100 (CET) From: Stefan Neis Subject: Re: header problems? On Sat, 4 Jan 2003, Ted Sikora wrote: > Tried building Zope with GCC 3.0.3 with the posix2 includes. Failed > miserably on the first module with: > > error L2029 : unresolved external Maybe you forgot to add -lcExt ? -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 24 ==========================** Date: Sun, 5 Jan 2003 19:18:39 +0100 (CET) From: Stefan Neis Subject: Re: header problems? On Sat, 4 Jan 2003, Ted Sikora wrote: > Tried building Zope with GCC 3.0.3 with the posix2 includes. Failed > miserably on the first module with: > > error L2029 : unresolved external Maybe you forgot to add -lcExt ? -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 25 ==========================** Date: Sun, 5 Jan 2003 19:31:08 +0100 (CET) From: Stefan Neis Subject: Re: gcc and Mozilla On Sat, 4 Jan 2003, Jeff Robinson wrote: > but because of "problems" he had backleveled to pgcc 2.95.3 (I > believe)... though of course this has its own problems because it > exhausts the virtual memory due to the size of some of the files (and > their includes) that it is trying to compile. The is where the > suggestion had come in to disable the 'debugs' that Mike Kaply's comment > refers to. That's one of gcc's main problems. It needs lots of memory, not only on OS/2. And if you manage to trigger an internal problem of gcc, you can be happy to get away with only 1GB of memory needed (either to recover and continue or to finally give an error message), no matter what platform. If possible, using -fno-rtti and -fno-exceptions (for all files) as well as not building debug versions of some specific files helps on _all_ platforms to avoid those (not so) rare problems, that's just how things are. :-( Regards, Stefan **= Email 26 ==========================** Date: Sun, 5 Jan 2003 19:31:08 +0100 (CET) From: Stefan Neis Subject: Re: gcc and Mozilla On Sat, 4 Jan 2003, Jeff Robinson wrote: > but because of "problems" he had backleveled to pgcc 2.95.3 (I > believe)... though of course this has its own problems because it > exhausts the virtual memory due to the size of some of the files (and > their includes) that it is trying to compile. The is where the > suggestion had come in to disable the 'debugs' that Mike Kaply's comment > refers to. That's one of gcc's main problems. It needs lots of memory, not only on OS/2. And if you manage to trigger an internal problem of gcc, you can be happy to get away with only 1GB of memory needed (either to recover and continue or to finally give an error message), no matter what platform. If possible, using -fno-rtti and -fno-exceptions (for all files) as well as not building debug versions of some specific files helps on _all_ platforms to avoid those (not so) rare problems, that's just how things are. :-( Regards, Stefan **= Email 27 ==========================** Date: Sun, 5 Jan 2003 19:44:22 +0000 From: John Poltorak Subject: Re: bpbatch On Sun, Jan 05, 2003 at 11:20:30AM -0800, Ken Ames wrote: > hi John, > the whole bpbatch can be grabbed at > http://cui.unige.ch/info/pc/remote-boot/soft/bpb-exe.zip. there is some > readme and text files inside and the bpbatch.org site has some docs as > well. I am going to try this out soon as I get some time. hth Ken, This is the same file as the one I downloaded from www.bpbatch.org and it does not contain a file called bpbatch. Here are the contents:- Length EAs ACLs Date Time Name -------- --- ---- ---- ---- ---- 2183 0 0 11-02-00 13:19 bpbatch.P 60093 0 0 11-02-00 13:19 bpbatch.hlp 191812 0 0 11-02-00 13:19 bpbatch.ovl 885 0 0 11-02-00 13:19 install 3563 0 0 11-02-00 13:19 license 173607 0 0 11-02-00 13:19 mrbatch 203190 0 0 11-02-00 13:19 mrbatch.exe 399536 0 0 11-02-00 13:19 mrbatch.sta 208763 0 0 11-02-00 13:19 mrzip 210416 0 0 11-02-00 13:19 mrzip.exe 429816 0 0 11-02-00 13:19 mrzip.sta 792 0 0 11-02-00 13:19 readme 13153 0 0 11-02-00 13:19 scard.txt 8631 0 0 11-02-00 13:19 whatsnew -------- ----- ----- ------- 1906440 0 0 14 files This is the README:- Document: README Version : $Id: readme,v 1.3 1999/09/09 13:01:53 david Exp $ ---------------------------------------------------------------------------- For explanations about this software, please read the Linux Remote-Boot mini-Howto : Configuring Remote-boot Workstations with Red-Hat Linux, DOS, Windows 3.1, Windows 95 and Windows NT http://www.bpbatch.org/ bpb_exe[.zip|.tar.gz] contains executables for DOS and Linux (libc6) Note: the linux sources have been compiled under RedHat 5.2 ********************************************************* Please read the LICENSE file before using this software ********************************************************* I have no idea what people mean when they specify bpbatch as bootfile. Maybe I need to read the mini-Howto... > Ken > > > John Poltorak wrote: > > >Has anyone com across bpbatch? > > > >It's supposed to be a bootfile from which Linux can be booted remotely > >over bootp and tftp. I'm trying to get it working from an OS/2 server, but > >don't really have a clue how it supposed to work. > > > >For a start I can't find a file called bpbatch even though Google takes me > >to www.bpbatch.org and I can easily identify a bpbatch archive, but it > >doesn't contain a file called bpbatch! > > > > > >Argghhhh!!!! > > > > > >So what exactly is this file bpbatch? > > > > > >I see an mrbatch which is an ELF binary. Should I use that? -- John **= Email 28 ==========================** Date: Sun, 5 Jan 2003 19:44:22 +0000 From: John Poltorak Subject: Re: bpbatch On Sun, Jan 05, 2003 at 11:20:30AM -0800, Ken Ames wrote: > hi John, > the whole bpbatch can be grabbed at > http://cui.unige.ch/info/pc/remote-boot/soft/bpb-exe.zip. there is some > readme and text files inside and the bpbatch.org site has some docs as > well. I am going to try this out soon as I get some time. hth Ken, This is the same file as the one I downloaded from www.bpbatch.org and it does not contain a file called bpbatch. Here are the contents:- Length EAs ACLs Date Time Name -------- --- ---- ---- ---- ---- 2183 0 0 11-02-00 13:19 bpbatch.P 60093 0 0 11-02-00 13:19 bpbatch.hlp 191812 0 0 11-02-00 13:19 bpbatch.ovl 885 0 0 11-02-00 13:19 install 3563 0 0 11-02-00 13:19 license 173607 0 0 11-02-00 13:19 mrbatch 203190 0 0 11-02-00 13:19 mrbatch.exe 399536 0 0 11-02-00 13:19 mrbatch.sta 208763 0 0 11-02-00 13:19 mrzip 210416 0 0 11-02-00 13:19 mrzip.exe 429816 0 0 11-02-00 13:19 mrzip.sta 792 0 0 11-02-00 13:19 readme 13153 0 0 11-02-00 13:19 scard.txt 8631 0 0 11-02-00 13:19 whatsnew -------- ----- ----- ------- 1906440 0 0 14 files This is the README:- Document: README Version : $Id: readme,v 1.3 1999/09/09 13:01:53 david Exp $ ---------------------------------------------------------------------------- For explanations about this software, please read the Linux Remote-Boot mini-Howto : Configuring Remote-boot Workstations with Red-Hat Linux, DOS, Windows 3.1, Windows 95 and Windows NT http://www.bpbatch.org/ bpb_exe[.zip|.tar.gz] contains executables for DOS and Linux (libc6) Note: the linux sources have been compiled under RedHat 5.2 ********************************************************* Please read the LICENSE file before using this software ********************************************************* I have no idea what people mean when they specify bpbatch as bootfile. Maybe I need to read the mini-Howto... > Ken > > > John Poltorak wrote: > > >Has anyone com across bpbatch? > > > >It's supposed to be a bootfile from which Linux can be booted remotely > >over bootp and tftp. I'm trying to get it working from an OS/2 server, but > >don't really have a clue how it supposed to work. > > > >For a start I can't find a file called bpbatch even though Google takes me > >to www.bpbatch.org and I can easily identify a bpbatch archive, but it > >doesn't contain a file called bpbatch! > > > > > >Argghhhh!!!! > > > > > >So what exactly is this file bpbatch? > > > > > >I see an mrbatch which is an ELF binary. Should I use that? -- John **= Email 29 ==========================** Date: Sun, 5 Jan 2003 20:44:46 +1100 (AED) From: Nicholas Sheppard Subject: Re: INETD & BOOTPD On Sat, 4 Jan 2003, John Poltorak wrote: > Yes, I now see the INETD handling has been commented out for EMX, I just > wondered if it would be possible to cater for being launched from INETD > in the same way as you made IPOP3D run from INETD on OS/2... I expect so. This is the code to do it from ipop3d: { char *s; int ibmso,emxso; if ((s = getenv ("INETDSOCKETHANDLE")) && (ibmso = atoi (s))) { /* connect inetd's socket to stdin and stdout */ if ((emxso = _impsockhandle (ibmso,0)) >= 0) { dup2 (emxso,0); dup2 (emxso,1); close (emxso); } } } Insert that at the top of main() in bootpd.c, then delete the "#ifndef __EMX__" statements on lines 267, 357, 418 and 635 along with their matching #endif's. Then re-compile and, as I read the code, it should be able to be run from inetd in the same way as ipop3d. There are other, more complicated and arguably neater ways of doing it, but that's the simplest I can think of. > One thing I didn't understand about the port was why this sort of patch > was necessary:- > > ! sep = getservbyname("bootps", "udp"); > ! sep = getservbyname("sbootp", "udp"); I think Stefan has the answer on the other thread. Nicholas S. |\ Location: Wollongong, Australia | Neither are any wars so furious and |\ E-mail: nps at zeta.org.au | bloody, or of so long continuance, as | WWW: http://www.zeta.org.au/~nps | those occasioned by difference in | ---> Cynicism & Negativity | opinion, especially if it be in things indifferent. - Jonathon Swift **= Email 30 ==========================** Date: Sun, 5 Jan 2003 20:44:46 +1100 (AED) From: Nicholas Sheppard Subject: Re: INETD & BOOTPD On Sat, 4 Jan 2003, John Poltorak wrote: > Yes, I now see the INETD handling has been commented out for EMX, I just > wondered if it would be possible to cater for being launched from INETD > in the same way as you made IPOP3D run from INETD on OS/2... I expect so. This is the code to do it from ipop3d: { char *s; int ibmso,emxso; if ((s = getenv ("INETDSOCKETHANDLE")) && (ibmso = atoi (s))) { /* connect inetd's socket to stdin and stdout */ if ((emxso = _impsockhandle (ibmso,0)) >= 0) { dup2 (emxso,0); dup2 (emxso,1); close (emxso); } } } Insert that at the top of main() in bootpd.c, then delete the "#ifndef __EMX__" statements on lines 267, 357, 418 and 635 along with their matching #endif's. Then re-compile and, as I read the code, it should be able to be run from inetd in the same way as ipop3d. There are other, more complicated and arguably neater ways of doing it, but that's the simplest I can think of. > One thing I didn't understand about the port was why this sort of patch > was necessary:- > > ! sep = getservbyname("bootps", "udp"); > ! sep = getservbyname("sbootp", "udp"); I think Stefan has the answer on the other thread. Nicholas S. |\ Location: Wollongong, Australia | Neither are any wars so furious and |\ E-mail: nps at zeta.org.au | bloody, or of so long continuance, as | WWW: http://www.zeta.org.au/~nps | those occasioned by difference in | ---> Cynicism & Negativity | opinion, especially if it be in things indifferent. - Jonathon Swift **= Email 31 ==========================** Date: Sun, 5 Jan 2003 21:15:03 +0000 From: John Poltorak Subject: Re: Perl build hang On Sun, Jan 05, 2003 at 09:18:42PM +0100, Stefan Neis wrote: > On Sun, 5 Jan 2003, John Poltorak wrote: > > > The hang always takes place at this point:- > > > > ext/IO/lib/IO/t/io_sock..............accept failed: Connection timed out at ../ext/IO/lib/IO/t/io_sock.t line 61. > > It hangs? I thought "die "message"" is supposed to end the process? That's what I thought. Maybe it is just waiting for a something which never happens... I left it running overnight and it just waited and waited, although it continued after pressing Ctrl-Brk. > Maybe it hangs waiting for the child (the part after the elsif where you > stopped quoting) which hangs for some unknown reason? > > > if($pid = fork()) { // Create a new process > > > > $sock = $listen->accept() or die "accept failed: $!"; <====== line 61 > > // Wait for the newly created process to "connect" to us, complain > // if this doesn't happen witin a "reasonable" time. > // Either the timeout value is ridiculously low for some reason > // (how many seconds till you get that message?) > // Or something is wrong within TCP/IP configuration > // (maybe 127.0.0.1 aka loopback interface not set up?) > // Or something is wrong in said newly created process. > (snipp) > > } elsif(defined $pid) { > // Here presumably follows the newly created process, would be > // interesting what this says or if it says anything at all ... > > No idea, what suddenly could have gone wrong if it used to work all the > time, so all I can try is help to debug the problem (and then, at the end, > one might find a "trivial" configuration issue...). If anything, it's probably a TCP/IP issue. I have been testing DHCP and messing with SETUP.CMD which may have had some knock on effect on Perl, especially when running a socket test. > Regards, > Stefan -- John **= Email 32 ==========================** Date: Sun, 5 Jan 2003 21:15:03 +0000 From: John Poltorak Subject: Re: Perl build hang On Sun, Jan 05, 2003 at 09:18:42PM +0100, Stefan Neis wrote: > On Sun, 5 Jan 2003, John Poltorak wrote: > > > The hang always takes place at this point:- > > > > ext/IO/lib/IO/t/io_sock..............accept failed: Connection timed out at ../ext/IO/lib/IO/t/io_sock.t line 61. > > It hangs? I thought "die "message"" is supposed to end the process? That's what I thought. Maybe it is just waiting for a something which never happens... I left it running overnight and it just waited and waited, although it continued after pressing Ctrl-Brk. > Maybe it hangs waiting for the child (the part after the elsif where you > stopped quoting) which hangs for some unknown reason? > > > if($pid = fork()) { // Create a new process > > > > $sock = $listen->accept() or die "accept failed: $!"; <====== line 61 > > // Wait for the newly created process to "connect" to us, complain > // if this doesn't happen witin a "reasonable" time. > // Either the timeout value is ridiculously low for some reason > // (how many seconds till you get that message?) > // Or something is wrong within TCP/IP configuration > // (maybe 127.0.0.1 aka loopback interface not set up?) > // Or something is wrong in said newly created process. > (snipp) > > } elsif(defined $pid) { > // Here presumably follows the newly created process, would be > // interesting what this says or if it says anything at all ... > > No idea, what suddenly could have gone wrong if it used to work all the > time, so all I can try is help to debug the problem (and then, at the end, > one might find a "trivial" configuration issue...). If anything, it's probably a TCP/IP issue. I have been testing DHCP and messing with SETUP.CMD which may have had some knock on effect on Perl, especially when running a socket test. > Regards, > Stefan -- John **= Email 33 ==========================** Date: Sun, 5 Jan 2003 21:18:42 +0100 (CET) From: Stefan Neis Subject: Re: Perl build hang On Sun, 5 Jan 2003, John Poltorak wrote: > The hang always takes place at this point:- > > ext/IO/lib/IO/t/io_sock..............accept failed: Connection timed out at ../ext/IO/lib/IO/t/io_sock.t line 61. It hangs? I thought "die "message"" is supposed to end the process? Maybe it hangs waiting for the child (the part after the elsif where you stopped quoting) which hangs for some unknown reason? > if($pid = fork()) { // Create a new process > > $sock = $listen->accept() or die "accept failed: $!"; <====== line 61 // Wait for the newly created process to "connect" to us, complain // if this doesn't happen witin a "reasonable" time. // Either the timeout value is ridiculously low for some reason // (how many seconds till you get that message?) // Or something is wrong within TCP/IP configuration // (maybe 127.0.0.1 aka loopback interface not set up?) // Or something is wrong in said newly created process. (snipp) > } elsif(defined $pid) { // Here presumably follows the newly created process, would be // interesting what this says or if it says anything at all ... No idea, what suddenly could have gone wrong if it used to work all the time, so all I can try is help to debug the problem (and then, at the end, one might find a "trivial" configuration issue...). Regards, Stefan **= Email 34 ==========================** Date: Sun, 5 Jan 2003 21:18:42 +0100 (CET) From: Stefan Neis Subject: Re: Perl build hang On Sun, 5 Jan 2003, John Poltorak wrote: > The hang always takes place at this point:- > > ext/IO/lib/IO/t/io_sock..............accept failed: Connection timed out at ../ext/IO/lib/IO/t/io_sock.t line 61. It hangs? I thought "die "message"" is supposed to end the process? Maybe it hangs waiting for the child (the part after the elsif where you stopped quoting) which hangs for some unknown reason? > if($pid = fork()) { // Create a new process > > $sock = $listen->accept() or die "accept failed: $!"; <====== line 61 // Wait for the newly created process to "connect" to us, complain // if this doesn't happen witin a "reasonable" time. // Either the timeout value is ridiculously low for some reason // (how many seconds till you get that message?) // Or something is wrong within TCP/IP configuration // (maybe 127.0.0.1 aka loopback interface not set up?) // Or something is wrong in said newly created process. (snipp) > } elsif(defined $pid) { // Here presumably follows the newly created process, would be // interesting what this says or if it says anything at all ... No idea, what suddenly could have gone wrong if it used to work all the time, so all I can try is help to debug the problem (and then, at the end, one might find a "trivial" configuration issue...). Regards, Stefan **= Email 35 ==========================** Date: Sun, 05 Jan 2003 22:09:25 +0000 From: "Lyn St George" Subject: Re: Perl build hang On Sun, 5 Jan 2003 21:15:03 +0000, John Poltorak wrote: > >If anything, it's probably a TCP/IP issue. I have been testing DHCP and >messing with SETUP.CMD which may have had some knock on effect on Perl, >especially when running a socket test. > Is your local loopback still working? I remember having a problem with perl, which turned out to be caused by an alteration I had made in config.sys, even though, if it hadn't been for the problem, I would have sworn black and blue that my config.sys had not changed at all !! - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 36 ==========================** Date: Sun, 05 Jan 2003 22:09:25 +0000 From: "Lyn St George" Subject: Re: Perl build hang On Sun, 5 Jan 2003 21:15:03 +0000, John Poltorak wrote: > >If anything, it's probably a TCP/IP issue. I have been testing DHCP and >messing with SETUP.CMD which may have had some knock on effect on Perl, >especially when running a socket test. > Is your local loopback still working? I remember having a problem with perl, which turned out to be caused by an alteration I had made in config.sys, even though, if it hadn't been for the problem, I would have sworn black and blue that my config.sys had not changed at all !! - Cheers Lyn St George +--------------------------------------------------------------------------------- + http://www.zolotek.net .. eCommerce hosting, consulting + http://www.os2docs.org .. some 'How To' stuff ... +---------------------------------------------------------------------------------- **= Email 37 ==========================** Date: Sun, 5 Jan 2003 22:26:58 +1100 (AED) From: Nicholas Sheppard Subject: Re: Drive letters On Sun, 5 Jan 2003, John Poltorak wrote: > In general, I don't see drive letters to be a major hurdle, apart from > their use within PASSWD where the ':' delimiter has two meanings, so an > alternative has to be chosen. That in itself is not so much of a problem, > because we have a means of handling it. Unfortunately we have conflicting > solutions both of which have become fairly entrenched because they have > been around for such a long time, and we really need to come up with a > single standard. It would be nice to be able to use something now without > being dependent on some magic in the future, although being able to > incorporate future developments would be good. I'm re-writing the passwd code for the next release of ipop3d so that it will be able to read both the $c and c; formats. If there are any others I can add them, too. I would like to move to the /dev/* format for writing new entries, however, for the reasons given by various people on this list. I don't know who else is out there writing or maintaining passwd code, or what they think might be the way forward. Anyone? The people writing the code are ultimately the ones who are going to be making the decisions. Nicholas S. |\ Location: Wollongong, Australia | Neither are any wars so furious and |\ E-mail: nps at zeta.org.au | bloody, or of so long continuance, as | WWW: http://www.zeta.org.au/~nps | those occasioned by difference in | ---> Cynicism & Negativity | opinion, especially if it be in things indifferent. - Jonathon Swift **= Email 38 ==========================** Date: Sun, 5 Jan 2003 22:26:58 +1100 (AED) From: Nicholas Sheppard Subject: Re: Drive letters On Sun, 5 Jan 2003, John Poltorak wrote: > In general, I don't see drive letters to be a major hurdle, apart from > their use within PASSWD where the ':' delimiter has two meanings, so an > alternative has to be chosen. That in itself is not so much of a problem, > because we have a means of handling it. Unfortunately we have conflicting > solutions both of which have become fairly entrenched because they have > been around for such a long time, and we really need to come up with a > single standard. It would be nice to be able to use something now without > being dependent on some magic in the future, although being able to > incorporate future developments would be good. I'm re-writing the passwd code for the next release of ipop3d so that it will be able to read both the $c and c; formats. If there are any others I can add them, too. I would like to move to the /dev/* format for writing new entries, however, for the reasons given by various people on this list. I don't know who else is out there writing or maintaining passwd code, or what they think might be the way forward. Anyone? The people writing the code are ultimately the ones who are going to be making the decisions. Nicholas S. |\ Location: Wollongong, Australia | Neither are any wars so furious and |\ E-mail: nps at zeta.org.au | bloody, or of so long continuance, as | WWW: http://www.zeta.org.au/~nps | those occasioned by difference in | ---> Cynicism & Negativity | opinion, especially if it be in things indifferent. - Jonathon Swift **= Email 39 ==========================** Date: Sun, 05 Jan 2003 23:02:42 +0100 From: Thomas Hoffmann Subject: Re: shadow-4.0.3 passwords Stefan, below you said that you would like to maintain Posix/2 from now on, didn't you? ;-) As I have been using a slightly patched version of lcExt.a for my R/2 porting attempt, I could send you some patches if you could have a look at them ... Thomas. Stefan Neis wrote: > On Fri, 3 Jan 2003, John Poltorak wrote: > > > Yes, that's also why I'm reluctant to put any work into Posix/2 apart > from making available what I currently have and which seems to work > quite well for me (But then, it doesn't get _that_ much testing over > here, there might well be a couple of funtions which I never used so > far ...) > > Regards, > Stefan > > P.S.: Actually, that's now "Dr. Stefan Neis" (still looks quite funny > to me), which means I now have only one full job left, which > _might_ give me some more time for wxWindows and/or Posix/2 - at > least on weekends... :-) > > > **= Email 40 ==========================** Date: Sun, 05 Jan 2003 23:02:42 +0100 From: Thomas Hoffmann Subject: Re: shadow-4.0.3 passwords Stefan, below you said that you would like to maintain Posix/2 from now on, didn't you? ;-) As I have been using a slightly patched version of lcExt.a for my R/2 porting attempt, I could send you some patches if you could have a look at them ... Thomas. Stefan Neis wrote: > On Fri, 3 Jan 2003, John Poltorak wrote: > > > Yes, that's also why I'm reluctant to put any work into Posix/2 apart > from making available what I currently have and which seems to work > quite well for me (But then, it doesn't get _that_ much testing over > here, there might well be a couple of funtions which I never used so > far ...) > > Regards, > Stefan > > P.S.: Actually, that's now "Dr. Stefan Neis" (still looks quite funny > to me), which means I now have only one full job left, which > _might_ give me some more time for wxWindows and/or Posix/2 - at > least on weekends... :-) > > > **= Email 41 ==========================** Date: Sun, 05 Jan 2003 23:09:12 +0100 From: Thomas Hoffmann Subject: [Fwd: failure notice]was: R Some "oldish" stuff, that got lost during the name change of Unixos2: Stefan Neis wrote: >> On Sat, 21 Dec 2002, Thomas Hoffmann wrote: ..... >>>>I remember to have read something about the eating >>>>up of brackets during macro expansion but cannot find this doc right >>>>now. Then I could decide where to report the problem: to the creators of >>>>the above code or to the autoconf maintainers. > >> >> >> Creators of the code. If they don't want to change it, it's up to them to >> try to convince autoconf maintainers of anything ... For this it would be nice if I could point at some syntax description from the autoconf docs, surely more convincing for the ignorant masses than saying "it did not work under my OS/2 installation" :-( >> > >>>>But why does none of the unix guys hav a problem with this? > >> >> >> Probably because they >> a) don't run autoconf but use the generated configure. >> b) even if they run autoconf, they use a version which works for that >> script. This code comes from the R.m4 macro, developed by the R core team and they DO use Unix for sure. And they are a rather big crowd, using several dialects of Unix/Linux. This made me a bit hesitant to go forward and say "your tools are faulty". >> ..... >> >> Some dl.a normally does quite a good job at "emulating" dlopen/dlsym/dlclose. >> Even though the internals are very different, it often works just nicely. >> However compiling the DLL's can be quite a problem ... I use a hacked version of Posix/2, which gives me the nicely working dl* functionality (just as a side note: Posix/2 is far from perfect, but R/2 would rather be undoable with plain EMX). What I mean is: For the "module DLLs" I need an import library that has to be derived from R's main library. This requires some restructuring of the program's architecture compared to Unix. Similar changes were done for Octave some years ago. And modul building works like a charm now. Just beware if the modules have names longer than 8 chars, then OS/2's DLL name length limit bites ... Thomas. **= Email 42 ==========================** Date: Sun, 05 Jan 2003 23:09:12 +0100 From: Thomas Hoffmann Subject: [Fwd: failure notice]was: R Some "oldish" stuff, that got lost during the name change of Unixos2: Stefan Neis wrote: >> On Sat, 21 Dec 2002, Thomas Hoffmann wrote: ..... >>>>I remember to have read something about the eating >>>>up of brackets during macro expansion but cannot find this doc right >>>>now. Then I could decide where to report the problem: to the creators of >>>>the above code or to the autoconf maintainers. > >> >> >> Creators of the code. If they don't want to change it, it's up to them to >> try to convince autoconf maintainers of anything ... For this it would be nice if I could point at some syntax description from the autoconf docs, surely more convincing for the ignorant masses than saying "it did not work under my OS/2 installation" :-( >> > >>>>But why does none of the unix guys hav a problem with this? > >> >> >> Probably because they >> a) don't run autoconf but use the generated configure. >> b) even if they run autoconf, they use a version which works for that >> script. This code comes from the R.m4 macro, developed by the R core team and they DO use Unix for sure. And they are a rather big crowd, using several dialects of Unix/Linux. This made me a bit hesitant to go forward and say "your tools are faulty". >> ..... >> >> Some dl.a normally does quite a good job at "emulating" dlopen/dlsym/dlclose. >> Even though the internals are very different, it often works just nicely. >> However compiling the DLL's can be quite a problem ... I use a hacked version of Posix/2, which gives me the nicely working dl* functionality (just as a side note: Posix/2 is far from perfect, but R/2 would rather be undoable with plain EMX). What I mean is: For the "module DLLs" I need an import library that has to be derived from R's main library. This requires some restructuring of the program's architecture compared to Unix. Similar changes were done for Octave some years ago. And modul building works like a charm now. Just beware if the modules have names longer than 8 chars, then OS/2's DLL name length limit bites ... Thomas.