From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 7 Jan 2003 04:47:44 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 6 ************************************************** Monday 06 January 2003 Number 6 ************************************************** Subjects for today 1 Re: PASSWD handling : Andreas Buening 2 Re: PASSWD handling : Andreas Buening 3 Re: realtime chat : jimburke200 at earthlink.net (James E. Burke Jr.) 4 Re: realtime chat : jimburke200 at earthlink.net (James E. Burke Jr.) 5 Re: INETD & BOOTPD : Nicholas Sheppard 6 Re: INETD & BOOTPD : Nicholas Sheppard 7 Re: PASSWD handling : Nicholas Sheppard 8 Re: PASSWD handling : Nicholas Sheppard 9 Re: PASSWD handling : John Poltorak 10 Re: PASSWD handling : John Poltorak 11 Re: Python scripts : Andrew MacIntyre 12 Re: Python scripts : Andrew MacIntyre 13 Single UNIX Specification : John Poltorak 14 Single UNIX Specification : John Poltorak 15 Re: realtime chat : Ken Ames 16 Re: realtime chat : Ken Ames 17 Re: realtime chat : Ken Ames 18 Re: realtime chat : Ken Ames 19 Ncurses problem? : John Poltorak 20 Ncurses problem? : John Poltorak 21 [unix_scripts] Scripting Question : Kay, John" 22 Internet Software Consortium apps : John Poltorak 23 Internet Software Consortium apps : John Poltorak 24 mmap() : John Poltorak 25 mmap() : John Poltorak 26 Re: Single UNIX Specification : Steve Wendt 27 Re: Single UNIX Specification : Steve Wendt 28 Re: PASSWD handling : John Poltorak 29 Re: PASSWD handling : John Poltorak 30 Re: mmap() : John Poltorak 31 Re: mmap() : John Poltorak 32 Re: realtime chat : Ken Ames 33 Re: realtime chat : Ken Ames 34 Re: PASSWD handling : Holger Veit 35 Re: PASSWD handling : Holger Veit 36 Re: Drive letters : Holger Veit 37 Re: Drive letters : Holger Veit 38 Re: PASSWD handling : Holger Veit 39 Re: PASSWD handling : Holger Veit 40 Re: PASSWD handling : email at eracc.hypermart.net (ERACC Lists) 41 Re: PASSWD handling : email at eracc.hypermart.net (ERACC Lists) 42 Re: PASSWD handling : Adrian Gschwend" 43 Re: PASSWD handling : Adrian Gschwend" 44 Re: PASSWD handling : Adrian Gschwend" 45 Re: PASSWD handling : Adrian Gschwend" 46 Re: Ncurses problem? : Thomas Dickey 47 Re: Ncurses problem? : Thomas Dickey 48 Re: mmap() : John Poltorak 49 Re: mmap() : John Poltorak 50 Re: mmap() : Sergey Yevtushenko 51 Re: mmap() : Sergey Yevtushenko 52 Re: PASSWD handling : nickk" 53 Re: PASSWD handling : nickk" 54 Re: realtime chat : John Poltorak 55 Re: realtime chat : John Poltorak 56 Re: mmap() : Sergey Yevtushenko 57 Re: mmap() : Sergey Yevtushenko 58 Re: PASSWD handling : John Poltorak 59 Re: PASSWD handling : John Poltorak 60 Re: mmap() : Sergey Yevtushenko 61 Re: mmap() : Sergey Yevtushenko 62 Re: shadow-4.0.3 passwords : Stefan Neis 63 Re: shadow-4.0.3 passwords : Stefan Neis 64 Re: [Fwd: failure notice]was: R : Stefan Neis 65 Re: [Fwd: failure notice]was: R : Stefan Neis 66 Re: header problems? : Stefan Neis 67 Re: header problems? : Stefan Neis 68 Re: realtime chat : Adrian Gschwend" 69 Re: realtime chat : Adrian Gschwend" 70 Re: PASSWD handling : nickk" 71 Re: PASSWD handling : nickk" 72 Re: PASSWD handling : John Poltorak 73 Re: PASSWD handling : John Poltorak 74 Re: PASSWD handling : nickk" 75 Re: PASSWD handling : nickk" 76 Re: Single UNIX Specification : John Poltorak 77 Re: Single UNIX Specification : John Poltorak 78 Re: Internet Software Consortium apps : Christian Hennecke" 79 Re: Internet Software Consortium apps : Christian Hennecke" 80 Re: PASSWD handling : Nicholas Sheppard 81 Re: PASSWD handling : Nicholas Sheppard 82 Re: realtime chat : Nicholas Sheppard 83 Re: realtime chat : Nicholas Sheppard 84 Re: PASSWD handling : Sergey Yevtushenko 85 Re: PASSWD handling : Sergey Yevtushenko **= Email 1 ==========================** Date: Tue, 07 Jan 2003 00:08:09 +0100 From: Andreas Buening Subject: Re: PASSWD handling Nicholas Sheppard wrote: > > On Mon, 6 Jan 2003, Andreas Buening wrote: > > > > Suppose I take the passwd code out of Pine for the next release (4.52 is > > > currently in pre-release testing) and make it into a PASSWD.LIB, since > > > I'm going to need to fix os2user.exe, anyway. > > > > Would it make sense to put the passwd.lib code into libunixos2? > > Quite possibly. Admittedly, I'm not up to speed on what libunixos2 does, > is there a reference somewhere? My principal motivation is my immediate > need to implement user authentication for ipop3d etc. but anything I > write will be free to be used elsewhere even if I don't immediately put > it in libunixos2 or posix2 or whatever. The idea of libunixos2 is to collect stuff that is not supported by EMX (header files, function definitions) but required by UnixOS/2. Currently it basically contains posix_spawn and GNU regex. You can find it at http://unix.os2site.com/sw/pub/source/libunixos2/. > > I still haven't understood the PASSWD problem completely. This might be > > a dumb question but why should any application ever read the /etc/passwd > > file directly? Isn't there any standard (SysV, Posix, BSD, whatever) > > that defines some API functions to read the PASSWD entries? > > POSIX . EMX has one, but as Holger says, it returns dummy values > so it's not very useful. This has led to every application that needs > multiple users needing to re-implement code to parse /etc/passwd. > > > In this case > > the passwd file format wouldn't matter. > > It matters to the person implementing getpwent(), etc. In the current > state of affairs, this is everyone who needs to access /etc/passwd. In this case it concerns only you. ;-) > Creating a "standard", working implementation of getpwent() etc. would > fix this, assuming that everyone using /etc/passwd got on board. I see it the following way: You define the passwd file format and the pwd.h API for UnixOS/2. Everybody else has to use this API. Period. Everthing else leads to chaos. Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 2 ==========================** Date: Tue, 07 Jan 2003 00:08:09 +0100 From: Andreas Buening Subject: Re: PASSWD handling Nicholas Sheppard wrote: > > On Mon, 6 Jan 2003, Andreas Buening wrote: > > > > Suppose I take the passwd code out of Pine for the next release (4.52 is > > > currently in pre-release testing) and make it into a PASSWD.LIB, since > > > I'm going to need to fix os2user.exe, anyway. > > > > Would it make sense to put the passwd.lib code into libunixos2? > > Quite possibly. Admittedly, I'm not up to speed on what libunixos2 does, > is there a reference somewhere? My principal motivation is my immediate > need to implement user authentication for ipop3d etc. but anything I > write will be free to be used elsewhere even if I don't immediately put > it in libunixos2 or posix2 or whatever. The idea of libunixos2 is to collect stuff that is not supported by EMX (header files, function definitions) but required by UnixOS/2. Currently it basically contains posix_spawn and GNU regex. You can find it at http://unix.os2site.com/sw/pub/source/libunixos2/. > > I still haven't understood the PASSWD problem completely. This might be > > a dumb question but why should any application ever read the /etc/passwd > > file directly? Isn't there any standard (SysV, Posix, BSD, whatever) > > that defines some API functions to read the PASSWD entries? > > POSIX . EMX has one, but as Holger says, it returns dummy values > so it's not very useful. This has led to every application that needs > multiple users needing to re-implement code to parse /etc/passwd. > > > In this case > > the passwd file format wouldn't matter. > > It matters to the person implementing getpwent(), etc. In the current > state of affairs, this is everyone who needs to access /etc/passwd. In this case it concerns only you. ;-) > Creating a "standard", working implementation of getpwent() etc. would > fix this, assuming that everyone using /etc/passwd got on board. I see it the following way: You define the passwd file format and the pwd.h API for UnixOS/2. Everybody else has to use this API. Period. Everthing else leads to chaos. Bye, Andreas -- One OS to rule them all, One OS to find them, One OS to bring them all and in the darkness bind them In the Land of Mordor where the Shadows lie. **= Email 3 ==========================** Date: Tue, 07 Jan 2003 06:16:57 -0800 From: jimburke200 at earthlink.net (James E. Burke Jr.) Subject: Re: realtime chat www.ecomstation.com has a realtime chat url that seems to be unused. >On Sun, 5 Jan 2003, Ken Ames wrote: > >> 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. > >I'm guessing from the dearth of replies to this that the answer is "no" >but I'd be happy to hang around on one if it existed, though I think my >time zone is fairly remote from most of the people on this list. > > Nicholas S. > >|\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule >|\ E-mail: nps at zeta.org.au | who has failed to establish it. >| WWW: http://www.zeta.org.au/~nps | >| ---> Cynicism & Negativity | - Ambrose Bierce > > **= Email 4 ==========================** Date: Tue, 07 Jan 2003 06:16:57 -0800 From: jimburke200 at earthlink.net (James E. Burke Jr.) Subject: Re: realtime chat www.ecomstation.com has a realtime chat url that seems to be unused. >On Sun, 5 Jan 2003, Ken Ames wrote: > >> 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. > >I'm guessing from the dearth of replies to this that the answer is "no" >but I'd be happy to hang around on one if it existed, though I think my >time zone is fairly remote from most of the people on this list. > > Nicholas S. > >|\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule >|\ E-mail: nps at zeta.org.au | who has failed to establish it. >| WWW: http://www.zeta.org.au/~nps | >| ---> Cynicism & Negativity | - Ambrose Bierce > > **= Email 5 ==========================** Date: Tue, 7 Jan 2003 07:44:41 +1100 (EST) From: Nicholas Sheppard Subject: Re: INETD & BOOTPD On Mon, 6 Jan 2003, John Poltorak wrote: > if ((skt = getenv ("INETDSOCKETHANDLE")) && (ibmso = atoi (s))) { ^ This `s' should be an `skt'; this is probably what is causing it to crash. Otherwise it looks okay to me. Nicholas S. **= Email 6 ==========================** Date: Tue, 7 Jan 2003 07:44:41 +1100 (EST) From: Nicholas Sheppard Subject: Re: INETD & BOOTPD On Mon, 6 Jan 2003, John Poltorak wrote: > if ((skt = getenv ("INETDSOCKETHANDLE")) && (ibmso = atoi (s))) { ^ This `s' should be an `skt'; this is probably what is causing it to crash. Otherwise it looks okay to me. Nicholas S. **= Email 7 ==========================** Date: Tue, 7 Jan 2003 08:04:30 +1100 (EST) From: Nicholas Sheppard Subject: Re: PASSWD handling On Mon, 6 Jan 2003, Andreas Buening wrote: > > Suppose I take the passwd code out of Pine for the next release (4.52 is > > currently in pre-release testing) and make it into a PASSWD.LIB, since > > I'm going to need to fix os2user.exe, anyway. > > Would it make sense to put the passwd.lib code into libunixos2? Quite possibly. Admittedly, I'm not up to speed on what libunixos2 does, is there a reference somewhere? My principal motivation is my immediate need to implement user authentication for ipop3d etc. but anything I write will be free to be used elsewhere even if I don't immediately put it in libunixos2 or posix2 or whatever. > I still haven't understood the PASSWD problem completely. This might be > a dumb question but why should any application ever read the /etc/passwd > file directly? Isn't there any standard (SysV, Posix, BSD, whatever) > that defines some API functions to read the PASSWD entries? POSIX . EMX has one, but as Holger says, it returns dummy values so it's not very useful. This has led to every application that needs multiple users needing to re-implement code to parse /etc/passwd. > In this case > the passwd file format wouldn't matter. It matters to the person implementing getpwent(), etc. In the current state of affairs, this is everyone who needs to access /etc/passwd. Creating a "standard", working implementation of getpwent() etc. would fix this, assuming that everyone using /etc/passwd got on board. Nicholas S. **= Email 8 ==========================** Date: Tue, 7 Jan 2003 08:04:30 +1100 (EST) From: Nicholas Sheppard Subject: Re: PASSWD handling On Mon, 6 Jan 2003, Andreas Buening wrote: > > Suppose I take the passwd code out of Pine for the next release (4.52 is > > currently in pre-release testing) and make it into a PASSWD.LIB, since > > I'm going to need to fix os2user.exe, anyway. > > Would it make sense to put the passwd.lib code into libunixos2? Quite possibly. Admittedly, I'm not up to speed on what libunixos2 does, is there a reference somewhere? My principal motivation is my immediate need to implement user authentication for ipop3d etc. but anything I write will be free to be used elsewhere even if I don't immediately put it in libunixos2 or posix2 or whatever. > I still haven't understood the PASSWD problem completely. This might be > a dumb question but why should any application ever read the /etc/passwd > file directly? Isn't there any standard (SysV, Posix, BSD, whatever) > that defines some API functions to read the PASSWD entries? POSIX . EMX has one, but as Holger says, it returns dummy values so it's not very useful. This has led to every application that needs multiple users needing to re-implement code to parse /etc/passwd. > In this case > the passwd file format wouldn't matter. It matters to the person implementing getpwent(), etc. In the current state of affairs, this is everyone who needs to access /etc/passwd. Creating a "standard", working implementation of getpwent() etc. would fix this, assuming that everyone using /etc/passwd got on board. Nicholas S. **= Email 9 ==========================** Date: Tue, 7 Jan 2003 09:12:43 +0000 From: John Poltorak Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 12:08:09AM +0100, Andreas Buening wrote: > Nicholas Sheppard wrote: > > > > > Would it make sense to put the passwd.lib code into libunixos2? > > > > Quite possibly. Admittedly, I'm not up to speed on what libunixos2 does, > > is there a reference somewhere? My principal motivation is my immediate > > need to implement user authentication for ipop3d etc. but anything I > > write will be free to be used elsewhere even if I don't immediately put > > it in libunixos2 or posix2 or whatever. > > The idea of libunixos2 is to collect stuff that is not supported by EMX > (header files, function definitions) but required by UnixOS/2. > Currently it basically contains posix_spawn and GNU regex. > You can find it at http://unix.os2site.com/sw/pub/source/libunixos2/. I can't help feeling that there is a large degree of overlap between libunixos2 and posix/2. Is there any way to merge the two? > > POSIX . EMX has one, but as Holger says, it returns dummy values > > so it's not very useful. This has led to every application that needs > > multiple users needing to re-implement code to parse /etc/passwd. > > > > > In this case > > > the passwd file format wouldn't matter. > > > > It matters to the person implementing getpwent(), etc. In the current > > state of affairs, this is everyone who needs to access /etc/passwd. > > In this case it concerns only you. ;-) It also concerns everyone who runs any apps which use passwd. Will any changes need to be made as a result of a new passwd handler? Will we need to convert passwd from one format to another? Will we need to migrate to new versions of some apps? > > Creating a "standard", working implementation of getpwent() etc. would > > fix this, assuming that everyone using /etc/passwd got on board. > > I see it the following way: You define the passwd file format and the > pwd.h API for UnixOS/2. Everybody else has to use this API. Period. > Everthing else leads to chaos. We also need to make sure it is accepted by everyone who maintains an app which accesses passwd. Does it mean that any apps will need to be modified or rebuilt? Are there any implications for Perl or Python in having new passwd handling? > Bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 10 ==========================** Date: Tue, 7 Jan 2003 09:12:43 +0000 From: John Poltorak Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 12:08:09AM +0100, Andreas Buening wrote: > Nicholas Sheppard wrote: > > > > > Would it make sense to put the passwd.lib code into libunixos2? > > > > Quite possibly. Admittedly, I'm not up to speed on what libunixos2 does, > > is there a reference somewhere? My principal motivation is my immediate > > need to implement user authentication for ipop3d etc. but anything I > > write will be free to be used elsewhere even if I don't immediately put > > it in libunixos2 or posix2 or whatever. > > The idea of libunixos2 is to collect stuff that is not supported by EMX > (header files, function definitions) but required by UnixOS/2. > Currently it basically contains posix_spawn and GNU regex. > You can find it at http://unix.os2site.com/sw/pub/source/libunixos2/. I can't help feeling that there is a large degree of overlap between libunixos2 and posix/2. Is there any way to merge the two? > > POSIX . EMX has one, but as Holger says, it returns dummy values > > so it's not very useful. This has led to every application that needs > > multiple users needing to re-implement code to parse /etc/passwd. > > > > > In this case > > > the passwd file format wouldn't matter. > > > > It matters to the person implementing getpwent(), etc. In the current > > state of affairs, this is everyone who needs to access /etc/passwd. > > In this case it concerns only you. ;-) It also concerns everyone who runs any apps which use passwd. Will any changes need to be made as a result of a new passwd handler? Will we need to convert passwd from one format to another? Will we need to migrate to new versions of some apps? > > Creating a "standard", working implementation of getpwent() etc. would > > fix this, assuming that everyone using /etc/passwd got on board. > > I see it the following way: You define the passwd file format and the > pwd.h API for UnixOS/2. Everybody else has to use this API. Period. > Everthing else leads to chaos. We also need to make sure it is accepted by everyone who maintains an app which accesses passwd. Does it mean that any apps will need to be modified or rebuilt? Are there any implications for Perl or Python in having new passwd handling? > Bye, > Andreas > > -- > One OS to rule them all, One OS to find them, > One OS to bring them all and in the darkness bind them > In the Land of Mordor where the Shadows lie. -- John **= Email 11 ==========================** Date: Tue, 7 Jan 2003 09:19:13 +1000 (est) From: Andrew MacIntyre Subject: Re: Python scripts On Sun, 5 Jan 2003, John Poltorak wrote: > Is it possible to make Python scripts run as command files by inserting > EXTPROC in the first line and changing the name to *.CMD? yes > With Perl I just need to use this:- > > extproc perl -x > #!perl > > > What do I need to do with this:- ? > > #!/usr/bin/python extproc python -x It is prudent to make sure that PYTHONHOME & PYTHONPATH are set. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au | Snail: PO Box 370 andymac at pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 12 ==========================** Date: Tue, 7 Jan 2003 09:19:13 +1000 (est) From: Andrew MacIntyre Subject: Re: Python scripts On Sun, 5 Jan 2003, John Poltorak wrote: > Is it possible to make Python scripts run as command files by inserting > EXTPROC in the first line and changing the name to *.CMD? yes > With Perl I just need to use this:- > > extproc perl -x > #!perl > > > What do I need to do with this:- ? > > #!/usr/bin/python extproc python -x It is prudent to make sure that PYTHONHOME & PYTHONPATH are set. -- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac at bullseye.apana.org.au | Snail: PO Box 370 andymac at pcug.org.au | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia **= Email 13 ==========================** Date: Tue, 7 Jan 2003 09:43:20 +0000 From: John Poltorak Subject: Single UNIX Specification There is a document here:- http://www.opengroup.org/onlinepubs/7908799/xcuix.html which lists all the Commands and Utilities that are part of a Single UNIX Specification, Version 2. Does anyone know whether this list is generally accepted amongst Unix vendors and if so whether it has been updated? -- John **= Email 14 ==========================** Date: Tue, 7 Jan 2003 09:43:20 +0000 From: John Poltorak Subject: Single UNIX Specification There is a document here:- http://www.opengroup.org/onlinepubs/7908799/xcuix.html which lists all the Commands and Utilities that are part of a Single UNIX Specification, Version 2. Does anyone know whether this list is generally accepted amongst Unix vendors and if so whether it has been updated? -- John **= Email 15 ==========================** Date: Tue, 07 Jan 2003 09:44:46 -0800 From: Ken Ames Subject: Re: realtime chat hi John, actually, we wouldn't need to set one up, we could use an existing irc network like irc.openprojects.net or even on irc.anduin.net where #netlabs is run. the latter one is a private server run by Eiric Overby aka Ltning so we could just ask him. Ken John Poltorak wrote: >On Tue, Jan 07, 2003 at 10:37:13PM +1100, Nicholas Sheppard wrote: > > >>On Sun, 5 Jan 2003, Ken Ames wrote: >> >> >> >>> 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. >>> >>> >>I'm guessing from the dearth of replies to this that the answer is "no" >>but I'd be happy to hang around on one if it existed, though I think my >>time zone is fairly remote from most of the people on this list. >> >> > >Computer people seem to keep odd hours, so you can never be sure when >people are around... > >As far as IRC servers go, which is the most popular one around and has it >been ported to OS/2? > >I've never even tried setting one up so may give it a try... > > > > >> Nicholas S. >> >>|\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule >>|\ E-mail: nps at zeta.org.au | who has failed to establish it. >>| WWW: http://www.zeta.org.au/~nps | >>| ---> Cynicism & Negativity | - Ambrose Bierce >> >> > > > > **= Email 16 ==========================** Date: Tue, 07 Jan 2003 09:44:46 -0800 From: Ken Ames Subject: Re: realtime chat hi John, actually, we wouldn't need to set one up, we could use an existing irc network like irc.openprojects.net or even on irc.anduin.net where #netlabs is run. the latter one is a private server run by Eiric Overby aka Ltning so we could just ask him. Ken John Poltorak wrote: >On Tue, Jan 07, 2003 at 10:37:13PM +1100, Nicholas Sheppard wrote: > > >>On Sun, 5 Jan 2003, Ken Ames wrote: >> >> >> >>> 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. >>> >>> >>I'm guessing from the dearth of replies to this that the answer is "no" >>but I'd be happy to hang around on one if it existed, though I think my >>time zone is fairly remote from most of the people on this list. >> >> > >Computer people seem to keep odd hours, so you can never be sure when >people are around... > >As far as IRC servers go, which is the most popular one around and has it >been ported to OS/2? > >I've never even tried setting one up so may give it a try... > > > > >> Nicholas S. >> >>|\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule >>|\ E-mail: nps at zeta.org.au | who has failed to establish it. >>| WWW: http://www.zeta.org.au/~nps | >>| ---> Cynicism & Negativity | - Ambrose Bierce >> >> > > > > **= Email 17 ==========================** Date: Tue, 07 Jan 2003 09:47:36 -0800 From: Ken Ames Subject: Re: realtime chat hi Nickolas, I see what you mean :) actually a few have spoken up now. I think irc is a good tool to help development move along. Ken Nicholas Sheppard wrote: >On Sun, 5 Jan 2003, Ken Ames wrote: > > > >> 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. >> >> > >I'm guessing from the dearth of replies to this that the answer is "no" >but I'd be happy to hang around on one if it existed, though I think my >time zone is fairly remote from most of the people on this list. > > Nicholas S. > >|\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule >|\ E-mail: nps at zeta.org.au | who has failed to establish it. >| WWW: http://www.zeta.org.au/~nps | >| ---> Cynicism & Negativity | - Ambrose Bierce > > > > **= Email 18 ==========================** Date: Tue, 07 Jan 2003 09:47:36 -0800 From: Ken Ames Subject: Re: realtime chat hi Nickolas, I see what you mean :) actually a few have spoken up now. I think irc is a good tool to help development move along. Ken Nicholas Sheppard wrote: >On Sun, 5 Jan 2003, Ken Ames wrote: > > > >> 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. >> >> > >I'm guessing from the dearth of replies to this that the answer is "no" >but I'd be happy to hang around on one if it existed, though I think my >time zone is fairly remote from most of the people on this list. > > Nicholas S. > >|\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule >|\ E-mail: nps at zeta.org.au | who has failed to establish it. >| WWW: http://www.zeta.org.au/~nps | >| ---> Cynicism & Negativity | - Ambrose Bierce > > > > **= Email 19 ==========================** Date: Tue, 7 Jan 2003 10:32:47 +0000 From: John Poltorak Subject: Ncurses problem? I'm not sure if this is a problem or not, but I noticed this msg whilst building NCURSES (5.3) :- sh ./run_tic.sh ** Building terminfo database, please wait... ** adjusting tabset paths Running tic to install c:/usr/share/terminfo ... You may see messages regarding unknown capabilities, e.g., AX. These are extended terminal capabilities which can be compiled using tic -x Read the INSTALL document before doing this - it can cause problems for older ncurses applications. 38 entries written to /usr/share/terminfo ** built new c:/usr/share/terminfo cp: ../share/terminfo: No such file or directory Everything appears to have been built and installed correctly, so I'm not sure what the msg is saying. -- John **= Email 20 ==========================** Date: Tue, 7 Jan 2003 10:32:47 +0000 From: John Poltorak Subject: Ncurses problem? I'm not sure if this is a problem or not, but I noticed this msg whilst building NCURSES (5.3) :- sh ./run_tic.sh ** Building terminfo database, please wait... ** adjusting tabset paths Running tic to install c:/usr/share/terminfo ... You may see messages regarding unknown capabilities, e.g., AX. These are extended terminal capabilities which can be compiled using tic -x Read the INSTALL document before doing this - it can cause problems for older ncurses applications. 38 entries written to /usr/share/terminfo ** built new c:/usr/share/terminfo cp: ../share/terminfo: No such file or directory Everything appears to have been built and installed correctly, so I'm not sure what the msg is saying. -- John **= Email 21 ==========================** Date: Tue, 7 Jan 2003 11:38:11 -0500 From: "Kay, John" Subject: [unix_scripts] Scripting Question Can someone please give me an example of how using "vi" I would use the output of one command inside the script as the input to another command? Thank you Jonathon Kay RF Associate Engineer Airgate PCS PCS: 6163089728 Work: 6166565159 ------------------------ Yahoo! Groups Sponsor ---------------------~--> Flexible Keyboard is the ideal accessory for PDA users that are on the move. http://us.click.yahoo.com/dCBVZC/WnCFAA/xGHJAA/CZFolB/TM ---------------------------------------------------------------------~-> To unsubscribe from this group, send an email to: unix_scripts-unsubscribe at yahoogroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ **= Email 22 ==========================** Date: Tue, 7 Jan 2003 12:07:06 +0000 From: John Poltorak Subject: Internet Software Consortium apps ISC maintain three important open source apps; BIND, DHCP and INN. I know there is an older version of BIND available for OS/2 but it appears difficult to maintain... Has anyone tried building any of these apps straight from the original source? Maybe the same tricks could be used to get them all to build on OS/2. What are the likely stumbling blocks? -- John **= Email 23 ==========================** Date: Tue, 7 Jan 2003 12:07:06 +0000 From: John Poltorak Subject: Internet Software Consortium apps ISC maintain three important open source apps; BIND, DHCP and INN. I know there is an older version of BIND available for OS/2 but it appears difficult to maintain... Has anyone tried building any of these apps straight from the original source? Maybe the same tricks could be used to get them all to build on OS/2. What are the likely stumbling blocks? -- John **= Email 24 ==========================** Date: Tue, 7 Jan 2003 12:15:02 +0000 From: John Poltorak Subject: mmap() Just looking through the INSTALL file for INN it says:- So far as possible, INN is written in portable C and should work on any Unix platform. It does, however, make extensive use of mmap() and certain other constructs that may be poorly or incompletely implemented, particularly on old operating systems. Before I try building this thing, where do we stand with mmap() on OS/2? -- John **= Email 25 ==========================** Date: Tue, 7 Jan 2003 12:15:02 +0000 From: John Poltorak Subject: mmap() Just looking through the INSTALL file for INN it says:- So far as possible, INN is written in portable C and should work on any Unix platform. It does, however, make extensive use of mmap() and certain other constructs that may be poorly or incompletely implemented, particularly on old operating systems. Before I try building this thing, where do we stand with mmap() on OS/2? -- John **= Email 26 ==========================** Date: Tue, 7 Jan 2003 12:33:41 -0800 (PST) From: Steve Wendt Subject: Re: Single UNIX Specification On Tue, 7 Jan 2003, John Poltorak wrote: > which lists all the Commands and Utilities that are part of a Single UNIX > Specification, Version 2. > > Does anyone know whether this list is generally accepted amongst Unix > vendors and if so whether it has been updated? Looks like version 3 was recently approved: http://www.opengroup.org/comm/press/14nov02.htm It's sponsored by IBM, HP, Sun, etc. so I would say it *is* "generally accepted amongst Unix vendors" **= Email 27 ==========================** Date: Tue, 7 Jan 2003 12:33:41 -0800 (PST) From: Steve Wendt Subject: Re: Single UNIX Specification On Tue, 7 Jan 2003, John Poltorak wrote: > which lists all the Commands and Utilities that are part of a Single UNIX > Specification, Version 2. > > Does anyone know whether this list is generally accepted amongst Unix > vendors and if so whether it has been updated? Looks like version 3 was recently approved: http://www.opengroup.org/comm/press/14nov02.htm It's sponsored by IBM, HP, Sun, etc. so I would say it *is* "generally accepted amongst Unix vendors" **= Email 28 ==========================** Date: Tue, 7 Jan 2003 12:44:36 +0000 From: John Poltorak Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 03:15:50PM +0300, nickk wrote: > On Tue, 7 Jan 2003 22:19:09 +1100 (AED), Nicholas Sheppard wrote: > > I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling > functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) > structure and location and also provides access control for users. The sshd from latest openssh already uses this > api ;) As I understand it, this will restrict usage to people running W4 FP13+. Is that the case? Personally I would prefer not to force such a restriction on anyone. > cu, nickk -- John **= Email 29 ==========================** Date: Tue, 7 Jan 2003 12:44:36 +0000 From: John Poltorak Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 03:15:50PM +0300, nickk wrote: > On Tue, 7 Jan 2003 22:19:09 +1100 (AED), Nicholas Sheppard wrote: > > I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling > functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) > structure and location and also provides access control for users. The sshd from latest openssh already uses this > api ;) As I understand it, this will restrict usage to people running W4 FP13+. Is that the case? Personally I would prefer not to force such a restriction on anyone. > cu, nickk -- John **= Email 30 ==========================** Date: Tue, 7 Jan 2003 13:23:51 +0000 From: John Poltorak Subject: Re: mmap() On Tue, Jan 07, 2003 at 02:57:13PM +0200, Sergey Yevtushenko wrote: > John Poltorak wrote: > > Just looking through the INSTALL file for INN it says:- > > > > > > So far as possible, INN is written in portable C and should work on any > > Unix platform. It does, however, make extensive use of mmap() and > > certain other constructs that may be poorly or incompletely implemented, > > particularly on old operating systems. > > > > > > > > Before I try building this thing, where do we stand with mmap() on OS/2? > > Some time ago I wrote implementation of memory mapped files for OS/2, > but it definitely not a direct replacement for mmap(). Also, that > implementation was primarily a "proof of concept" rather than finished > library, so it requires some work before use. > Article and sources can be found at EDM/2. Thanks for the pointer. If anyone wants to read it, check:- http://www.edm2.com/0610/memorymap.html How functional is your library and do have any plans for it? My search for mmap found this:- http://hobbes.nmsu.edu/pub/os2/dev/unix/mmap-1.77.zip which was written by someone else. Do you know how complete this one is? > Regards, > Sergey. > > -- John **= Email 31 ==========================** Date: Tue, 7 Jan 2003 13:23:51 +0000 From: John Poltorak Subject: Re: mmap() On Tue, Jan 07, 2003 at 02:57:13PM +0200, Sergey Yevtushenko wrote: > John Poltorak wrote: > > Just looking through the INSTALL file for INN it says:- > > > > > > So far as possible, INN is written in portable C and should work on any > > Unix platform. It does, however, make extensive use of mmap() and > > certain other constructs that may be poorly or incompletely implemented, > > particularly on old operating systems. > > > > > > > > Before I try building this thing, where do we stand with mmap() on OS/2? > > Some time ago I wrote implementation of memory mapped files for OS/2, > but it definitely not a direct replacement for mmap(). Also, that > implementation was primarily a "proof of concept" rather than finished > library, so it requires some work before use. > Article and sources can be found at EDM/2. Thanks for the pointer. If anyone wants to read it, check:- http://www.edm2.com/0610/memorymap.html How functional is your library and do have any plans for it? My search for mmap found this:- http://hobbes.nmsu.edu/pub/os2/dev/unix/mmap-1.77.zip which was written by someone else. Do you know how complete this one is? > Regards, > Sergey. > > -- John **= Email 32 ==========================** Date: Tue, 07 Jan 2003 13:30:08 -0800 From: Ken Ames Subject: Re: realtime chat hi everyone, we now have an irc channel on irc.anduin.net #unixos2 , I hope everyone will take advantage and use it even if only from time to time. mozilla has a built-in irc client if you don't have one. it is a usable client. I hope to see you all there! Ken **= Email 33 ==========================** Date: Tue, 07 Jan 2003 13:30:08 -0800 From: Ken Ames Subject: Re: realtime chat hi everyone, we now have an irc channel on irc.anduin.net #unixos2 , I hope everyone will take advantage and use it even if only from time to time. mozilla has a built-in irc client if you don't have one. it is a usable client. I hope to see you all there! Ken **= Email 34 ==========================** Date: Tue, 7 Jan 2003 13:33:16 +0100 From: Holger Veit Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 09:12:43AM +0000, John Poltorak wrote: > On Tue, Jan 07, 2003 at 12:08:09AM +0100, Andreas Buening wrote: > > Nicholas Sheppard wrote: > > > > > > > Would it make sense to put the passwd.lib code into libunixos2? > > > > > > Quite possibly. Admittedly, I'm not up to speed on what libunixos2 does, > > > is there a reference somewhere? My principal motivation is my immediate > > > need to implement user authentication for ipop3d etc. but anything I > > > write will be free to be used elsewhere even if I don't immediately put > > > it in libunixos2 or posix2 or whatever. > > > > The idea of libunixos2 is to collect stuff that is not supported by EMX > > (header files, function definitions) but required by UnixOS/2. > > Currently it basically contains posix_spawn and GNU regex. > > You can find it at http://unix.os2site.com/sw/pub/source/libunixos2/. > > I can't help feeling that there is a large degree of overlap between > libunixos2 and posix/2. Is there any way to merge the two? POSIX/2 was a case study to check whether it is possible to extend EMX without actually touching the inner workings of EMX itself (due to some kind of appreciation of EM's work). While libext (which is POSIX/2) contains some worthy parts, I think the strategy not to touch EMX itself is limited to what is now in libext. As there has been recently a posting in emx list (I think by Andreas) with a plea to at least add an alias of str(n)icmp to str(n)casecmp to fix the most obvious flaw, I again recommend to cannibalize EMX and add certain missing parts directly (but still keeping backward compatibility - libunixos2 *must* drop backward compatibility, but it is possible to integrate *some* extension from libext to EMX without breaking anything). Call this EMX __EMXVERSION__ 99 (not sure about this particular symbol offhand but I had temporarily submitted a change with this version id to EM long ago). I have strong doubts given EM almost completely disappearing that there will be a further significant addendum to EMX by EM himself. > > In this case it concerns only you. ;-) > > It also concerns everyone who runs any apps which use passwd. > > Will any changes need to be made as a result of a new passwd handler? In theory, apps that correctly use getpwent() will not need any change at all - you just have to replace the EMX DLLs with versions that have the correct implementation. In practice, as already stated, almost everyone has reinvented the wheel and wrote his own passwd/group parser, and this code has to be located and undone. > Will we need to convert passwd from one format to another? Maybe with some shell script in the beginning, but we one day have to make a final cut and decide "this is it" (as recommended already: exactly the format that Unix uses should be "it" - there is a lot of stuff hanging at it, for instance Yellow Pages (NIS) and PAM, which I don't like very much to rewrite. > Will we need to migrate to new versions of some apps? As the original Unix apps usually only work correctly with the Unix passwd format, the main porting job - done noce only) will be to undo the OS/2 specific changes, recompile, relink, and reissue after testing. > > > Creating a "standard", working implementation of getpwent() etc. would > > > fix this, assuming that everyone using /etc/passwd got on board. > > > > I see it the following way: You define the passwd file format and the > > pwd.h API for UnixOS/2. Everybody else has to use this API. Period. > > Everthing else leads to chaos. > > We also need to make sure it is accepted by everyone who maintains an app > which accesses passwd. Okay. John Doe-Porter writes his well-known foobar application which relies on some obscure OS/2 passwd format, and since it was hard to port, and he has lack of time and is generally refusing to accept any comment from outside (just because his code is so great), he consequently ignores any new pwd.h and any new /etc/passwd (you could write a shell script that bends %ETC% to the own version of %ETC%\\PASSWD - simple solution). So, we have no aceeptance by everyone, and thus the project /etc/passwd is dead, right? My opinion is the same as the one Andreas stated above. Citation: "I see it the following way: You define the passwd file format and the pwd.h API for UnixOS/2. Everybody else has to use this API. Period. Everthing else leads to chaos." Exactly, this is it. > Does it mean that any apps will need to be modified or rebuilt? The ones that deal with passwd have to be checked, obviously. > Are there any implications for Perl or Python in having new passwd > handling? They use getpwent and friends if they are working correctly (some HAS_PWENT or similar variable to be set to 1). Holger OA -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 35 ==========================** Date: Tue, 7 Jan 2003 13:33:16 +0100 From: Holger Veit Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 09:12:43AM +0000, John Poltorak wrote: > On Tue, Jan 07, 2003 at 12:08:09AM +0100, Andreas Buening wrote: > > Nicholas Sheppard wrote: > > > > > > > Would it make sense to put the passwd.lib code into libunixos2? > > > > > > Quite possibly. Admittedly, I'm not up to speed on what libunixos2 does, > > > is there a reference somewhere? My principal motivation is my immediate > > > need to implement user authentication for ipop3d etc. but anything I > > > write will be free to be used elsewhere even if I don't immediately put > > > it in libunixos2 or posix2 or whatever. > > > > The idea of libunixos2 is to collect stuff that is not supported by EMX > > (header files, function definitions) but required by UnixOS/2. > > Currently it basically contains posix_spawn and GNU regex. > > You can find it at http://unix.os2site.com/sw/pub/source/libunixos2/. > > I can't help feeling that there is a large degree of overlap between > libunixos2 and posix/2. Is there any way to merge the two? POSIX/2 was a case study to check whether it is possible to extend EMX without actually touching the inner workings of EMX itself (due to some kind of appreciation of EM's work). While libext (which is POSIX/2) contains some worthy parts, I think the strategy not to touch EMX itself is limited to what is now in libext. As there has been recently a posting in emx list (I think by Andreas) with a plea to at least add an alias of str(n)icmp to str(n)casecmp to fix the most obvious flaw, I again recommend to cannibalize EMX and add certain missing parts directly (but still keeping backward compatibility - libunixos2 *must* drop backward compatibility, but it is possible to integrate *some* extension from libext to EMX without breaking anything). Call this EMX __EMXVERSION__ 99 (not sure about this particular symbol offhand but I had temporarily submitted a change with this version id to EM long ago). I have strong doubts given EM almost completely disappearing that there will be a further significant addendum to EMX by EM himself. > > In this case it concerns only you. ;-) > > It also concerns everyone who runs any apps which use passwd. > > Will any changes need to be made as a result of a new passwd handler? In theory, apps that correctly use getpwent() will not need any change at all - you just have to replace the EMX DLLs with versions that have the correct implementation. In practice, as already stated, almost everyone has reinvented the wheel and wrote his own passwd/group parser, and this code has to be located and undone. > Will we need to convert passwd from one format to another? Maybe with some shell script in the beginning, but we one day have to make a final cut and decide "this is it" (as recommended already: exactly the format that Unix uses should be "it" - there is a lot of stuff hanging at it, for instance Yellow Pages (NIS) and PAM, which I don't like very much to rewrite. > Will we need to migrate to new versions of some apps? As the original Unix apps usually only work correctly with the Unix passwd format, the main porting job - done noce only) will be to undo the OS/2 specific changes, recompile, relink, and reissue after testing. > > > Creating a "standard", working implementation of getpwent() etc. would > > > fix this, assuming that everyone using /etc/passwd got on board. > > > > I see it the following way: You define the passwd file format and the > > pwd.h API for UnixOS/2. Everybody else has to use this API. Period. > > Everthing else leads to chaos. > > We also need to make sure it is accepted by everyone who maintains an app > which accesses passwd. Okay. John Doe-Porter writes his well-known foobar application which relies on some obscure OS/2 passwd format, and since it was hard to port, and he has lack of time and is generally refusing to accept any comment from outside (just because his code is so great), he consequently ignores any new pwd.h and any new /etc/passwd (you could write a shell script that bends %ETC% to the own version of %ETC%\\PASSWD - simple solution). So, we have no aceeptance by everyone, and thus the project /etc/passwd is dead, right? My opinion is the same as the one Andreas stated above. Citation: "I see it the following way: You define the passwd file format and the pwd.h API for UnixOS/2. Everybody else has to use this API. Period. Everthing else leads to chaos." Exactly, this is it. > Does it mean that any apps will need to be modified or rebuilt? The ones that deal with passwd have to be checked, obviously. > Are there any implications for Perl or Python in having new passwd > handling? They use getpwent and friends if they are working correctly (some HAS_PWENT or similar variable to be set to 1). Holger OA -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 36 ==========================** Date: Tue, 7 Jan 2003 13:45:10 +0100 From: Holger Veit Subject: Re: Drive letters On Sat, Jan 04, 2003 at 04:32:27AM -0500, Henry Sobotka wrote: > The one point that strikes me as missing in this entire discussion is > the fact that c:/usr/bin is not the equivalent of > /[c_drive|unixroot|whatever]/usr/bin, but rather of > /dev/[da0s1|hda1|whatever]/usr/bin (assuming c: is the first primary on > disk 1). In other words, the difference between DOSlike and UNIXlike > file systems is the fact that the former exposes the hard disk location, > whereas the latter hides it from the user via mount points. What this > suggests is that the UNIX-OS2 FS be explicitly creatable instead of > derived from a SET UNIXROOT statement or some mechanism that hides that > variable from the user. Meaning how about an FS that, like TVFS, the > user has to define such that anything undefined is invisible to it, with > "mount c:/usr /usr" == "mount /dev/[da0s1|hda1|whatever]/usr /usr"? > > There's a lot to be said for partitioning. It's like dividing submarines > into airtight compartments or projects into tasks, or having separate > file cabinets for correspondence, finance, operations etc. instead of > one humungous drawer. It's easier and faster to type "cd k:\mozilla" > than "cd /home/henry/projects/mozilla" and disk access is likely > quicker. With partitions you can also take advantage of HD speed > differences, e.g. by putting heavily read material such as source code > in the fastest area (usually the outside tracks), systems and > applications near the center, and static stuff (docs and images) where > it's slowest. Not to mention that, the bigger the partition, the greater > the potential loss. > > One can even argue against single-tree filesystems on the grounds of the > simplicity of "deltree /" versus "deltree [c...z]:\". Or against a > standard FS because it's a known entity rather than a black box. > > 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. There is one important point which you neglect: You have to bootstrap the environment, i.e. the filesystem tree somehow, whether you use devices or a kind of symbolic links (what "/drive_c" prefixes are). Under Unix this works by having a RAM-based root filesystem (actually just a single inode, on which the root device is mounted on), and after getting a real root file system you can mount further filesystems (because you then hae /etc/fstab). To boot Unix, you must get the /dev/sda, or whatever device contains the '/' filesystem from elsewhere. This is exactly what UNIXROOT is good and required for (it is basically the mounted root file system). The other points, whether the mount works on devices (some encrypted version of "C:\" or "Z:\foo") or on an equivalent of a symbolic link ("c:\unixusr" is supposed to be "/usr") is just syntactic sugar which we could spend endless fruitless discussions on. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 37 ==========================** Date: Tue, 7 Jan 2003 13:45:10 +0100 From: Holger Veit Subject: Re: Drive letters On Sat, Jan 04, 2003 at 04:32:27AM -0500, Henry Sobotka wrote: > The one point that strikes me as missing in this entire discussion is > the fact that c:/usr/bin is not the equivalent of > /[c_drive|unixroot|whatever]/usr/bin, but rather of > /dev/[da0s1|hda1|whatever]/usr/bin (assuming c: is the first primary on > disk 1). In other words, the difference between DOSlike and UNIXlike > file systems is the fact that the former exposes the hard disk location, > whereas the latter hides it from the user via mount points. What this > suggests is that the UNIX-OS2 FS be explicitly creatable instead of > derived from a SET UNIXROOT statement or some mechanism that hides that > variable from the user. Meaning how about an FS that, like TVFS, the > user has to define such that anything undefined is invisible to it, with > "mount c:/usr /usr" == "mount /dev/[da0s1|hda1|whatever]/usr /usr"? > > There's a lot to be said for partitioning. It's like dividing submarines > into airtight compartments or projects into tasks, or having separate > file cabinets for correspondence, finance, operations etc. instead of > one humungous drawer. It's easier and faster to type "cd k:\mozilla" > than "cd /home/henry/projects/mozilla" and disk access is likely > quicker. With partitions you can also take advantage of HD speed > differences, e.g. by putting heavily read material such as source code > in the fastest area (usually the outside tracks), systems and > applications near the center, and static stuff (docs and images) where > it's slowest. Not to mention that, the bigger the partition, the greater > the potential loss. > > One can even argue against single-tree filesystems on the grounds of the > simplicity of "deltree /" versus "deltree [c...z]:\". Or against a > standard FS because it's a known entity rather than a black box. > > 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. There is one important point which you neglect: You have to bootstrap the environment, i.e. the filesystem tree somehow, whether you use devices or a kind of symbolic links (what "/drive_c" prefixes are). Under Unix this works by having a RAM-based root filesystem (actually just a single inode, on which the root device is mounted on), and after getting a real root file system you can mount further filesystems (because you then hae /etc/fstab). To boot Unix, you must get the /dev/sda, or whatever device contains the '/' filesystem from elsewhere. This is exactly what UNIXROOT is good and required for (it is basically the mounted root file system). The other points, whether the mount works on devices (some encrypted version of "C:\" or "Z:\foo") or on an equivalent of a symbolic link ("c:\unixusr" is supposed to be "/usr") is just syntactic sugar which we could spend endless fruitless discussions on. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 38 ==========================** Date: Tue, 7 Jan 2003 13:47:01 +0100 From: Holger Veit Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 12:44:36PM +0000, John Poltorak wrote: > On Tue, Jan 07, 2003 at 03:15:50PM +0300, nickk wrote: > > On Tue, 7 Jan 2003 22:19:09 +1100 (AED), Nicholas Sheppard wrote: > > > > I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling > > functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) > > structure and location and also provides access control for users. The sshd from latest openssh already uses this > > api ;) > > As I understand it, this will restrict usage to people running W4 FP13+. > > Is that the case? > > Personally I would prefer not to force such a restriction on anyone. You cannot get the bear's fur without killing him first. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 39 ==========================** Date: Tue, 7 Jan 2003 13:47:01 +0100 From: Holger Veit Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 12:44:36PM +0000, John Poltorak wrote: > On Tue, Jan 07, 2003 at 03:15:50PM +0300, nickk wrote: > > On Tue, 7 Jan 2003 22:19:09 +1100 (AED), Nicholas Sheppard wrote: > > > > I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling > > functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) > > structure and location and also provides access control for users. The sshd from latest openssh already uses this > > api ;) > > As I understand it, this will restrict usage to people running W4 FP13+. > > Is that the case? > > Personally I would prefer not to force such a restriction on anyone. You cannot get the bear's fur without killing him first. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 40 ==========================** Date: Tue, 07 Jan 2003 13:53:22 -0600 From: email at eracc.hypermart.net (ERACC Lists) Subject: Re: PASSWD handling In: <20030107193823.G83 at manninghammills.org> On: Tue, 7 Jan 2003 19:38:23 +0000 Screaming: Re: PASSWD handling John Poltorak did rant: [...] +Personally, I have no idea which version of OS/2 most people use, +although I suspect the majority on this list are reasonably up to date. [...] We are still running Warp 4 FP 12. Plan to move to eCS once cash flow gets better. :-) Gene -- +=========================-=>Unix & OS/2<=-=========================+ # Owner and C.E.O. - ERA Computer Consulting - Jackson, TN USA # # eCS,OS/2,UnixWare,OpenServer & Linux Business Computing Solutions # # Please visit our www pages at http://eracc.hypermart.net/ # +===================================================================+ We run IBM OS/2 v.4.00, Revision 9.036 Sysinfo: 40 Processes, 155 Threads, uptime is 7d 0h 11m 24s 275ms **= Email 41 ==========================** Date: Tue, 07 Jan 2003 13:53:22 -0600 From: email at eracc.hypermart.net (ERACC Lists) Subject: Re: PASSWD handling In: <20030107193823.G83 at manninghammills.org> On: Tue, 7 Jan 2003 19:38:23 +0000 Screaming: Re: PASSWD handling John Poltorak did rant: [...] +Personally, I have no idea which version of OS/2 most people use, +although I suspect the majority on this list are reasonably up to date. [...] We are still running Warp 4 FP 12. Plan to move to eCS once cash flow gets better. :-) Gene -- +=========================-=>Unix & OS/2<=-=========================+ # Owner and C.E.O. - ERA Computer Consulting - Jackson, TN USA # # eCS,OS/2,UnixWare,OpenServer & Linux Business Computing Solutions # # Please visit our www pages at http://eracc.hypermart.net/ # +===================================================================+ We run IBM OS/2 v.4.00, Revision 9.036 Sysinfo: 40 Processes, 155 Threads, uptime is 7d 0h 11m 24s 275ms **= Email 42 ==========================** Date: Tue, 07 Jan 2003 13:58:54 +0100 (CET) From: "Adrian Gschwend" Subject: Re: PASSWD handling On Tue, 07 Jan 2003 15:15:50 +0300 (MSK), nickk wrote: Hi Nickk! >I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling >functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) >structure and location and also provides access control for users. The sshd from latest openssh already uses this >api ;) Nice to have you here finaly :-) The discussion right now is about how to handle the passwd handling as you noticed I guess. Holger proposed to have it exactly like on unix systems for 100% compatibility, without any $ or ; for driveletter compatibility in it. I forward you the mail from Holger about it separately. You might give some comments about your way because you defined that in Security/2 cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 43 ==========================** Date: Tue, 07 Jan 2003 13:58:54 +0100 (CET) From: "Adrian Gschwend" Subject: Re: PASSWD handling On Tue, 07 Jan 2003 15:15:50 +0300 (MSK), nickk wrote: Hi Nickk! >I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling >functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) >structure and location and also provides access control for users. The sshd from latest openssh already uses this >api ;) Nice to have you here finaly :-) The discussion right now is about how to handle the passwd handling as you noticed I guess. Holger proposed to have it exactly like on unix systems for 100% compatibility, without any $ or ; for driveletter compatibility in it. I forward you the mail from Holger about it separately. You might give some comments about your way because you defined that in Security/2 cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 44 ==========================** Date: Tue, 07 Jan 2003 14:07:11 +0100 (CET) From: "Adrian Gschwend" Subject: Re: PASSWD handling On Tue, 7 Jan 2003 13:47:01 +0100, Holger Veit wrote: >> Personally I would prefer not to force such a restriction on anyone. > >You cannot get the bear's fur without killing him first. I agree with that. You can get fixpacks who provide what we need even for Warp3 so this should definitely not be a problem. Otherwise we run into hacks and this leads to nowhere. Same goes for kernel upgrades. Unixos2 users are mostly professionals I would say so no problem. cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 45 ==========================** Date: Tue, 07 Jan 2003 14:07:11 +0100 (CET) From: "Adrian Gschwend" Subject: Re: PASSWD handling On Tue, 7 Jan 2003 13:47:01 +0100, Holger Veit wrote: >> Personally I would prefer not to force such a restriction on anyone. > >You cannot get the bear's fur without killing him first. I agree with that. You can get fixpacks who provide what we need even for Warp3 so this should definitely not be a problem. Otherwise we run into hacks and this leads to nowhere. Same goes for kernel upgrades. Unixos2 users are mostly professionals I would say so no problem. cu Adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 46 ==========================** Date: Tue, 7 Jan 2003 14:25:08 -0500 From: Thomas Dickey Subject: Re: Ncurses problem? On Tue, Jan 07, 2003 at 10:32:47AM +0000, John Poltorak wrote: > > I'm not sure if this is a problem or not, but I noticed this msg whilst > building NCURSES (5.3) :- > > > sh ./run_tic.sh > ** Building terminfo database, please wait... > ** adjusting tabset paths > Running tic to install c:/usr/share/terminfo ... > > You may see messages regarding unknown capabilities, e.g., AX. > These are extended terminal capabilities which can be compiled > using > tic -x > Read the INSTALL document before doing this - it can cause > problems for older ncurses applications. > > 38 entries written to /usr/share/terminfo > ** built new c:/usr/share/terminfo > cp: ../share/terminfo: No such file or directory I'm not sure: you reported this before, and I did look at the script, but didn't see what was wrong. Perhaps some environment variable is triggering this... > > > Everything appears to have been built and installed correctly, so I'm not > sure what the msg is saying. > > > -- > John > > > > -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 47 ==========================** Date: Tue, 7 Jan 2003 14:25:08 -0500 From: Thomas Dickey Subject: Re: Ncurses problem? On Tue, Jan 07, 2003 at 10:32:47AM +0000, John Poltorak wrote: > > I'm not sure if this is a problem or not, but I noticed this msg whilst > building NCURSES (5.3) :- > > > sh ./run_tic.sh > ** Building terminfo database, please wait... > ** adjusting tabset paths > Running tic to install c:/usr/share/terminfo ... > > You may see messages regarding unknown capabilities, e.g., AX. > These are extended terminal capabilities which can be compiled > using > tic -x > Read the INSTALL document before doing this - it can cause > problems for older ncurses applications. > > 38 entries written to /usr/share/terminfo > ** built new c:/usr/share/terminfo > cp: ../share/terminfo: No such file or directory I'm not sure: you reported this before, and I did look at the script, but didn't see what was wrong. Perhaps some environment variable is triggering this... > > > Everything appears to have been built and installed correctly, so I'm not > sure what the msg is saying. > > > -- > John > > > > -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 48 ==========================** Date: Tue, 7 Jan 2003 14:56:09 +0000 From: John Poltorak Subject: Re: mmap() On Tue, Jan 07, 2003 at 04:06:18PM +0200, Sergey Yevtushenko wrote: > John Poltorak wrote: > > > Thanks for the pointer. If anyone wants to read it, check:- > > > > http://www.edm2.com/0610/memorymap.html > > > > How functional is your library and do have any plans for it? > > It has some limitations (no serialization, no support for anonymous > mapping, etc). Unfortunately I have no time to work on it futher > to make it more complete/useable. Is the source available anywhere? > > My search for mmap found this:- > > > > http://hobbes.nmsu.edu/pub/os2/dev/unix/mmap-1.77.zip > > > > which was written by someone else. Do you know how complete this one is? > > There are no sources, so I can only guess how correct/complete it is. I guess it would be possible to try it out an see how far it gets with any builds which require it. Does anyone have any contact with Maurilio Longo? I notice Yuri was mentioned in one of the docs... > Regards, > Sergey. > -- John **= Email 49 ==========================** Date: Tue, 7 Jan 2003 14:56:09 +0000 From: John Poltorak Subject: Re: mmap() On Tue, Jan 07, 2003 at 04:06:18PM +0200, Sergey Yevtushenko wrote: > John Poltorak wrote: > > > Thanks for the pointer. If anyone wants to read it, check:- > > > > http://www.edm2.com/0610/memorymap.html > > > > How functional is your library and do have any plans for it? > > It has some limitations (no serialization, no support for anonymous > mapping, etc). Unfortunately I have no time to work on it futher > to make it more complete/useable. Is the source available anywhere? > > My search for mmap found this:- > > > > http://hobbes.nmsu.edu/pub/os2/dev/unix/mmap-1.77.zip > > > > which was written by someone else. Do you know how complete this one is? > > There are no sources, so I can only guess how correct/complete it is. I guess it would be possible to try it out an see how far it gets with any builds which require it. Does anyone have any contact with Maurilio Longo? I notice Yuri was mentioned in one of the docs... > Regards, > Sergey. > -- John **= Email 50 ==========================** Date: Tue, 07 Jan 2003 14:57:13 +0200 From: Sergey Yevtushenko Subject: Re: mmap() John Poltorak wrote: > Just looking through the INSTALL file for INN it says:- > > > So far as possible, INN is written in portable C and should work on any > Unix platform. It does, however, make extensive use of mmap() and > certain other constructs that may be poorly or incompletely implemented, > particularly on old operating systems. > > > > Before I try building this thing, where do we stand with mmap() on OS/2? Some time ago I wrote implementation of memory mapped files for OS/2, but it definitely not a direct replacement for mmap(). Also, that implementation was primarily a "proof of concept" rather than finished library, so it requires some work before use. Article and sources can be found at EDM/2. Regards, Sergey. **= Email 51 ==========================** Date: Tue, 07 Jan 2003 14:57:13 +0200 From: Sergey Yevtushenko Subject: Re: mmap() John Poltorak wrote: > Just looking through the INSTALL file for INN it says:- > > > So far as possible, INN is written in portable C and should work on any > Unix platform. It does, however, make extensive use of mmap() and > certain other constructs that may be poorly or incompletely implemented, > particularly on old operating systems. > > > > Before I try building this thing, where do we stand with mmap() on OS/2? Some time ago I wrote implementation of memory mapped files for OS/2, but it definitely not a direct replacement for mmap(). Also, that implementation was primarily a "proof of concept" rather than finished library, so it requires some work before use. Article and sources can be found at EDM/2. Regards, Sergey. **= Email 52 ==========================** Date: Tue, 07 Jan 2003 15:15:50 +0300 (MSK) From: "nickk" Subject: Re: PASSWD handling On Tue, 7 Jan 2003 22:19:09 +1100 (AED), Nicholas Sheppard wrote: >> Will any changes need to be made as a result of a new passwd handler? > >I guess that depends on what the old passwd handlers look like. In most >cases (e.g. sshd and ipop3d) I expect it's just a matter of deleting the >internal re-implementation of getpwnam() and instead linking with the new >passwd handler. I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) structure and location and also provides access control for users. The sshd from latest openssh already uses this api ;) cu, nickk **= Email 53 ==========================** Date: Tue, 07 Jan 2003 15:15:50 +0300 (MSK) From: "nickk" Subject: Re: PASSWD handling On Tue, 7 Jan 2003 22:19:09 +1100 (AED), Nicholas Sheppard wrote: >> Will any changes need to be made as a result of a new passwd handler? > >I guess that depends on what the old passwd handlers look like. In most >cases (e.g. sshd and ipop3d) I expect it's just a matter of deleting the >internal re-implementation of getpwnam() and instead linking with the new >passwd handler. I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) structure and location and also provides access control for users. The sshd from latest openssh already uses this api ;) cu, nickk **= Email 54 ==========================** Date: Tue, 7 Jan 2003 15:57:16 +0000 From: John Poltorak Subject: Re: realtime chat On Tue, Jan 07, 2003 at 10:37:13PM +1100, Nicholas Sheppard wrote: > On Sun, 5 Jan 2003, Ken Ames wrote: > > > 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. > > I'm guessing from the dearth of replies to this that the answer is "no" > but I'd be happy to hang around on one if it existed, though I think my > time zone is fairly remote from most of the people on this list. Computer people seem to keep odd hours, so you can never be sure when people are around... As far as IRC servers go, which is the most popular one around and has it been ported to OS/2? I've never even tried setting one up so may give it a try... > Nicholas S. > > |\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule > |\ E-mail: nps at zeta.org.au | who has failed to establish it. > | WWW: http://www.zeta.org.au/~nps | > | ---> Cynicism & Negativity | - Ambrose Bierce -- John **= Email 55 ==========================** Date: Tue, 7 Jan 2003 15:57:16 +0000 From: John Poltorak Subject: Re: realtime chat On Tue, Jan 07, 2003 at 10:37:13PM +1100, Nicholas Sheppard wrote: > On Sun, 5 Jan 2003, Ken Ames wrote: > > > 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. > > I'm guessing from the dearth of replies to this that the answer is "no" > but I'd be happy to hang around on one if it existed, though I think my > time zone is fairly remote from most of the people on this list. Computer people seem to keep odd hours, so you can never be sure when people are around... As far as IRC servers go, which is the most popular one around and has it been ported to OS/2? I've never even tried setting one up so may give it a try... > Nicholas S. > > |\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule > |\ E-mail: nps at zeta.org.au | who has failed to establish it. > | WWW: http://www.zeta.org.au/~nps | > | ---> Cynicism & Negativity | - Ambrose Bierce -- John **= Email 56 ==========================** Date: Tue, 07 Jan 2003 16:06:18 +0200 From: Sergey Yevtushenko Subject: Re: mmap() John Poltorak wrote: > Thanks for the pointer. If anyone wants to read it, check:- > > http://www.edm2.com/0610/memorymap.html > > How functional is your library and do have any plans for it? It has some limitations (no serialization, no support for anonymous mapping, etc). Unfortunately I have no time to work on it futher to make it more complete/useable. > My search for mmap found this:- > > http://hobbes.nmsu.edu/pub/os2/dev/unix/mmap-1.77.zip > > which was written by someone else. Do you know how complete this one is? There are no sources, so I can only guess how correct/complete it is. Regards, Sergey. **= Email 57 ==========================** Date: Tue, 07 Jan 2003 16:06:18 +0200 From: Sergey Yevtushenko Subject: Re: mmap() John Poltorak wrote: > Thanks for the pointer. If anyone wants to read it, check:- > > http://www.edm2.com/0610/memorymap.html > > How functional is your library and do have any plans for it? It has some limitations (no serialization, no support for anonymous mapping, etc). Unfortunately I have no time to work on it futher to make it more complete/useable. > My search for mmap found this:- > > http://hobbes.nmsu.edu/pub/os2/dev/unix/mmap-1.77.zip > > which was written by someone else. Do you know how complete this one is? There are no sources, so I can only guess how correct/complete it is. Regards, Sergey. **= Email 58 ==========================** Date: Tue, 7 Jan 2003 17:25:52 +0000 From: John Poltorak Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 07:43:42PM +0300, nickk wrote: > I think, we must remember that OS/2 is not Unix and we should use OS/2 native anvantages and not just make > another unix clone ;) I would like to think we can use OS/2 as a superset of Unix. I welcome OS/2 enhancements such as those in TAR which can handle EAs for example. My principle concern is creating an environment which will allow Unix apps to be built as transparently as possible and with little effort. If an OS/2 feature can be added, so much the better, however, we are in danger, as with TAR of having an unsupported and unmaintainable program if the maintainer disappears. -- John **= Email 59 ==========================** Date: Tue, 7 Jan 2003 17:25:52 +0000 From: John Poltorak Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 07:43:42PM +0300, nickk wrote: > I think, we must remember that OS/2 is not Unix and we should use OS/2 native anvantages and not just make > another unix clone ;) I would like to think we can use OS/2 as a superset of Unix. I welcome OS/2 enhancements such as those in TAR which can handle EAs for example. My principle concern is creating an environment which will allow Unix apps to be built as transparently as possible and with little effort. If an OS/2 feature can be added, so much the better, however, we are in danger, as with TAR of having an unsupported and unmaintainable program if the maintainer disappears. -- John **= Email 60 ==========================** Date: Tue, 07 Jan 2003 17:51:17 +0200 From: Sergey Yevtushenko Subject: Re: mmap() John Poltorak wrote: >>It has some limitations (no serialization, no support for anonymous >>mapping, etc). Unfortunately I have no time to work on it futher >>to make it more complete/useable. > > > Is the source available anywhere? As usual, in appropriate source code bundle: http://www.edm2.com/zips/edm0610s.zip Regads, Sergey. **= Email 61 ==========================** Date: Tue, 07 Jan 2003 17:51:17 +0200 From: Sergey Yevtushenko Subject: Re: mmap() John Poltorak wrote: >>It has some limitations (no serialization, no support for anonymous >>mapping, etc). Unfortunately I have no time to work on it futher >>to make it more complete/useable. > > > Is the source available anywhere? As usual, in appropriate source code bundle: http://www.edm2.com/zips/edm0610s.zip Regads, Sergey. **= Email 62 ==========================** Date: Tue, 7 Jan 2003 18:20:00 +0100 (CET) From: Stefan Neis Subject: Re: shadow-4.0.3 passwords Hi, > below you said that you would like to maintain Posix/2 from now on, > didn't you? ;-) No, not really. I don't like to make promises as my time is way to limited... > 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 ... Great, go ahead... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 63 ==========================** Date: Tue, 7 Jan 2003 18:20:00 +0100 (CET) From: Stefan Neis Subject: Re: shadow-4.0.3 passwords Hi, > below you said that you would like to maintain Posix/2 from now on, > didn't you? ;-) No, not really. I don't like to make promises as my time is way to limited... > 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 ... Great, go ahead... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 64 ==========================** Date: Tue, 7 Jan 2003 18:27:11 +0100 (CET) From: Stefan Neis Subject: Re: [Fwd: failure notice]was: R On Sun, 5 Jan 2003, Thomas Hoffmann wrote: > 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". But using which autoconf version? wxWindows for example is still using 2.13 even though most (All?) of the "bugs" for autoconf-2.5x seem to be fixed, meanwhile. Or if they are using 2.56 and you are using something slightly older, that might also explain your problem. In short: Make sure you're using the exact same version on OS/2 that others are using on Unix... :-( > 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 ... I see... Regards, Stefan **= Email 65 ==========================** Date: Tue, 7 Jan 2003 18:27:11 +0100 (CET) From: Stefan Neis Subject: Re: [Fwd: failure notice]was: R On Sun, 5 Jan 2003, Thomas Hoffmann wrote: > 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". But using which autoconf version? wxWindows for example is still using 2.13 even though most (All?) of the "bugs" for autoconf-2.5x seem to be fixed, meanwhile. Or if they are using 2.56 and you are using something slightly older, that might also explain your problem. In short: Make sure you're using the exact same version on OS/2 that others are using on Unix... :-( > 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 ... I see... Regards, Stefan **= Email 66 ==========================** Date: Tue, 7 Jan 2003 18:30:40 +0100 (CET) From: Stefan Neis Subject: Re: header problems? On Mon, 6 Jan 2003, Ted Sikora wrote: (My speculation about missing cExt) > No I had it. Why do the simple explanations never work? :-( Anyway, that missing symbol sounds like one that should be within cExt.a. Maybe a problem with ordering? -lcExt should be add the very end of the line... Regards, Stefan **= Email 67 ==========================** Date: Tue, 7 Jan 2003 18:30:40 +0100 (CET) From: Stefan Neis Subject: Re: header problems? On Mon, 6 Jan 2003, Ted Sikora wrote: (My speculation about missing cExt) > No I had it. Why do the simple explanations never work? :-( Anyway, that missing symbol sounds like one that should be within cExt.a. Maybe a problem with ordering? -lcExt should be add the very end of the line... Regards, Stefan **= Email 68 ==========================** Date: Tue, 07 Jan 2003 18:59:19 +0100 (CET) From: "Adrian Gschwend" Subject: Re: realtime chat On Tue, 07 Jan 2003 09:44:46 -0800, Ken Ames wrote: > actually, we wouldn't need to set one up, we could use an existing irc >network like irc.openprojects.net or even on irc.anduin.net where >#netlabs is run. the latter one is a private server run by Eiric Overby >aka Ltning so we could just ask him. I would appreciate such a channel as well, even if just a few of you can be online it's a benefit for the project. I would propose to open a #unixos2 channel on irc.anduin.net. Ltning won't have a problem with that. Created it now, I will join the next days and I hope I'm not the only one :-) cu adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 69 ==========================** Date: Tue, 07 Jan 2003 18:59:19 +0100 (CET) From: "Adrian Gschwend" Subject: Re: realtime chat On Tue, 07 Jan 2003 09:44:46 -0800, Ken Ames wrote: > actually, we wouldn't need to set one up, we could use an existing irc >network like irc.openprojects.net or even on irc.anduin.net where >#netlabs is run. the latter one is a private server run by Eiric Overby >aka Ltning so we could just ask him. I would appreciate such a channel as well, even if just a few of you can be online it's a benefit for the project. I would propose to open a #unixos2 channel on irc.anduin.net. Ltning won't have a problem with that. Created it now, I will join the next days and I hope I'm not the only one :-) cu adrian -- Adrian Gschwend at netlabs.org ktk [a t] netlabs.org ------- Free Software for OS/2 and eCS http://www.netlabs.org **= Email 70 ==========================** Date: Tue, 07 Jan 2003 19:33:25 +0300 (MSK) From: "nickk" Subject: Re: PASSWD handling On Tue, 7 Jan 2003 12:44:36 +0000, John Poltorak wrote: >> >> I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling >> functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) >> structure and location and also provides access control for users. The sshd from latest openssh already uses this >> api ;) > >As I understand it, this will restrict usage to people running W4 FP13+. > >Is that the case? > >Personally I would prefer not to force such a restriction on anyone. There is no strict dependence between Security/2 able to run and OS/2 fixpack level. Some os/2 kernels have bugs in SES KPI, some works ok. The actual OS/2 revisions suitable for Security/2 can be determined only after testing. Currently, i know only that ACP1 kernel 14.062 has bugs. Except kernel there is not other modules that may broke Security/2 work. Also, i do not think that providing a broad compatibility for all os/2 systems is wise decision, thus ibm closes support for old revisions. We already have mostly 16 bit os/2 kernel as the result of such approach. **= Email 71 ==========================** Date: Tue, 07 Jan 2003 19:33:25 +0300 (MSK) From: "nickk" Subject: Re: PASSWD handling On Tue, 7 Jan 2003 12:44:36 +0000, John Poltorak wrote: >> >> I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling >> functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) >> structure and location and also provides access control for users. The sshd from latest openssh already uses this >> api ;) > >As I understand it, this will restrict usage to people running W4 FP13+. > >Is that the case? > >Personally I would prefer not to force such a restriction on anyone. There is no strict dependence between Security/2 able to run and OS/2 fixpack level. Some os/2 kernels have bugs in SES KPI, some works ok. The actual OS/2 revisions suitable for Security/2 can be determined only after testing. Currently, i know only that ACP1 kernel 14.062 has bugs. Except kernel there is not other modules that may broke Security/2 work. Also, i do not think that providing a broad compatibility for all os/2 systems is wise decision, thus ibm closes support for old revisions. We already have mostly 16 bit os/2 kernel as the result of such approach. **= Email 72 ==========================** Date: Tue, 7 Jan 2003 19:38:23 +0000 From: John Poltorak Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 07:33:25PM +0300, nickk wrote: > On Tue, 7 Jan 2003 12:44:36 +0000, John Poltorak wrote: > > >> > >> I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling > >> functions. This api is independable of actual user base (it may be passwd file or sql database or anything you > like) > >> structure and location and also provides access control for users. The sshd from latest openssh already uses > this > >> api ;) > > > >As I understand it, this will restrict usage to people running W4 FP13+. > > > >Is that the case? > > > >Personally I would prefer not to force such a restriction on anyone. > > There is no strict dependence between Security/2 able to run and OS/2 fixpack level. Some os/2 kernels have bugs > in SES KPI, some works ok. The actual OS/2 revisions suitable for Security/2 can be determined only after testing. > Currently, i know only that ACP1 kernel 14.062 has bugs. Except kernel there is not other modules that may broke > Security/2 work. > > Also, i do not think that providing a broad compatibility for all os/2 systems is wise decision, thus ibm closes > support for old revisions. We already have mostly 16 bit os/2 kernel as the result of such approach. I just don't like the idea of forcing people to upgrade systems which are running perfectly well - it has the smell of upgraditis and reminds me too much of the Microsoft way. Personally, I have no idea which version of OS/2 most people use, although I suspect the majority on this list are reasonably up to date. I remember upgrading to FP13 was a major struggle on one of my systems and discovered it simply wouldn't run, so now I have to remember that certain programs simply won't work on that machine - this came as something of a culture shock as every version of OS/2 I had ever tried would run on every machine I had. I suspect the majority of OS/2 users are not running a version at the required level to use SES and I wouldn't want to alienate them. Would it be passible to use SES if detected and something else if not? -- John **= Email 73 ==========================** Date: Tue, 7 Jan 2003 19:38:23 +0000 From: John Poltorak Subject: Re: PASSWD handling On Tue, Jan 07, 2003 at 07:33:25PM +0300, nickk wrote: > On Tue, 7 Jan 2003 12:44:36 +0000, John Poltorak wrote: > > >> > >> I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling > >> functions. This api is independable of actual user base (it may be passwd file or sql database or anything you > like) > >> structure and location and also provides access control for users. The sshd from latest openssh already uses > this > >> api ;) > > > >As I understand it, this will restrict usage to people running W4 FP13+. > > > >Is that the case? > > > >Personally I would prefer not to force such a restriction on anyone. > > There is no strict dependence between Security/2 able to run and OS/2 fixpack level. Some os/2 kernels have bugs > in SES KPI, some works ok. The actual OS/2 revisions suitable for Security/2 can be determined only after testing. > Currently, i know only that ACP1 kernel 14.062 has bugs. Except kernel there is not other modules that may broke > Security/2 work. > > Also, i do not think that providing a broad compatibility for all os/2 systems is wise decision, thus ibm closes > support for old revisions. We already have mostly 16 bit os/2 kernel as the result of such approach. I just don't like the idea of forcing people to upgrade systems which are running perfectly well - it has the smell of upgraditis and reminds me too much of the Microsoft way. Personally, I have no idea which version of OS/2 most people use, although I suspect the majority on this list are reasonably up to date. I remember upgrading to FP13 was a major struggle on one of my systems and discovered it simply wouldn't run, so now I have to remember that certain programs simply won't work on that machine - this came as something of a culture shock as every version of OS/2 I had ever tried would run on every machine I had. I suspect the majority of OS/2 users are not running a version at the required level to use SES and I wouldn't want to alienate them. Would it be passible to use SES if detected and something else if not? -- John **= Email 74 ==========================** Date: Tue, 07 Jan 2003 19:43:42 +0300 (MSK) From: "nickk" Subject: Re: PASSWD handling Hi! On Tue, 07 Jan 2003 13:58:54 +0100 (CET), Adrian Gschwend wrote: >>I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling >>functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) >>structure and location and also provides access control for users. The sshd from latest openssh already uses this >>api ;) > >Nice to have you here finaly :-) The discussion right now is about how >to handle the passwd handling as you noticed I guess. Holger proposed >to have it exactly like on unix systems for 100% compatibility, without >any $ or ; for driveletter compatibility in it. I forward you the mail >from Holger about it separately. > >You might give some comments about your way because you defined that in >Security/2 I defined in my passwd.dll slighlty modified version of passwd library that was used in older sshd package. But, it does not matter (at least for me :)), because i do think that the actual format of passwd file (if it even will exist) should not be known for user or programmer. He uses only getpwnam() and other functions to get unix-like pw structure. Everyone can replace passwd.dll from Security/2 to his own dll of given format and define user base to any format, style, location. I think, we must remember that OS/2 is not Unix and we should use OS/2 native anvantages and not just make another unix clone ;) **= Email 75 ==========================** Date: Tue, 07 Jan 2003 19:43:42 +0300 (MSK) From: "nickk" Subject: Re: PASSWD handling Hi! On Tue, 07 Jan 2003 13:58:54 +0100 (CET), Adrian Gschwend wrote: >>I'd like you look to the Security/2 API as the base for implementation of getpwnam() and other passwd handling >>functions. This api is independable of actual user base (it may be passwd file or sql database or anything you like) >>structure and location and also provides access control for users. The sshd from latest openssh already uses this >>api ;) > >Nice to have you here finaly :-) The discussion right now is about how >to handle the passwd handling as you noticed I guess. Holger proposed >to have it exactly like on unix systems for 100% compatibility, without >any $ or ; for driveletter compatibility in it. I forward you the mail >from Holger about it separately. > >You might give some comments about your way because you defined that in >Security/2 I defined in my passwd.dll slighlty modified version of passwd library that was used in older sshd package. But, it does not matter (at least for me :)), because i do think that the actual format of passwd file (if it even will exist) should not be known for user or programmer. He uses only getpwnam() and other functions to get unix-like pw structure. Everyone can replace passwd.dll from Security/2 to his own dll of given format and define user base to any format, style, location. I think, we must remember that OS/2 is not Unix and we should use OS/2 native anvantages and not just make another unix clone ;) **= Email 76 ==========================** Date: Tue, 7 Jan 2003 20:48:05 +0000 From: John Poltorak Subject: Re: Single UNIX Specification On Tue, Jan 07, 2003 at 12:33:41PM -0800, Steve Wendt wrote: > On Tue, 7 Jan 2003, John Poltorak wrote: > > > which lists all the Commands and Utilities that are part of a Single UNIX > > Specification, Version 2. > > > > Does anyone know whether this list is generally accepted amongst Unix > > vendors and if so whether it has been updated? > > Looks like version 3 was recently approved: > http://www.opengroup.org/comm/press/14nov02.htm Thanks for that. I think a few people should have a look at:- http://www.unix.org/version3 It would be nice to have UnixOS/2 as compliant as possible. > It's sponsored by IBM, HP, Sun, etc. so I would say it *is* "generally > accepted amongst Unix vendors" I guess the Unix specification produced must be as definitive as you can get. -- John **= Email 77 ==========================** Date: Tue, 7 Jan 2003 20:48:05 +0000 From: John Poltorak Subject: Re: Single UNIX Specification On Tue, Jan 07, 2003 at 12:33:41PM -0800, Steve Wendt wrote: > On Tue, 7 Jan 2003, John Poltorak wrote: > > > which lists all the Commands and Utilities that are part of a Single UNIX > > Specification, Version 2. > > > > Does anyone know whether this list is generally accepted amongst Unix > > vendors and if so whether it has been updated? > > Looks like version 3 was recently approved: > http://www.opengroup.org/comm/press/14nov02.htm Thanks for that. I think a few people should have a look at:- http://www.unix.org/version3 It would be nice to have UnixOS/2 as compliant as possible. > It's sponsored by IBM, HP, Sun, etc. so I would say it *is* "generally > accepted amongst Unix vendors" I guess the Unix specification produced must be as definitive as you can get. -- John **= Email 78 ==========================** Date: Tue, 07 Jan 2003 21:36:20 +0100 (CET) From: "Christian Hennecke" Subject: Re: Internet Software Consortium apps On Tue, 7 Jan 2003 12:07:06 +0000, John Poltorak wrote: >ISC maintain three important open source apps; BIND, DHCP and INN. > >I know there is an older version of BIND available for OS/2 but it appears >difficult to maintain... Has anyone tried building any of these apps >straight from the original source? Maybe the same tricks could be used to >get them all to build on OS/2. What are the likely stumbling blocks? I haven't tried, but I would like to add that it would be really nice to have an alternative to Changi, the only (?) NNTP server for OS/2. Changi apparently has a few issues and it isn't maintained any more. Christian Hennecke **= Email 79 ==========================** Date: Tue, 07 Jan 2003 21:36:20 +0100 (CET) From: "Christian Hennecke" Subject: Re: Internet Software Consortium apps On Tue, 7 Jan 2003 12:07:06 +0000, John Poltorak wrote: >ISC maintain three important open source apps; BIND, DHCP and INN. > >I know there is an older version of BIND available for OS/2 but it appears >difficult to maintain... Has anyone tried building any of these apps >straight from the original source? Maybe the same tricks could be used to >get them all to build on OS/2. What are the likely stumbling blocks? I haven't tried, but I would like to add that it would be really nice to have an alternative to Changi, the only (?) NNTP server for OS/2. Changi apparently has a few issues and it isn't maintained any more. Christian Hennecke **= Email 80 ==========================** Date: Tue, 7 Jan 2003 22:19:09 +1100 (AED) From: Nicholas Sheppard Subject: Re: PASSWD handling On Tue, 7 Jan 2003, John Poltorak wrote: > Will any changes need to be made as a result of a new passwd handler? I guess that depends on what the old passwd handlers look like. In most cases (e.g. sshd and ipop3d) I expect it's just a matter of deleting the internal re-implementation of getpwnam() and instead linking with the new passwd handler. > Will we need to convert passwd from one format to another? If you use old applications with differing formats you will, but that has nothing to do with a new handler. The new handler can read all the old formats so that new (or re-built) applications shouldn't need passwd to be converted, though any new entries will be written in the new format so that the old formats will gradually disappear. Converting old entries may have some advantages, however, e.g. if you want to parse passwd with a shell script. > Will we need to migrate to new versions of some apps? Applications that use old formats would need to be re-built before they are able to understand the new format. So, yes, unless you don't need your old-format application to co-operate with any other applications. > We also need to make sure it is accepted by everyone who maintains an app > which accesses passwd. Being first-to-market might be enough to do that. If a passwd.lib gets released, works, and is sufficiently well-known, then no one's going to re-implement another one. The "sufficiently well-known" part is where we could fall down (e.g. I wasn't aware of Kai Uwe Rommel's format when I was deciding what to do with ipop3d), but if this list and related projects like Posix/2 account for everyone porting Unix applications, then I imagine we should be okay, at least if we are porting Unix applications. People who aren't porting from Unix may have other ideas about multiple users, I don't know. Has anyone ever written an article about UnixOS/2 etc. for the wider OS/2 community, e.g. in OS/2 e-Zine? > Does it mean that any apps will need to be modified or rebuilt? Probably, see above. Nicholas S. |\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule |\ E-mail: nps at zeta.org.au | who has failed to establish it. | WWW: http://www.zeta.org.au/~nps | | ---> Cynicism & Negativity | - Ambrose Bierce **= Email 81 ==========================** Date: Tue, 7 Jan 2003 22:19:09 +1100 (AED) From: Nicholas Sheppard Subject: Re: PASSWD handling On Tue, 7 Jan 2003, John Poltorak wrote: > Will any changes need to be made as a result of a new passwd handler? I guess that depends on what the old passwd handlers look like. In most cases (e.g. sshd and ipop3d) I expect it's just a matter of deleting the internal re-implementation of getpwnam() and instead linking with the new passwd handler. > Will we need to convert passwd from one format to another? If you use old applications with differing formats you will, but that has nothing to do with a new handler. The new handler can read all the old formats so that new (or re-built) applications shouldn't need passwd to be converted, though any new entries will be written in the new format so that the old formats will gradually disappear. Converting old entries may have some advantages, however, e.g. if you want to parse passwd with a shell script. > Will we need to migrate to new versions of some apps? Applications that use old formats would need to be re-built before they are able to understand the new format. So, yes, unless you don't need your old-format application to co-operate with any other applications. > We also need to make sure it is accepted by everyone who maintains an app > which accesses passwd. Being first-to-market might be enough to do that. If a passwd.lib gets released, works, and is sufficiently well-known, then no one's going to re-implement another one. The "sufficiently well-known" part is where we could fall down (e.g. I wasn't aware of Kai Uwe Rommel's format when I was deciding what to do with ipop3d), but if this list and related projects like Posix/2 account for everyone porting Unix applications, then I imagine we should be okay, at least if we are porting Unix applications. People who aren't porting from Unix may have other ideas about multiple users, I don't know. Has anyone ever written an article about UnixOS/2 etc. for the wider OS/2 community, e.g. in OS/2 e-Zine? > Does it mean that any apps will need to be modified or rebuilt? Probably, see above. Nicholas S. |\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule |\ E-mail: nps at zeta.org.au | who has failed to establish it. | WWW: http://www.zeta.org.au/~nps | | ---> Cynicism & Negativity | - Ambrose Bierce **= Email 82 ==========================** Date: Tue, 7 Jan 2003 22:37:13 +1100 (AED) From: Nicholas Sheppard Subject: Re: realtime chat On Sun, 5 Jan 2003, Ken Ames wrote: > 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. I'm guessing from the dearth of replies to this that the answer is "no" but I'd be happy to hang around on one if it existed, though I think my time zone is fairly remote from most of the people on this list. Nicholas S. |\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule |\ E-mail: nps at zeta.org.au | who has failed to establish it. | WWW: http://www.zeta.org.au/~nps | | ---> Cynicism & Negativity | - Ambrose Bierce **= Email 83 ==========================** Date: Tue, 7 Jan 2003 22:37:13 +1100 (AED) From: Nicholas Sheppard Subject: Re: realtime chat On Sun, 5 Jan 2003, Ken Ames wrote: > 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. I'm guessing from the dearth of replies to this that the answer is "no" but I'd be happy to hang around on one if it existed, though I think my time zone is fairly remote from most of the people on this list. Nicholas S. |\ Location: Wollongong, Australia | REBEL, n. A proponent of a new misrule |\ E-mail: nps at zeta.org.au | who has failed to establish it. | WWW: http://www.zeta.org.au/~nps | | ---> Cynicism & Negativity | - Ambrose Bierce **= Email 84 ==========================** Date: Tue, 07 Jan 2003 22:53:04 +0200 From: Sergey Yevtushenko Subject: Re: PASSWD handling John, > I just don't like the idea of forcing people to upgrade systems which are > running perfectly well - it has the smell of upgraditis and reminds me too > much of the Microsoft way. Nevertheless any software has some, more or less restrictive, system requirements and peoples accepting that. If working system already does what it should, then there is no need to install new software. Installation of the new software means that someone accepts the new system requirements. > > Personally, I have no idea which version of OS/2 most people use, although > I suspect the majority on this list are reasonably up to date. I remember > upgrading to FP13 was a major struggle on one of my systems and discovered > it simply wouldn't run, so now I have to remember that certain programs > simply won't work on that machine - this came as something of a culture > shock as every version of OS/2 I had ever tried would run on every machine > I had. I suspect the majority of OS/2 users are not running a version at > the required level to use SES and I wouldn't want to alienate them. I suspect you met problems with some old software built using Borland tools. If so - just repack binaries using lxlite and this will fix problem with FP#13+. > Would it be passible to use SES if detected and something else if not? I think this can be hidden inside pwd() library. Thanks. **= Email 85 ==========================** Date: Tue, 07 Jan 2003 22:53:04 +0200 From: Sergey Yevtushenko Subject: Re: PASSWD handling John, > I just don't like the idea of forcing people to upgrade systems which are > running perfectly well - it has the smell of upgraditis and reminds me too > much of the Microsoft way. Nevertheless any software has some, more or less restrictive, system requirements and peoples accepting that. If working system already does what it should, then there is no need to install new software. Installation of the new software means that someone accepts the new system requirements. > > Personally, I have no idea which version of OS/2 most people use, although > I suspect the majority on this list are reasonably up to date. I remember > upgrading to FP13 was a major struggle on one of my systems and discovered > it simply wouldn't run, so now I have to remember that certain programs > simply won't work on that machine - this came as something of a culture > shock as every version of OS/2 I had ever tried would run on every machine > I had. I suspect the majority of OS/2 users are not running a version at > the required level to use SES and I wouldn't want to alienate them. I suspect you met problems with some old software built using Borland tools. If so - just repack binaries using lxlite and this will fix problem with FP#13+. > Would it be passible to use SES if detected and something else if not? I think this can be hidden inside pwd() library. Thanks.