From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Mon, 6 Jan 2003 04:47:30 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 5 ************************************************** Sunday 05 January 2003 Number 5 ************************************************** Subjects for today 1 diff ... : Thomas Hoffmann 2 diff ... : Thomas Hoffmann 3 Re: header problems? : Ted Sikora 4 Re: header problems? : Ted Sikora 5 Re: INETD & BOOTPD : Aelfred se leof 6 Re: INETD & BOOTPD : Aelfred se leof 7 Re: gcc and Mozilla : John Poltorak 8 Re: gcc and Mozilla : John Poltorak 9 Re: 'add' program : Thomas E. Dickey" 10 Re: 'add' program : Thomas E. Dickey" 11 Elapsed time : John Poltorak 12 Elapsed time : John Poltorak 13 Re: Elapsed time : Steve Wendt 14 Re: Elapsed time : Steve Wendt 15 Re: 'add' program : John Poltorak 16 Re: 'add' program : John Poltorak 17 Re: Elapsed time : John Poltorak 18 Re: Elapsed time : John Poltorak 19 Re: PASSWD handling : John Poltorak 20 Re: PASSWD handling : John Poltorak 21 Re: 'add' program : John Poltorak 22 Re: 'add' program : John Poltorak 23 Re: PASSWD handling : Andreas Buening 24 Re: PASSWD handling : Andreas Buening 25 Re: INETD & BOOTPD : John Poltorak 26 Re: INETD & BOOTPD : John Poltorak 27 Re: diff ... : John Poltorak 28 Re: diff ... : John Poltorak 29 Re: INETD & BOOTPD : John Poltorak 30 Re: INETD & BOOTPD : John Poltorak 31 Re: Drive letters : Holger Veit 32 Re: Drive letters : Holger Veit 33 Re: diff ... : Thomas Hoffmann 34 Re: diff ... : Thomas Hoffmann **= Email 1 ==========================** Date: Mon, 06 Jan 2003 00:18:18 +0100 From: Thomas Hoffmann Subject: diff ... One more victim of the address change ... > I noticed that the new diff.exe from Jun's diffutils 2.8 is plagued by > the same error as its predecessor (see attachment). > > Jun, can you look into this please? Or maybe anybody else can try this > and possibly build the package from scratch (diffutils is rather simple: > 4 executables, no dlls) (John??) > > > --------------010002040507070405030203 > Content-Type: message/rfc822; > name="OS/2's GNUdiff and input from stdio" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="OS/2's GNUdiff and input from stdio" > > Message-ID: <3BBCE3E9.A99B43A6 at zappa.sax.de> > Date: Thu, 04 Oct 2001 23:34:17 +0100 > From: Thomas Hoffmann > X-Mailer: Mozilla 4.61 [de] (OS/2; U) > X-Accept-Language: de > MIME-Version: 1.0 > To: os2-unix list > Subject: OS/2's GNUdiff and input from stdio > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > I tried to pipe the output of a program into OS/2's GNUdiff (it says it > would be v.2.7.1, it is the one from the archive from leo): > > cat bla1 | diff bla2 - > > and got the response > > diff.exe: -: Invalid seek > > So I tried to rebuild the diffutils from (configure.in-)scratch and got > a diff.exe > that can handle the above input (I used libcext, because this is the > "active" > library on my computer at the moment). > > Because I regard(ed) diff not only as stone old, but also as rock solid, > I am > a bit afraid to screw up something. Can anybody comment on my above > observation > and what should be done? > > Thomas. > > > --------------010002040507070405030203-- > > **= Email 2 ==========================** Date: Mon, 06 Jan 2003 00:18:18 +0100 From: Thomas Hoffmann Subject: diff ... One more victim of the address change ... > I noticed that the new diff.exe from Jun's diffutils 2.8 is plagued by > the same error as its predecessor (see attachment). > > Jun, can you look into this please? Or maybe anybody else can try this > and possibly build the package from scratch (diffutils is rather simple: > 4 executables, no dlls) (John??) > > > --------------010002040507070405030203 > Content-Type: message/rfc822; > name="OS/2's GNUdiff and input from stdio" > Content-Transfer-Encoding: 7bit > Content-Disposition: inline; > filename="OS/2's GNUdiff and input from stdio" > > Message-ID: <3BBCE3E9.A99B43A6 at zappa.sax.de> > Date: Thu, 04 Oct 2001 23:34:17 +0100 > From: Thomas Hoffmann > X-Mailer: Mozilla 4.61 [de] (OS/2; U) > X-Accept-Language: de > MIME-Version: 1.0 > To: os2-unix list > Subject: OS/2's GNUdiff and input from stdio > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > I tried to pipe the output of a program into OS/2's GNUdiff (it says it > would be v.2.7.1, it is the one from the archive from leo): > > cat bla1 | diff bla2 - > > and got the response > > diff.exe: -: Invalid seek > > So I tried to rebuild the diffutils from (configure.in-)scratch and got > a diff.exe > that can handle the above input (I used libcext, because this is the > "active" > library on my computer at the moment). > > Because I regard(ed) diff not only as stone old, but also as rock solid, > I am > a bit afraid to screw up something. Can anybody comment on my above > observation > and what should be done? > > Thomas. > > > --------------010002040507070405030203-- > > **= Email 3 ==========================** Date: Mon, 06 Jan 2003 08:05:31 -0500 From: Ted Sikora Subject: Re: header problems? No I had it. Stefan Neis wrote: > On Sat, 4 Jan 2003, Ted Sikora wrote: > > >>Tried building Zope with GCC 3.0.3 with the posix2 includes. Failed >>miserably on the first module with: >> >>error L2029 : unresolved external > > > Maybe you forgot to add -lcExt ? I had it. -- Ted Sikora tsikora at ntplx.net **= Email 4 ==========================** Date: Mon, 06 Jan 2003 08:05:31 -0500 From: Ted Sikora Subject: Re: header problems? No I had it. Stefan Neis wrote: > On Sat, 4 Jan 2003, Ted Sikora wrote: > > >>Tried building Zope with GCC 3.0.3 with the posix2 includes. Failed >>miserably on the first module with: >> >>error L2029 : unresolved external > > > Maybe you forgot to add -lcExt ? I had it. -- Ted Sikora tsikora at ntplx.net **= Email 5 ==========================** Date: Mon, 6 Jan 2003 08:17:07 +1100 (EST) From: Aelfred se leof Subject: Re: INETD & BOOTPD On Sun, 5 Jan 2003, John Poltorak wrote: > > Insert that at the top of main() in bootpd.c, > > Exactly whereabouts? > > I'm no expert with C and 'top' can mean different things... At the beginning, immediately after the variable declarations, should work. Nicholas S. **= Email 6 ==========================** Date: Mon, 6 Jan 2003 08:17:07 +1100 (EST) From: Aelfred se leof Subject: Re: INETD & BOOTPD On Sun, 5 Jan 2003, John Poltorak wrote: > > Insert that at the top of main() in bootpd.c, > > Exactly whereabouts? > > I'm no expert with C and 'top' can mean different things... At the beginning, immediately after the variable declarations, should work. Nicholas S. **= Email 7 ==========================** Date: Mon, 6 Jan 2003 11:10:33 +0000 From: John Poltorak Subject: Re: gcc and Mozilla On Sat, Jan 04, 2003 at 07:04:44PM -0600, Jeff Robinson wrote: > John Poltorak wrote: > > On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: > > > > > >>Basically everyone is trying to figure out why gcc builds fail on OS/2 > >>where they are common-place on other platforms. Which of course quickly > >>brings to mind the work this group is doing to not only standardise > >>tools, but to have the most up-to-date ones available (and working). > > > > > > Do have a list of the pre-requisite list of tools (including versions) > > required for building Mozilla? > > > > There is a list of required software at > http://www.mozilla.org/ports/os2/setup.html Why do you use BASH? I would suggest using the most recent version of PDKSH instead. Of course that would mean using date, expr, tee, test and uname from the GNU shell utils. Also Make 3.79.1 or maybe 3.80 in a short while... The versions of Perl and Autoconf are quite old, but it doesn't necessarily mean they don't work correctly. We need to know what the problems are rather than just changing things for the sake of it with the hope something fixes it. > This was originally setup for the VACPP build, I believe. From > experience I learned that thing were very dependent on the proper > version and archive of each tool, each seeming to have it's own special > foible. (Like one version of pwd return a path name including drive > letter, and another version only the path... obviously the latter isn't > that OS/2 workable). This had originally lead me to compile the > MozTools WarpIN archive just because it was so tedious to get everything > together in the first place. > > I'm willing to try and make a new "MozTools" archive out of the latest > UnixOS2 packages if our tools can do everything that the build-system > needs. Andreas Buening has made a great effort to get many of the base tools in line with the current GNU sources, and I would be tempted to use them but many are very new and will not have had much real world testing, so that could be slightly risky... > (Obviously folks that want the entire UnixOS2 environment > wouldn't need such a thing). Needless to say the build is non-trivial; > it takes about 4 hours on my 800Mhz Athlon with 512megs of RAM. > > > We've come a long way in the last year thanks to some excellent work by a > > number of people. We've also managed to pinpoint a number of commonly > > occuring problem areas, which I would suggest are generally due to the > > shell, Make or headers. > > > > I remember one of the earlier versions of gmake was also a problem for > Mozilla as it would run out of file handles. I believe Henry Sobotka > compiled a special vesion specifically to get around this problem. It would be better to use a generally available version. The number of different versions of Make for OS/2 is silly. There must be around ten to choose from - all with their individual traits and bugs. > >>Does anyone consider this a suitable "real-world" goal to help > >>prioritise what tools the UnixOS2 project works on next? > > > > > > I think 'prioritising' goals for a disparate group of OS/2 enthusiasts is > > like herding cats :-)... > > > > Point well taken! I just wanted to pretend to be a manager and say > prioritise, at the same time leveraging my paradigm. Now I feel all dirty. :-)... I think we all want everything to happen ASAP, but unfortunately is doesn't. Assembling an updated collection of basic tools has been my personal priority for a long time, but it isn't something I can do by myself, but I think we are getting close now. > I've dropped an e-mail message to Javier to see if he can supply us with > some more detailed information. I'll keep folks updated when I receive > a reply. Would it be useful having him on the list? > Jeff > > -- > ---------------- > Whatza JamochaMUD? > http://jamochamud.anecho.mb.ca > > Or other stuff: http://www.anecho.mb.ca/~jeffnik > ----------------------------------------------------------- > > -- John **= Email 8 ==========================** Date: Mon, 6 Jan 2003 11:10:33 +0000 From: John Poltorak Subject: Re: gcc and Mozilla On Sat, Jan 04, 2003 at 07:04:44PM -0600, Jeff Robinson wrote: > John Poltorak wrote: > > On Sat, Jan 04, 2003 at 03:01:12PM -0600, Jeff Robinson wrote: > > > > > >>Basically everyone is trying to figure out why gcc builds fail on OS/2 > >>where they are common-place on other platforms. Which of course quickly > >>brings to mind the work this group is doing to not only standardise > >>tools, but to have the most up-to-date ones available (and working). > > > > > > Do have a list of the pre-requisite list of tools (including versions) > > required for building Mozilla? > > > > There is a list of required software at > http://www.mozilla.org/ports/os2/setup.html Why do you use BASH? I would suggest using the most recent version of PDKSH instead. Of course that would mean using date, expr, tee, test and uname from the GNU shell utils. Also Make 3.79.1 or maybe 3.80 in a short while... The versions of Perl and Autoconf are quite old, but it doesn't necessarily mean they don't work correctly. We need to know what the problems are rather than just changing things for the sake of it with the hope something fixes it. > This was originally setup for the VACPP build, I believe. From > experience I learned that thing were very dependent on the proper > version and archive of each tool, each seeming to have it's own special > foible. (Like one version of pwd return a path name including drive > letter, and another version only the path... obviously the latter isn't > that OS/2 workable). This had originally lead me to compile the > MozTools WarpIN archive just because it was so tedious to get everything > together in the first place. > > I'm willing to try and make a new "MozTools" archive out of the latest > UnixOS2 packages if our tools can do everything that the build-system > needs. Andreas Buening has made a great effort to get many of the base tools in line with the current GNU sources, and I would be tempted to use them but many are very new and will not have had much real world testing, so that could be slightly risky... > (Obviously folks that want the entire UnixOS2 environment > wouldn't need such a thing). Needless to say the build is non-trivial; > it takes about 4 hours on my 800Mhz Athlon with 512megs of RAM. > > > We've come a long way in the last year thanks to some excellent work by a > > number of people. We've also managed to pinpoint a number of commonly > > occuring problem areas, which I would suggest are generally due to the > > shell, Make or headers. > > > > I remember one of the earlier versions of gmake was also a problem for > Mozilla as it would run out of file handles. I believe Henry Sobotka > compiled a special vesion specifically to get around this problem. It would be better to use a generally available version. The number of different versions of Make for OS/2 is silly. There must be around ten to choose from - all with their individual traits and bugs. > >>Does anyone consider this a suitable "real-world" goal to help > >>prioritise what tools the UnixOS2 project works on next? > > > > > > I think 'prioritising' goals for a disparate group of OS/2 enthusiasts is > > like herding cats :-)... > > > > Point well taken! I just wanted to pretend to be a manager and say > prioritise, at the same time leveraging my paradigm. Now I feel all dirty. :-)... I think we all want everything to happen ASAP, but unfortunately is doesn't. Assembling an updated collection of basic tools has been my personal priority for a long time, but it isn't something I can do by myself, but I think we are getting close now. > I've dropped an e-mail message to Javier to see if he can supply us with > some more detailed information. I'll keep folks updated when I receive > a reply. Would it be useful having him on the list? > Jeff > > -- > ---------------- > Whatza JamochaMUD? > http://jamochamud.anecho.mb.ca > > Or other stuff: http://www.anecho.mb.ca/~jeffnik > ----------------------------------------------------------- > > -- John **= Email 9 ==========================** Date: Mon, 6 Jan 2003 11:15:48 -0500 (EST) From: "Thomas E. Dickey" Subject: Re: 'add' program On Mon, 6 Jan 2003, John Poltorak wrote: > On Sun, Dec 29, 2002 at 06:38:44PM -0500, Thomas Dickey wrote: > > I updated the configure script (and since it was a while, did some todo's) > > for the 'add' program that you tried recently. It's still using the > > patched autoconf 2.13, but seems to find ncurses as expected. > > I just gave this a try and must be missing something... The patched autoconf 2.13 has two flavors - the one that works on Unix, and the additional patch which I added for OS/2. When I built ncurses recently on OS/2, I regenerated the configure script using that version of autoconf. The configure script you see is actually generated by autoconf 2.52 (plus patch). > > > Here is what I see in config.log:- > > configure:4095: checking if we have identified curses headers > configure:4115: gcc -c -Zmt -D__ST_MT_ERRNO__ conftest.c 1>&5 > In file included from c:\usr\include\curses.h:1, > from configure:4109: > c:\usr\include\ncurses/curses.h:58: ncurses_dll.h: No such file or directory > In file included from c:\usr\include\curses.h:1, > from configure:4109: > c:\usr\include\ncurses/curses.h:102: unctrl.h: No such file or directory > > > I can't fugure out why it has c:\usr\include here instead of c:/usr/include > as appears in my C_INCLUDE_PATH. > > > > > > > -- > > Thomas E. Dickey > > http://invisible-island.net > > ftp://invisible-island.net > > > -- T.E.Dickey http://invisible-island.net ftp://invisible-island.net **= Email 10 ==========================** Date: Mon, 6 Jan 2003 11:15:48 -0500 (EST) From: "Thomas E. Dickey" Subject: Re: 'add' program On Mon, 6 Jan 2003, John Poltorak wrote: > On Sun, Dec 29, 2002 at 06:38:44PM -0500, Thomas Dickey wrote: > > I updated the configure script (and since it was a while, did some todo's) > > for the 'add' program that you tried recently. It's still using the > > patched autoconf 2.13, but seems to find ncurses as expected. > > I just gave this a try and must be missing something... The patched autoconf 2.13 has two flavors - the one that works on Unix, and the additional patch which I added for OS/2. When I built ncurses recently on OS/2, I regenerated the configure script using that version of autoconf. The configure script you see is actually generated by autoconf 2.52 (plus patch). > > > Here is what I see in config.log:- > > configure:4095: checking if we have identified curses headers > configure:4115: gcc -c -Zmt -D__ST_MT_ERRNO__ conftest.c 1>&5 > In file included from c:\usr\include\curses.h:1, > from configure:4109: > c:\usr\include\ncurses/curses.h:58: ncurses_dll.h: No such file or directory > In file included from c:\usr\include\curses.h:1, > from configure:4109: > c:\usr\include\ncurses/curses.h:102: unctrl.h: No such file or directory > > > I can't fugure out why it has c:\usr\include here instead of c:/usr/include > as appears in my C_INCLUDE_PATH. > > > > > > > -- > > Thomas E. Dickey > > http://invisible-island.net > > ftp://invisible-island.net > > > -- T.E.Dickey http://invisible-island.net ftp://invisible-island.net **= Email 11 ==========================** Date: Mon, 6 Jan 2003 13:51:32 +0000 From: John Poltorak Subject: Elapsed time Is there a Unix utility which will show the elapsed time between to instances? I want to know the duration between two events in a shell script. -- John **= Email 12 ==========================** Date: Mon, 6 Jan 2003 13:51:32 +0000 From: John Poltorak Subject: Elapsed time Is there a Unix utility which will show the elapsed time between to instances? I want to know the duration between two events in a shell script. -- John **= Email 13 ==========================** Date: Mon, 6 Jan 2003 14:13:58 -0800 (PST) From: Steve Wendt Subject: Re: Elapsed time On Mon, 6 Jan 2003, John Poltorak wrote: > Is there a Unix utility which will show the elapsed time between to > instances? > > I want to know the duration between two events in a shell script. time (the date utility is used to SET the time, believe it or not). **= Email 14 ==========================** Date: Mon, 6 Jan 2003 14:13:58 -0800 (PST) From: Steve Wendt Subject: Re: Elapsed time On Mon, 6 Jan 2003, John Poltorak wrote: > Is there a Unix utility which will show the elapsed time between to > instances? > > I want to know the duration between two events in a shell script. time (the date utility is used to SET the time, believe it or not). **= Email 15 ==========================** Date: Mon, 6 Jan 2003 15:34:23 +0000 From: John Poltorak Subject: Re: 'add' program On Sun, Dec 29, 2002 at 06:38:44PM -0500, Thomas Dickey wrote: > I updated the configure script (and since it was a while, did some todo's) > for the 'add' program that you tried recently. It's still using the > patched autoconf 2.13, but seems to find ncurses as expected. I just gave this a try and must be missing something... Here is what I see in config.log:- configure:4095: checking if we have identified curses headers configure:4115: gcc -c -Zmt -D__ST_MT_ERRNO__ conftest.c 1>&5 In file included from c:\usr\include\curses.h:1, from configure:4109: c:\usr\include\ncurses/curses.h:58: ncurses_dll.h: No such file or directory In file included from c:\usr\include\curses.h:1, from configure:4109: c:\usr\include\ncurses/curses.h:102: unctrl.h: No such file or directory I can't fugure out why it has c:\usr\include here instead of c:/usr/include as appears in my C_INCLUDE_PATH. > -- > Thomas E. Dickey > http://invisible-island.net > ftp://invisible-island.net -- John **= Email 16 ==========================** Date: Mon, 6 Jan 2003 15:34:23 +0000 From: John Poltorak Subject: Re: 'add' program On Sun, Dec 29, 2002 at 06:38:44PM -0500, Thomas Dickey wrote: > I updated the configure script (and since it was a while, did some todo's) > for the 'add' program that you tried recently. It's still using the > patched autoconf 2.13, but seems to find ncurses as expected. I just gave this a try and must be missing something... Here is what I see in config.log:- configure:4095: checking if we have identified curses headers configure:4115: gcc -c -Zmt -D__ST_MT_ERRNO__ conftest.c 1>&5 In file included from c:\usr\include\curses.h:1, from configure:4109: c:\usr\include\ncurses/curses.h:58: ncurses_dll.h: No such file or directory In file included from c:\usr\include\curses.h:1, from configure:4109: c:\usr\include\ncurses/curses.h:102: unctrl.h: No such file or directory I can't fugure out why it has c:\usr\include here instead of c:/usr/include as appears in my C_INCLUDE_PATH. > -- > Thomas E. Dickey > http://invisible-island.net > ftp://invisible-island.net -- John **= Email 17 ==========================** Date: Mon, 6 Jan 2003 16:09:36 +0000 From: John Poltorak Subject: Re: Elapsed time On Mon, Jan 06, 2003 at 01:51:32PM +0000, John Poltorak wrote: > Is there a Unix utility which will show the elapsed time between to > instances? > > I want to know the duration between two events in a shell script. In case anyone is interested, here's one solution:- start_time=`date +"%s"` **= Email 18 ==========================** Date: Mon, 6 Jan 2003 16:09:36 +0000 From: John Poltorak Subject: Re: Elapsed time On Mon, Jan 06, 2003 at 01:51:32PM +0000, John Poltorak wrote: > Is there a Unix utility which will show the elapsed time between to > instances? > > I want to know the duration between two events in a shell script. In case anyone is interested, here's one solution:- start_time=`date +"%s"` **= Email 19 ==========================** Date: Mon, 6 Jan 2003 16:33:00 +0000 From: John Poltorak Subject: Re: PASSWD handling On Mon, Jan 06, 2003 at 05:14:31PM +0100, Andreas Buening wrote: > I still haven't understood the PASSWD problem completely. The major problem is that there are two different solutions to handling embedded drive letters in the home directory or shell fields. Different apps use one or other of these two formats which can lead to errors retreiving data from the passwd file. We need to standardise on a single access method. > 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 20 ==========================** Date: Mon, 6 Jan 2003 16:33:00 +0000 From: John Poltorak Subject: Re: PASSWD handling On Mon, Jan 06, 2003 at 05:14:31PM +0100, Andreas Buening wrote: > I still haven't understood the PASSWD problem completely. The major problem is that there are two different solutions to handling embedded drive letters in the home directory or shell fields. Different apps use one or other of these two formats which can lead to errors retreiving data from the passwd file. We need to standardise on a single access method. > 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 21 ==========================** Date: Mon, 6 Jan 2003 16:48:52 +0000 From: John Poltorak Subject: Re: 'add' program On Mon, Jan 06, 2003 at 11:15:48AM -0500, Thomas E. Dickey wrote: > On Mon, 6 Jan 2003, John Poltorak wrote: > > > On Sun, Dec 29, 2002 at 06:38:44PM -0500, Thomas Dickey wrote: > > > I updated the configure script (and since it was a while, did some todo's) > > > for the 'add' program that you tried recently. It's still using the > > > patched autoconf 2.13, but seems to find ncurses as expected. > > > > I just gave this a try and must be missing something... > > The patched autoconf 2.13 has two flavors - the one that works on Unix, > and the additional patch which I added for OS/2. When I built ncurses > recently on OS/2, I regenerated the configure script using that version > of autoconf. The configure script you see is actually generated by > autoconf 2.52 (plus patch). I'm actually rebuilding configure using autoconf v2.13 plus your two patches:- autoconf-2.13-20020210.patch.gz autoconf-2.13-20020210-emx.patch.gz so I would have expected configure to work OK. Where abouts within configure does it generate the lines:- ? configure:4115: gcc -c -Zmt -D__ST_MT_ERRNO__ conftest.c 1>&5 In file included from c:\usr\include\curses.h:1, from configure:4109: c:\usr\include\ncurses/curses.h:58: ncurses_dll.h: No such file or directory This is the relevant part of configure, but I can't figure out where c:\usr\include comes from. cf_cv_ncurses_header=none for cf_header in \ curses.h \ ncurses.h \ ncurses/curses.h \ ncurses/ncurses.h do cat > conftest.$ac_ext < <============== 4109 int main() { initscr(); tgoto("?", 0,0) ; return 0; } EOF if { (eval echo configure:4115: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; rm -rf conftest* cf_cv_ncurses_header=$cf_header; break else echo "configure: failed program was:" >&5 cat conftest.$ac_ext >&5 fi rm -f conftest* done fi > -- > T.E.Dickey > http://invisible-island.net > ftp://invisible-island.net **= Email 22 ==========================** Date: Mon, 6 Jan 2003 16:48:52 +0000 From: John Poltorak Subject: Re: 'add' program On Mon, Jan 06, 2003 at 11:15:48AM -0500, Thomas E. Dickey wrote: > On Mon, 6 Jan 2003, John Poltorak wrote: > > > On Sun, Dec 29, 2002 at 06:38:44PM -0500, Thomas Dickey wrote: > > > I updated the configure script (and since it was a while, did some todo's) > > > for the 'add' program that you tried recently. It's still using the > > > patched autoconf 2.13, but seems to find ncurses as expected. > > > > I just gave this a try and must be missing something... > > The patched autoconf 2.13 has two flavors - the one that works on Unix, > and the additional patch which I added for OS/2. When I built ncurses > recently on OS/2, I regenerated the configure script using that version > of autoconf. The configure script you see is actually generated by > autoconf 2.52 (plus patch). I'm actually rebuilding configure using autoconf v2.13 plus your two patches:- autoconf-2.13-20020210.patch.gz autoconf-2.13-20020210-emx.patch.gz so I would have expected configure to work OK. Where abouts within configure does it generate the lines:- ? configure:4115: gcc -c -Zmt -D__ST_MT_ERRNO__ conftest.c 1>&5 In file included from c:\usr\include\curses.h:1, from configure:4109: c:\usr\include\ncurses/curses.h:58: ncurses_dll.h: No such file or directory This is the relevant part of configure, but I can't figure out where c:\usr\include comes from. cf_cv_ncurses_header=none for cf_header in \ curses.h \ ncurses.h \ ncurses/curses.h \ ncurses/ncurses.h do cat > conftest.$ac_ext < <============== 4109 int main() { initscr(); tgoto("?", 0,0) ; return 0; } EOF if { (eval echo configure:4115: \"$ac_compile\") 1>&5; (eval $ac_compile) 2>&5; rm -rf conftest* cf_cv_ncurses_header=$cf_header; break else echo "configure: failed program was:" >&5 cat conftest.$ac_ext >&5 fi rm -f conftest* done fi > -- > T.E.Dickey > http://invisible-island.net > ftp://invisible-island.net **= Email 23 ==========================** Date: Mon, 06 Jan 2003 17:14:31 +0100 From: Andreas Buening Subject: Re: PASSWD handling Nicholas Sheppard wrote: > > On Thu, 2 Jan 2003, John Poltorak wrote: [drive letters] > At least some Cygwin applications don't understand Windows-style paths, > which makes them virtually unusable in a normal Windows environment. I > don't want my OS/2 applications to go down the same path. ACK. > > But we also need a 'quick and > > dirty' solution which can be put together in maybe a week or so which can > > serve as a standard for all current apps which require passwd access. > > 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? > The file format will be the same as the current one, except that drive > letters will be represented by /dev/c, /dev/d, etc. instead of the > current $ solution. It would be simple to make the reading routines able > to parse the old $ and ; conventions and convert them, but new entries > will be written in the new format. 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? In this case the passwd file format wouldn't matter. We could implement filenames with drive letters or $ signs or even in ROT13 encoding. As long as all applications access those entries only by the API function this doesn't matter. Is there really a not negligible set of applications that "must" read the passwd file by hand? [snip] 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 24 ==========================** Date: Mon, 06 Jan 2003 17:14:31 +0100 From: Andreas Buening Subject: Re: PASSWD handling Nicholas Sheppard wrote: > > On Thu, 2 Jan 2003, John Poltorak wrote: [drive letters] > At least some Cygwin applications don't understand Windows-style paths, > which makes them virtually unusable in a normal Windows environment. I > don't want my OS/2 applications to go down the same path. ACK. > > But we also need a 'quick and > > dirty' solution which can be put together in maybe a week or so which can > > serve as a standard for all current apps which require passwd access. > > 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? > The file format will be the same as the current one, except that drive > letters will be represented by /dev/c, /dev/d, etc. instead of the > current $ solution. It would be simple to make the reading routines able > to parse the old $ and ; conventions and convert them, but new entries > will be written in the new format. 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? In this case the passwd file format wouldn't matter. We could implement filenames with drive letters or $ signs or even in ROT13 encoding. As long as all applications access those entries only by the API function this doesn't matter. Is there really a not negligible set of applications that "must" read the passwd file by hand? [snip] 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 25 ==========================** Date: Mon, 6 Jan 2003 19:37:51 +0000 From: John Poltorak Subject: Re: INETD & BOOTPD On Mon, Jan 06, 2003 at 08:17:07AM +1100, Aelfred se leof wrote: > On Sun, 5 Jan 2003, John Poltorak wrote: > > > > Insert that at the top of main() in bootpd.c, > > > > Exactly whereabouts? > > > > I'm no expert with C and 'top' can mean different things... > > At the beginning, immediately after the variable declarations, should > work. Does this look right:- ? /* * Initialization such as command-line processing is done and then the * main server loop is started. */ void main(argc, argv) int argc; char **argv; { struct timeval *timeout; struct bootp *bp; struct servent *servp; struct hostent *hep; char *stmp; char *skt; int n, ba_len, ra_len; int nfound, readfds; int standalone; int ibmso,emxso; #ifdef SA_NOCLDSTOP /* Have POSIX sigaction(2). */ struct sigaction sa; #endif #ifdef __EMX__ static char bootptab_file[256]; char *etc = getenv("ETC"); if (etc != NULL) { strcpy(bootptab_file, etc); strcat(bootptab_file, "\\bootptab"); bootptab = bootptab_file; } if ((skt = getenv ("INETDSOCKETHANDLE")) && (ibmso = atoi (s))) { /* connect inetd's socket to stdin and stdout */ if ((emxso = _impsockhandle (ibmso,0)) >= 0) { dup2 (emxso,0); dup2 (emxso,1); close (emxso); } } #endif I had to change char *s to char *skt since s was defined elsewhere. I also commented this out to make it compile:- #else /* SETSID */ // if (setsid() < 0) // perror("setsid"); #endif /* SETSID */ Unfortunately when I run it, it crashes:- Process terminated with SIGSEGV > Nicholas S. -- John **= Email 26 ==========================** Date: Mon, 6 Jan 2003 19:37:51 +0000 From: John Poltorak Subject: Re: INETD & BOOTPD On Mon, Jan 06, 2003 at 08:17:07AM +1100, Aelfred se leof wrote: > On Sun, 5 Jan 2003, John Poltorak wrote: > > > > Insert that at the top of main() in bootpd.c, > > > > Exactly whereabouts? > > > > I'm no expert with C and 'top' can mean different things... > > At the beginning, immediately after the variable declarations, should > work. Does this look right:- ? /* * Initialization such as command-line processing is done and then the * main server loop is started. */ void main(argc, argv) int argc; char **argv; { struct timeval *timeout; struct bootp *bp; struct servent *servp; struct hostent *hep; char *stmp; char *skt; int n, ba_len, ra_len; int nfound, readfds; int standalone; int ibmso,emxso; #ifdef SA_NOCLDSTOP /* Have POSIX sigaction(2). */ struct sigaction sa; #endif #ifdef __EMX__ static char bootptab_file[256]; char *etc = getenv("ETC"); if (etc != NULL) { strcpy(bootptab_file, etc); strcat(bootptab_file, "\\bootptab"); bootptab = bootptab_file; } if ((skt = getenv ("INETDSOCKETHANDLE")) && (ibmso = atoi (s))) { /* connect inetd's socket to stdin and stdout */ if ((emxso = _impsockhandle (ibmso,0)) >= 0) { dup2 (emxso,0); dup2 (emxso,1); close (emxso); } } #endif I had to change char *s to char *skt since s was defined elsewhere. I also commented this out to make it compile:- #else /* SETSID */ // if (setsid() < 0) // perror("setsid"); #endif /* SETSID */ Unfortunately when I run it, it crashes:- Process terminated with SIGSEGV > Nicholas S. -- John **= Email 27 ==========================** Date: Mon, 6 Jan 2003 19:58:19 +0000 From: John Poltorak Subject: Re: diff ... On Mon, Jan 06, 2003 at 12:18:18AM +0100, Thomas Hoffmann wrote: > > I tried to pipe the output of a program into OS/2's GNUdiff (it says it > > would be v.2.7.1, it is the one from the archive from leo): > > > > cat bla1 | diff bla2 - > > > > and got the response > > > > diff.exe: -: Invalid seek > > I get this. > > So I tried to rebuild the diffutils from (configure.in-)scratch and got > > a diff.exe > > that can handle the above input (I used libcext, because this is the > > "active" > > library on my computer at the moment). > > > > Because I regard(ed) diff not only as stone old, but also as rock solid, > > I am > > a bit afraid to screw up something. Can anybody comment on my above > > observation > > and what should be done? Do you expect different output? When uou built it, did you need to apply any patches or did it just compile straight out of the box? > > > > Thomas. -- John **= Email 28 ==========================** Date: Mon, 6 Jan 2003 19:58:19 +0000 From: John Poltorak Subject: Re: diff ... On Mon, Jan 06, 2003 at 12:18:18AM +0100, Thomas Hoffmann wrote: > > I tried to pipe the output of a program into OS/2's GNUdiff (it says it > > would be v.2.7.1, it is the one from the archive from leo): > > > > cat bla1 | diff bla2 - > > > > and got the response > > > > diff.exe: -: Invalid seek > > I get this. > > So I tried to rebuild the diffutils from (configure.in-)scratch and got > > a diff.exe > > that can handle the above input (I used libcext, because this is the > > "active" > > library on my computer at the moment). > > > > Because I regard(ed) diff not only as stone old, but also as rock solid, > > I am > > a bit afraid to screw up something. Can anybody comment on my above > > observation > > and what should be done? Do you expect different output? When uou built it, did you need to apply any patches or did it just compile straight out of the box? > > > > Thomas. -- John **= Email 29 ==========================** Date: Mon, 6 Jan 2003 21:17:20 +0000 From: John Poltorak Subject: Re: INETD & BOOTPD On Tue, Jan 07, 2003 at 07:44:41AM +1100, Nicholas Sheppard wrote: > 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. Thanks for pointing that out. It seems to work now. > Nicholas S. -- John **= Email 30 ==========================** Date: Mon, 6 Jan 2003 21:17:20 +0000 From: John Poltorak Subject: Re: INETD & BOOTPD On Tue, Jan 07, 2003 at 07:44:41AM +1100, Nicholas Sheppard wrote: > 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. Thanks for pointing that out. It seems to work now. > Nicholas S. -- John **= Email 31 ==========================** Date: Mon, 6 Jan 2003 21:28:43 +0100 From: Holger Veit Subject: Re: Drive letters On Sun, Jan 05, 2003 at 10:26:58PM +1100, Nicholas Sheppard wrote: > On Sun, 5 Jan 2003, John Poltorak wrote: > > > In general, I don't see drive letters to be a major hurdle, apart from > > their use within PASSWD where the ':' delimiter has two meanings, so an > > alternative has to be chosen. That in itself is not so much of a problem, > > because we have a means of handling it. Unfortunately we have conflicting > > solutions both of which have become fairly entrenched because they have > > been around for such a long time, and we really need to come up with a > > single standard. It would be nice to be able to use something now without > > being dependent on some magic in the future, although being able to > > incorporate future developments would be good. > > I'm re-writing the passwd code for the next release of ipop3d so that it > will be able to read both the $c and c; formats. If there are any others I > can add them, too. I would like to move to the /dev/* format for writing > new entries, however, for the reasons given by various people on this > list. Ahem, the only code to deal with passwd and group files should be the POSIX {get|set}{pw,gr}ent routines and friends. Unfortunately, in EMX these are NO-OPs or non-working dummies. The real fix should not be to modify programs like ipop3d to process $c and c; anachronisms, but rather library routines that understand the various formats and implicitly convert the different conventions to OS/2 path names where needed (implement a __getpwent() or __getpwuid() that returns drive paths, and the standard getpwent/getpwuid which return Unix names. Rather than feed the $c or c; junk in /etc/passwd further (you will never ever get rid of it if you still support it for writing!) enforce the Unix name convention in /etc/passwd - there are numerous shell and perl scripts (even if per uses the getpw*() routines if they are available - in OS/2-EMX they are unusuable, therefore perl circumvents them) which will get confused with either c; or c$ or other nonsense inventions. Fix the right place once, not myriads of places whenever wind changes. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 32 ==========================** Date: Mon, 6 Jan 2003 21:28:43 +0100 From: Holger Veit Subject: Re: Drive letters On Sun, Jan 05, 2003 at 10:26:58PM +1100, Nicholas Sheppard wrote: > On Sun, 5 Jan 2003, John Poltorak wrote: > > > In general, I don't see drive letters to be a major hurdle, apart from > > their use within PASSWD where the ':' delimiter has two meanings, so an > > alternative has to be chosen. That in itself is not so much of a problem, > > because we have a means of handling it. Unfortunately we have conflicting > > solutions both of which have become fairly entrenched because they have > > been around for such a long time, and we really need to come up with a > > single standard. It would be nice to be able to use something now without > > being dependent on some magic in the future, although being able to > > incorporate future developments would be good. > > I'm re-writing the passwd code for the next release of ipop3d so that it > will be able to read both the $c and c; formats. If there are any others I > can add them, too. I would like to move to the /dev/* format for writing > new entries, however, for the reasons given by various people on this > list. Ahem, the only code to deal with passwd and group files should be the POSIX {get|set}{pw,gr}ent routines and friends. Unfortunately, in EMX these are NO-OPs or non-working dummies. The real fix should not be to modify programs like ipop3d to process $c and c; anachronisms, but rather library routines that understand the various formats and implicitly convert the different conventions to OS/2 path names where needed (implement a __getpwent() or __getpwuid() that returns drive paths, and the standard getpwent/getpwuid which return Unix names. Rather than feed the $c or c; junk in /etc/passwd further (you will never ever get rid of it if you still support it for writing!) enforce the Unix name convention in /etc/passwd - there are numerous shell and perl scripts (even if per uses the getpw*() routines if they are available - in OS/2-EMX they are unusuable, therefore perl circumvents them) which will get confused with either c; or c$ or other nonsense inventions. Fix the right place once, not myriads of places whenever wind changes. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 33 ==========================** Date: Mon, 06 Jan 2003 23:49:52 +0100 From: Thomas Hoffmann Subject: Re: diff ... John Poltorak wrote: > > When uou built it, did you need to apply any patches or did it just > compile straight out of the box? As I wrote: I built it from configure.in using a "Posix/2ized" environment (linking with -lcExt). No patches or stuff ... **= Email 34 ==========================** Date: Mon, 06 Jan 2003 23:49:52 +0100 From: Thomas Hoffmann Subject: Re: diff ... John Poltorak wrote: > > When uou built it, did you need to apply any patches or did it just > compile straight out of the box? As I wrote: I built it from configure.in using a "Posix/2ized" environment (linking with -lcExt). No patches or stuff ...