From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Sat, 16 Feb 2002 04:15:29 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 137 ************************************************** Friday 15 February 2002 Number 137 ************************************************** Subjects for today 1 curses.h : John Poltorak 2 Re: IFS=\t ? : Andreas Buening 3 Re: Checking for BSD compatible install... : Andreas Buening 4 Re: Building libregex from BSD libc : Andreas Buening 5 Re: IFS=\t ? : John Poltorak 6 Re: Checking for BSD compatible install... : John Poltorak 7 Re: Building libregex from BSD libc : John Poltorak 8 Re: Problem with READ function : Charles R. Hunter" 9 Re: BISON v1.33 : Thomas Dickey 10 Re: BYACC - official home : Thomas Dickey 11 Problem with READ function : John Poltorak 12 Re: Building libregex from BSD libc : Holger Veit 13 Re: BISON v1.33 : Thomas Dickey 14 BZIP2 v1.0.2 : John Poltorak 15 Re: Building libregex from BSD libc : Stefan Neis 16 Re: Problem with READ function : Charles R. Hunter" 17 Re: Building libregex from BSD libc : John Poltorak 18 Re: BZIP2 v1.0.2 : Steve Wendt" 19 GZIP v1.3.2 : John Poltorak 20 BISON v1.33 : John Poltorak 21 BYACC - official home : John Poltorak 22 Re: BISON v1.33 : John Poltorak 23 Re: BZIP2 v1.0.2 : John Poltorak 24 Re: Building libregex from BSD libc : Stefan Neis 25 Re: BISON v1.33 : John Poltorak 26 Re: BZIP2 v1.0.2 : Kris Steenhaut 27 Re: Problem with READ function : John Poltorak 28 Re: Building libregex from BSD libc : Henry Sobotka 29 Re: Building libregex from BSD libc : Andreas Buening 30 Re: Building libregex from BSD libc : Andreas Buening 31 make 3.79.1 : Andreas Buening 32 Re: make 3.79.1 : John Poltorak 33 Re: make 3.79.1 : Andreas Buening 34 Re: Building libregex from BSD libc : Stefan Neis **= Email 1 ==========================** Date: Sat, 16 Feb 2002 00:04:01 +0000 From: John Poltorak Subject: curses.h I would like to replace curses.h in EMX with the one from NCURSES for UnixOS/2. Is this a silly idea? What are the consequences of making such a change? -- John **= Email 2 ==========================** Date: Sat, 16 Feb 2002 01:17:28 +0100 From: Andreas Buening Subject: Re: IFS=\t ? John Poltorak wrote: > > I came across a neat routine for parsing a line of text yesterday, > something which I'd been struggling to do with AWK. Here it is:- > > grep ^KEY FILENAME | while read p1 p2 p3 ; do echo $p3 $p2 $p1 ; done > > Unfortunately the default delimiter is " " and I want to use TAB. I think > I can do this by setting the envvar IFS, which sounds simple enough, but I > haven't got it working. Can someone give me an exammple? IFS=' ' (a real tab!) should work. For newlines: IFS=' ' 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 Redmond where the Shadows lie. **= Email 3 ==========================** Date: Sat, 16 Feb 2002 01:17:44 +0100 From: Andreas Buening Subject: Re: Checking for BSD compatible install... John Poltorak wrote: > > Sometimes when configure is running:- > > checking for a BSD compatible install... > > it finds ./install.sh -c and sometimes it finds c:/usr/bin/install.exe -c. > > Can someone provide a standalone test for this? I can't figure out why I > get differring results. If configure isn't able to find executables ./install.sh is used for install. That's all. 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 Redmond where the Shadows lie. **= Email 4 ==========================** Date: Sat, 16 Feb 2002 01:18:27 +0100 From: Andreas Buening Subject: Re: Building libregex from BSD libc John Poltorak wrote: > > I've seen some code for building libregex and managed to compile a > REGEX.DLL which is one of the standard DLLs in the OS2LIBS package of > UnixOS/2. Unfortuantely this is derived from GLIBC and it appears that we > don't want to go down that road, so I'd like to be able to build the same > thing using BSD libc, but have no idea how. I guess I can use something > from Posix/2 but I don't know my way round that package, so I'd be very > grateful if someone could supply a Makefile which does the BSD equivalent > of:- [snip] Why? What's wrong with GNU regex? I don't know whether GNU and BSD regex are compatible but if we want to use mostly the GNU tools (grep, make, whatever) we should also have GNU regex because a lot of those programs need it. Either we have a standalone dll or dozens of programs will link GNU regex statically. By the way, the same consideration also applies to GNU versus BSD gettext and most likely also to other libraries. I prefer GNU tools because - they often have some nice non standard extensions - they are already in use for OS/2 - their sources already contain some non Unix support - there are a lot more people that have already dealt with the GNU than the BSD flavor 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 Redmond where the Shadows lie. **= Email 5 ==========================** Date: Sat, 16 Feb 2002 09:35:09 +0000 From: John Poltorak Subject: Re: IFS=\t ? On Sat, Feb 16, 2002 at 01:17:28AM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > I came across a neat routine for parsing a line of text yesterday, > > something which I'd been struggling to do with AWK. Here it is:- > > > > grep ^KEY FILENAME | while read p1 p2 p3 ; do echo $p3 $p2 $p1 ; done > > > > Unfortunately the default delimiter is " " and I want to use TAB. I think > > I can do this by setting the envvar IFS, which sounds simple enough, but I > > haven't got it working. Can someone give me an exammple? > > IFS=' ' > (a real tab!) should work. Thanks! I never thought of using a real tab. For newlines: > IFS=' > ' > > 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 Redmond where the Shadows lie. -- John **= Email 6 ==========================** Date: Sat, 16 Feb 2002 09:40:37 +0000 From: John Poltorak Subject: Re: Checking for BSD compatible install... On Sat, Feb 16, 2002 at 01:17:44AM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > Sometimes when configure is running:- > > > > checking for a BSD compatible install... > > > > it finds ./install.sh -c and sometimes it finds c:/usr/bin/install.exe -c. > > > > Can someone provide a standalone test for this? I can't figure out why I > > get differring results. > > If configure isn't able to find executables ./install.sh is > used for install. That's all. What I don't understand is why it doesn't find install.exe every time... I'm using the same script which creates the same environment and the same version of autoconf to create the configure script. > 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 Redmond where the Shadows lie. -- John **= Email 7 ==========================** Date: Sat, 16 Feb 2002 10:05:19 +0000 From: John Poltorak Subject: Re: Building libregex from BSD libc On Sat, Feb 16, 2002 at 01:18:27AM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > I've seen some code for building libregex and managed to compile a > > REGEX.DLL which is one of the standard DLLs in the OS2LIBS package of > > UnixOS/2. Unfortuantely this is derived from GLIBC and it appears that we > > don't want to go down that road, so I'd like to be able to build the same > > thing using BSD libc, but have no idea how. I guess I can use something > > from Posix/2 but I don't know my way round that package, so I'd be very > > grateful if someone could supply a Makefile which does the BSD equivalent > > of:- > > [snip] > > Why? What's wrong with GNU regex? I don't know whether GNU and > BSD regex are compatible but if we want to use mostly the GNU > tools (grep, make, whatever) we should also have GNU regex > because a lot of those programs need it. Either we have a standalone > dll or dozens of programs will link GNU regex statically. REGEX is built using files from GLIBC. It is supposed to be a POSIX library so I was surprised that I couldn't find the same files under BSD libc. What I was looking for was adding some headers and libraries to a LIBEMX package, but that would mean adding elements from GLIBC whereas it has been suggested we don't go down that route since LIBEMU will incorporate BSD libc. I, too, would prefer to retain REGEX.DLL and thought it should be possible to create a functionally equivalent library using BSD code as it claimed to be POSIX compliant. > By the way, the same consideration also applies to GNU > versus BSD gettext and most likely also to other libraries. That is something we need to consider too. > I prefer GNU tools because I don't think there is any question about replacing GNU utils, I believe they are even standard on FreeBSD. It's basically a problem about the inclusion of GLIBC in UnixOS/2. > 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 Redmond where the Shadows lie. -- John **= Email 8 ==========================** Date: Sat, 16 Feb 2002 10:44:38 -0500 From: "Charles R. Hunter" Subject: Re: Problem with READ function On Sat, Feb 16, 2002 at 11:06:44AM +0000, John Poltorak (jp at eyup.org) wrote: > > > Can anyone explain what is wrong with this shell script which uses the > READ function? :- > Well you can't exactly do what you're wanting to do with that syntax. I think what you want to do is more akin to: for x in `grep ^KEY index` do for y in $x do echo -n $y; done done but even that is not right, since depending on your shell version your first line might get auto-split into elements even though you are really wanting the entire line as one element the first time round The reason your read statemtent isn't holding its values is because of the way bourne shell ( or any sh ) works. You have in implicit subshell being launched in the read because it is at the end of the pipe. This sort of thing is poorly suited for bourne shell. In fact, nearly everything is poorly suited for bourne shell :) Yes, other shells have arrays and functions and you could use them... I'd stay away though. Bourne shell is the defacto standard shell for doing *shell* programming in, but now days, if you want to get any serious work done, one should use perl. Hope this helps. Charles > > > #! sh > # > KEY=fruit > grep ^$KEY index | while read A B C D ; do echo $A $B $C $D ; done > > echo $A $B $C $D > > echo end > > > > using this INDEX > > > >cat index > fruit apple banana cherry > vegetable asparagus broccoli cabbage > > > I don't see why the second ECHO produces no output. Why have the variables > lost their values? > > -- > John > -- Charles R. Hunter Director, Physics Computer Network Purdue University crh at physics.purdue.edu **= Email 9 ==========================** Date: Sat, 16 Feb 2002 10:46:08 -0500 From: Thomas Dickey Subject: Re: BISON v1.33 On Sat, Feb 16, 2002 at 03:22:15PM +0000, John Poltorak wrote: > GNU Bison v1.33 has been released recently. It's available here:- > > ftp://ftp.gnu.org/pub/gnu/bison/bison-1.33.tar.gz > > Let's see if it builds... It requires Autoconf v2.52g which is a beta, so > I'm a bit scepticle about my chances. and in turn autoconf 2.52g relies upon an unreleased version of automake, right? -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 10 ==========================** Date: Sat, 16 Feb 2002 10:48:14 -0500 From: Thomas Dickey Subject: Re: BYACC - official home On Sat, Feb 16, 2002 at 03:33:18PM +0000, John Poltorak wrote: > > > There was some discussion a while ago about the most recent version of > BYACC and it appeared that it had been hijacked by the Linux crowd... not exactly. There are packages, but they don't add anything of substance. > Is there an 'official' maintainer of BYACC? If so where would he keep it? I don't think so. If it were hard to compile, I'd have a package for it, since as a matter of practice I prefer byacc to bison. (I've seen a few packages which rely on bison, but imho, they should be deleted). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 11 ==========================** Date: Sat, 16 Feb 2002 11:06:44 +0000 From: John Poltorak Subject: Problem with READ function Can anyone explain what is wrong with this shell script which uses the READ function? :- #! sh # KEY=fruit grep ^$KEY index | while read A B C D ; do echo $A $B $C $D ; done echo $A $B $C $D echo end using this INDEX >cat index fruit apple banana cherry vegetable asparagus broccoli cabbage I don't see why the second ECHO produces no output. Why have the variables lost their values? -- John **= Email 12 ==========================** Date: Sat, 16 Feb 2002 11:29:25 +0100 From: Holger Veit Subject: Re: Building libregex from BSD libc On Sat, Feb 16, 2002 at 01:18:27AM +0100, Andreas Buening wrote: > [snip] > > Why? What's wrong with GNU regex? I don't know whether GNU and > BSD regex are compatible but if we want to use mostly the GNU > tools (grep, make, whatever) we should also have GNU regex No. GNu tools are usually constructed to build on multiple Unix and non-Unix platforms and will (thanks to autoconf and friends) take whatever they find as functions on that platform. There may or may not be a GLIBC (likely not) or REGEX.DLL available. > because a lot of those programs need it. Either we have a standalone > dll or dozens of programs will link GNU regex statically. No. The regex functionality can be built into the libc shared library on some systems. We have here under OS/2 the situation of a REGEX and GETTEXT and INTL DLL because EMX didn't provide a "correct" implementation right from the beginning. > By the way, the same consideration also applies to GNU > versus BSD gettext and most likely also to other libraries. > I prefer GNU tools because > - they often have some nice non standard extensions > - they are already in use for OS/2 > - their sources already contain some non Unix support > - there are a lot more people that have already dealt with the > GNU than the BSD flavor > > > 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 Redmond where the Shadows lie. -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 13 ==========================** Date: Sat, 16 Feb 2002 11:30:17 -0500 From: Thomas Dickey Subject: Re: BISON v1.33 On Sat, Feb 16, 2002 at 03:51:56PM +0000, John Poltorak wrote: > On Sat, Feb 16, 2002 at 10:46:08AM -0500, Thomas Dickey wrote: > > On Sat, Feb 16, 2002 at 03:22:15PM +0000, John Poltorak wrote: > > > GNU Bison v1.33 has been released recently. It's available here:- > > > > > > ftp://ftp.gnu.org/pub/gnu/bison/bison-1.33.tar.gz > > > > > > Let's see if it builds... It requires Autoconf v2.52g which is a beta, so > > > I'm a bit scepticle about my chances. > > > > and in turn autoconf 2.52g relies upon an unreleased version of automake, right? > > How do I tell? I grep through the source, looking for automake (but also there are references to 1.5, 1.5b, etc). I noted this last week (for 2.52h) but my report was disregarded because "users" are not expected to make corrections to the code and therefore won't have to worry about dependencies. > I only know about the autoconf requirement from configure.in which has:- > > AC_PREREQ(2.52g) > > It really does seem a bit absurd that a release version of a program > depends on beta versions of tools. ( 2.52g is supposed to be a beta ;-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 14 ==========================** Date: Sat, 16 Feb 2002 11:46:41 +0000 From: John Poltorak Subject: BZIP2 v1.0.2 A new release of BZIP2 (v1.0.2) slipped out last month, see:- http://sources.redhat.com/bzip2/index.html#bzip2-latest Has anyone tried building this on OS/2? ISTR there were several different ports of previous versions. It would be nice to get any OS/2 specific changes incoporated into the original so that it would build out of the box. -- John **= Email 15 ==========================** Date: Sat, 16 Feb 2002 12:53:57 +0100 (CET) From: Stefan Neis Subject: Re: Building libregex from BSD libc On Sat, 16 Feb 2002, John Poltorak wrote: > REGEX is built using files from GLIBC. It is supposed to be a POSIX > library so I was surprised that I couldn't find the same files under BSD > libc. Posix only specifies the names of the functions to be available and the name of the header file. Everybody is allowed to invent its own scheme for dividing the source code into different files ... > What I was looking for was adding some headers and libraries to a > LIBEMX package, but that would mean adding elements from GLIBC whereas it > has been suggested we don't go down that route since LIBEMU will > incorporate BSD libc. Yes, but still, what's the problem with using GNU regex _now_? When LIBEMU becomes available, everything needs to be reconfigured and rebuild anyway, whereby you'll get the switchover from GNU regex to BSD regex at no cost. Why putting time into a preliminary version now? > I, too, would prefer to retain REGEX.DLL and thought > it should be possible to create a functionally equivalent library using > BSD code as it claimed to be POSIX compliant. Personally, I'd be happy to have less of those very small DLLs containing essentially just one or two functions. What's the advantage of putting everything into its own DLL instead of putting it into some (lib)c.dll? > > By the way, the same consideration also applies to GNU > > versus BSD gettext and most likely also to other libraries. > > That is something we need to consider too. Does it? I.e. is there an own BSD gettext? Or are they just using GNU gettext. Anyway, whenever BSD is providing its own functionality on library level, it's more than likely that every Unix is providing its own functionality (except of course Linux) and GNU tools are famous for working on real Unices as well, so what's the point of that discussion? > I don't think there is any question about replacing GNU utils, I believe > they are even standard on FreeBSD. It's basically a problem about the > inclusion of GLIBC in UnixOS/2. Exactly. To come back to that licence issue: Whenever you use grep on one of your source files, you don't have to put it under GPL, so no problem with using GNU utils. However, if you link against GLIBC (at least if you link statically as every reasonable person would like to do in view of the frequency of incompatible changes) ... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 16 ==========================** Date: Sat, 16 Feb 2002 13:32:17 -0500 From: "Charles R. Hunter" Subject: Re: Problem with READ function On Sat, Feb 16, 2002 at 05:10:15PM +0000, John Poltorak (jp at eyup.org) wrote: > > All I'm trying to do is find the shell version of:- > > parse value linein(FILE) with parm1 parm2 parm3 parm4 > > Currently, I've resorted to this:- > > > ARCHIVE=`grep ^$PKG table | awk '{print $2}'` > PARMS=`grep ^$PKG table | awk '{print $3}'` > SRC=`grep ^$PKG table | awk '{print $4}'` > > which works but seems rather inefficient and clumsy. Well, if your program is a program in itself.. .I mean not in a makefile or anything, you can do this clever bit... :) --- #!/bin/sh KEY=fruit if [ $# -le 0 ]; then $0 `grep ^$KEY index` else ARCHIVE=$2 PARMS=$3 SRC=$4 echo $ARCHIVE $PARMS $SRC # rest of your program goes here... fi --- But if you are adding a routine to another program I think you would have to settle for: #!/bin/sh KEY=fruit line=`grep ^$KEY index` ARCHIVE=`echo $line | cut -d' ' -f2` PARMS=`echo $line | cut -d' ' -f3` SRC=`echo $line | cut -d' ' -f4` echo $ARCHIVE $PARMS $SRC ---- Which is not half as bad as calling awk but not the greatest either. If you don't actually need the variables to be seperate you can of course do this: #!/bin/sh KEY=fruit line=`grep ^$KEY index | cut -f2-` echo $line ---- BTW, the perl way to do all this is: ---- #!/usr/bin/perl my ($ARCHIVE, $PARMS, $SRC, $junk ); ($junk, $ARCHIVE, $PARMS, $SRC)=split(' ', `grep \^$KEY fruit`); print "$ARCHIVE $PARMS $SRC\n"; -- Charles R. Hunter Director, Physics Computer Network Purdue University crh at physics.purdue.edu **= Email 17 ==========================** Date: Sat, 16 Feb 2002 14:04:09 +0000 From: John Poltorak Subject: Re: Building libregex from BSD libc On Sat, Feb 16, 2002 at 12:53:57PM +0100, Stefan Neis wrote: > On Sat, 16 Feb 2002, John Poltorak wrote: > > > What I was looking for was adding some headers and libraries to a > > LIBEMX package, but that would mean adding elements from GLIBC whereas it > > has been suggested we don't go down that route since LIBEMU will > > incorporate BSD libc. > > Yes, but still, what's the problem with using GNU regex _now_? There isn't a problem using REGEX.DLL. In fact it is included in the UnixOS/2 OS2LIBS package. The issue is about inclusion of the REGEX headers and library in LIBEMX which is a proposed predecessor to LIBEMU. > When LIBEMU becomes available, everything needs to be reconfigured and > rebuild anyway, whereby you'll get the switchover from GNU regex to > BSD regex at no cost. Why putting time into a preliminary version now? There is no hold up resulting from this discussion. It's useful to determine how REGEX and INTL should be handled by LIBEMU. > > I, too, would prefer to retain REGEX.DLL and thought > > it should be possible to create a functionally equivalent library using > > BSD code as it claimed to be POSIX compliant. > > Personally, I'd be happy to have less of those very small DLLs containing > essentially just one or two functions. What's the advantage of putting > everything into its own DLL instead of putting it into some (lib)c.dll? Easier maintenance ...? > > > By the way, the same consideration also applies to GNU > > > versus BSD gettext and most likely also to other libraries. > > > > That is something we need to consider too. > > Does it? I.e. is there an own BSD gettext? Or are they just using GNU > gettext. I don't know, that's why I thought it needed consideration. > Regards, > Stefan > -- > Micro$oft is not an answer. It is a question. The answer is 'no'. > -- John **= Email 18 ==========================** Date: Sat, 16 Feb 2002 14:11:05 -0800 (PST) From: "Steve Wendt" Subject: Re: BZIP2 v1.0.2 On Sat, 16 Feb 2002 16:12:09 +0000, John Poltorak wrote: >It is a fairly new compression program and format which is more efficient >than GZIP. Many Unix programs are becoming bundled as tar.bz2 archives. Used by WarpIn as well, if I remember correctly. ----------- "Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws." - Plato (427-347 B.C.) **= Email 19 ==========================** Date: Sat, 16 Feb 2002 14:24:19 +0000 From: John Poltorak Subject: GZIP v1.3.2 There is a beta version of GZIP v1.3.2 available here:- ftp://alpha.gnu.org/gnu/gzip/gzip-1.3.2.tar.gz This will handle files greater than 2GB and is due to be released soon. It would be nice if it worked straight out of the box on OS/2, just like the current version does. Has anyone tried it? -- John **= Email 20 ==========================** Date: Sat, 16 Feb 2002 15:22:15 +0000 From: John Poltorak Subject: BISON v1.33 GNU Bison v1.33 has been released recently. It's available here:- ftp://ftp.gnu.org/pub/gnu/bison/bison-1.33.tar.gz Let's see if it builds... It requires Autoconf v2.52g which is a beta, so I'm a bit scepticle about my chances. -- John **= Email 21 ==========================** Date: Sat, 16 Feb 2002 15:33:18 +0000 From: John Poltorak Subject: BYACC - official home There was some discussion a while ago about the most recent version of BYACC and it appeared that it had been hijacked by the Linux crowd... Is there an 'official' maintainer of BYACC? If so where would he keep it? -- John **= Email 22 ==========================** Date: Sat, 16 Feb 2002 15:51:56 +0000 From: John Poltorak Subject: Re: BISON v1.33 On Sat, Feb 16, 2002 at 10:46:08AM -0500, Thomas Dickey wrote: > On Sat, Feb 16, 2002 at 03:22:15PM +0000, John Poltorak wrote: > > GNU Bison v1.33 has been released recently. It's available here:- > > > > ftp://ftp.gnu.org/pub/gnu/bison/bison-1.33.tar.gz > > > > Let's see if it builds... It requires Autoconf v2.52g which is a beta, so > > I'm a bit scepticle about my chances. > > and in turn autoconf 2.52g relies upon an unreleased version of automake, right? How do I tell? I only know about the autoconf requirement from configure.in which has:- AC_PREREQ(2.52g) It really does seem a bit absurd that a release version of a program depends on beta versions of tools. > -- > Thomas E. Dickey > http://invisible-island.net > ftp://invisible-island.net -- John **= Email 23 ==========================** Date: Sat, 16 Feb 2002 16:12:09 +0000 From: John Poltorak Subject: Re: BZIP2 v1.0.2 On Sat, Feb 16, 2002 at 05:01:15PM +0100, Kris Steenhaut wrote: > > > John Poltorak schreef: > > > A new release of BZIP2 (v1.0.2) slipped out last month, see:- > > > > http://sources.redhat.com/bzip2/index.html#bzip2-latest > > > > Has anyone tried building this on OS/2? > > > > Pardon my ignorance, but what's bzip ? Actually BZIP2... See:- http://sources.redhat.com/bzip2/ It is a fairly new compression program and format which is more efficient than GZIP. Many Unix programs are becoming bundled as tar.bz2 archives. > -- > Groeten uit Gent, > > Kris > > -- John **= Email 24 ==========================** Date: Sat, 16 Feb 2002 16:12:22 +0100 (CET) From: Stefan Neis Subject: Re: Building libregex from BSD libc On Sat, 16 Feb 2002, John Poltorak wrote: > > Personally, I'd be happy to have less of those very small DLLs containing > > essentially just one or two functions. What's the advantage of putting > > everything into its own DLL instead of putting it into some (lib)c.dll? > > Easier maintenance ...? Well, if those functions are part of libc on other platforms, it looks like splitting them into their own DLL is causing additional work instead of making life easier... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 25 ==========================** Date: Sat, 16 Feb 2002 16:47:01 +0000 From: John Poltorak Subject: Re: BISON v1.33 On Sat, Feb 16, 2002 at 11:30:17AM -0500, Thomas Dickey wrote: > On Sat, Feb 16, 2002 at 03:51:56PM +0000, John Poltorak wrote: > > On Sat, Feb 16, 2002 at 10:46:08AM -0500, Thomas Dickey wrote: > > > On Sat, Feb 16, 2002 at 03:22:15PM +0000, John Poltorak wrote: > > > > GNU Bison v1.33 has been released recently. It's available here:- > > > > > > > > ftp://ftp.gnu.org/pub/gnu/bison/bison-1.33.tar.gz > > > and in turn autoconf 2.52g relies upon an unreleased version of automake, right? > > > > How do I tell? > > I grep through the source, looking for automake (but also there are references > to 1.5, 1.5b, etc). # Makefile.in generated by automake 1.5c from Makefile.am. > > It really does seem a bit absurd that a release version of a program > > depends on beta versions of tools. > > ( 2.52g is supposed to be a beta ;-) I did manage to install 2.52g - but not 2.52h... > -- > Thomas E. Dickey > http://invisible-island.net > ftp://invisible-island.net -- John **= Email 26 ==========================** Date: Sat, 16 Feb 2002 17:01:15 +0100 From: Kris Steenhaut Subject: Re: BZIP2 v1.0.2 John Poltorak schreef: > A new release of BZIP2 (v1.0.2) slipped out last month, see:- > > http://sources.redhat.com/bzip2/index.html#bzip2-latest > > Has anyone tried building this on OS/2? > Pardon my ignorance, but what's bzip ? -- Groeten uit Gent, Kris **= Email 27 ==========================** Date: Sat, 16 Feb 2002 17:10:15 +0000 From: John Poltorak Subject: Re: Problem with READ function On Sat, Feb 16, 2002 at 10:44:38AM -0500, Charles R. Hunter wrote: > On Sat, Feb 16, 2002 at 11:06:44AM +0000, John Poltorak (jp at eyup.org) wrote: > > > > > > Can anyone explain what is wrong with this shell script which uses the > > READ function? :- > > > Well you can't exactly do what you're wanting to do with that syntax. > > I think what you want to do is more akin to: > > for x in `grep ^KEY index` > do > for y in $x > do > echo -n $y; > done > done All I'm trying to do is find the shell version of:- parse value linein(FILE) with parm1 parm2 parm3 parm4 Currently, I've resorted to this:- ARCHIVE=`grep ^$PKG table | awk '{print $2}'` PARMS=`grep ^$PKG table | awk '{print $3}'` SRC=`grep ^$PKG table | awk '{print $4}'` which works but seems rather inefficient and clumsy. > Hope this helps. > > Charles > -- > Charles R. Hunter > Director, Physics Computer Network > Purdue University crh at physics.purdue.edu -- John **= Email 28 ==========================** Date: Sat, 16 Feb 2002 19:35:39 -0500 From: Henry Sobotka Subject: Re: Building libregex from BSD libc Andreas Buening wrote: > > The question is whether we need (or want to use) an external _GNU_ regex > to avoid linking that _GNU_ regex statically by those GNU programs. I don't think there's any cut-and-dry answer to that. Programs that accept regular expressions as input, or use them internally, or interpret scripts in which they're heavily used probably benefit from having the regex engine built in. Others where regex usage is occasional might be better off with that code loadable on call. Also, a search of my emx drive for regex.c turns up 12 copies (excluding what appears to be a 16-bit version in rcs) ranging in date from 1993 to 1997, and in size from 87K to 184K. Six are identical in size, so assuming the same of the content, there appear to be seven different versions. This raises the question: are any of those diffs local tweaks to make the core regex engine work better with the parent program, or adapt it to the program's traditional regex flavor, or add useful extensions? Wherever there are any such enhancements, we should also make sure the local regex code is used, rather than any other version on the system. Another key issue is the question of how the BSD and GNU regex engines compare in terms of performance. Suppose the BSD proves superior (by virtue of divine authorship?), and its sitting in memory with the rest of libc offsets the advantages of static linkage, even in the case of heavy users? In brief, I think we should tread carefully with regex, and avoid lumping it in the same class as the other libraries that are problematic because of multiple versions floating around. h~ **= Email 29 ==========================** Date: Sat, 16 Feb 2002 20:03:23 +0100 From: Andreas Buening Subject: Re: Building libregex from BSD libc Stefan Neis wrote: > > On Sat, 16 Feb 2002, John Poltorak wrote: [regex] > > > By the way, the same consideration also applies to GNU > > > versus BSD gettext and most likely also to other libraries. > > > > That is something we need to consider too. > > Does it? I.e. is there an own BSD gettext? Or are they just using GNU > gettext. > Anyway, whenever BSD is providing its own functionality on library level, > it's more than likely that every Unix is providing its own functionality > (except of course Linux) and GNU tools are famous for working on real > Unices as well, so what's the point of that discussion? If I remember correctly there is a note in the GNU gettext docu that gettext hasn't become a Posix standard yet and because of that GNU gettext may not be compatible with other gettext implementation. This also means static linking if no external _GNU_ gettext is found. [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 Redmond where the Shadows lie. **= Email 30 ==========================** Date: Sat, 16 Feb 2002 20:03:31 +0100 From: Andreas Buening Subject: Re: Building libregex from BSD libc Holger Veit wrote: > > On Sat, Feb 16, 2002 at 01:18:27AM +0100, Andreas Buening wrote: > > [snip] > > > > Why? What's wrong with GNU regex? I don't know whether GNU and > > BSD regex are compatible but if we want to use mostly the GNU > > tools (grep, make, whatever) we should also have GNU regex > > No. GNu tools are usually constructed to build on multiple Unix > and non-Unix platforms and will (thanks to autoconf and friends) > take whatever they find as functions on that platform. There may or > may not be a GLIBC (likely not) or REGEX.DLL available. Not really. All GNU programs that require regex contain an internal copy of GNU regex. A lot of them use an autoconf test to decide whether to use the internal or (if available) the external regex. These tests check whether a specific C code sequence works with that external library. If you have only a BSD regex (either as a part of libc or as a standalone dll) I doubt that these programs will use the BSD flavor but instead link the internal GNU regex statically (about 10 KB / executable). Another question is whether the BSD regex _could_ be used if these autoconf tests would be changed. But I don't know whether GNU regex includes some special extensions that are required by some of those GNU programs. > > because a lot of those programs need it. Either we have a standalone > > dll or dozens of programs will link GNU regex statically. > > No. The regex functionality can be built into the libc shared library > on some systems. We have here under OS/2 the situation of a > REGEX and GETTEXT and INTL DLL because EMX didn't provide a > "correct" implementation right from the beginning. Sure. But whether we use a standalone regex.dll or regex is included into a libc.dll, that's only a packaging problem (any maybe a GNU vs. BSD license problem). The question is whether we need (or want to use) an external _GNU_ regex to avoid linking that _GNU_ regex statically by those GNU programs. [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 Redmond where the Shadows lie. **= Email 31 ==========================** Date: Sat, 16 Feb 2002 21:00:31 +0100 From: Andreas Buening Subject: make 3.79.1 Hello! I've just uploaded a new make 3.79.1 release. I treat this as beta, so don't expect to much. But I would appreciate if some people try whether it works for them. You can get it from ftp://ftp.unixos2.com/incoming/make-3_79_1-bin-beta1.zip Using /bin/sh should work like on Unix, cmd might cause some problems. current features: - The shell that is used by make is determined the following way: if an environment variable MAKESHELL exists that one is used otherwise if SHELL is specified in Makefile then that one is used otherwise the following env. vars are used: SHELL, OS2_SHELL otherwise cmd.exe is the default - currently no DOS support for EMX - make -j may not work properly - support for $UNIXROOT to find /bin/sh if necessary - if using cmd for SHELL backslashes are kept unchanged. 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 Redmond where the Shadows lie. **= Email 32 ==========================** Date: Sat, 16 Feb 2002 21:07:38 +0000 From: John Poltorak Subject: Re: make 3.79.1 On Sat, Feb 16, 2002 at 09:00:31PM +0100, Andreas Buening wrote: > Hello! > > I've just uploaded a new make 3.79.1 release. I treat this as > beta, so don't expect to much. But I would appreciate if > some people try whether it works for them. You can get it from > ftp://ftp.unixos2.com/incoming/make-3_79_1-bin-beta1.zip I just tried to install Autoconf 2.52.h with it as I got a command not found error, which I'm hoping this version corrects, but I got an earlier error: make[2]: Entering directory `C:/workdir/autoconf-2.52h/bin' + : sh -x ../config/mkinstalldirs c:/usr/local/bin + errstatus=0 + dirmode= + usage=Usage: mkinstalldirs [-h] [--help] [-m mode] dir ... + test 1 -gt 0 + break + test -d c:/usr/local/bin + shift + exit 0 + list=autom4te autoconf autoheader autoreconf ifnames autoscan autoupdate sh: too many files open in shell make[2]: *** [install-binSCRIPTS] Error 1 Maybe this is an EMX file handles problem. I'll reset EMXOPT and try again, but I haven't had this problem before with other builds. Does anyone have any suggestions about which apps don't build properly because of the 'Command not found' problem? Is this Make likely to be able to install Perl? The last time I tried building Perl 5.6.1 there was some problem put down to 'Make install' treating the INSTALL file as a target. > 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 Redmond where the Shadows lie. -- John **= Email 33 ==========================** Date: Sat, 16 Feb 2002 23:00:11 +0100 From: Andreas Buening Subject: Re: make 3.79.1 John Poltorak wrote: > > On Sat, Feb 16, 2002 at 09:00:31PM +0100, Andreas Buening wrote: [make] > sh: too many files open in shell > make[2]: *** [install-binSCRIPTS] Error 1 > > Maybe this is an EMX file handles problem. I'll reset EMXOPT and try > again, but I haven't had this problem before with other builds. Hmm, I'm using -h256 in EMXOPT. This is definitely enough, but I wonder why sh reports that error. [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 Redmond where the Shadows lie. **= Email 34 ==========================** Date: Sat, 16 Feb 2002 23:32:35 +0100 (CET) From: Stefan Neis Subject: Re: Building libregex from BSD libc On Sat, 16 Feb 2002, Andreas Buening wrote: > Not really. All GNU programs that require regex contain an > internal copy of GNU regex. A lot of them use an autoconf test > to decide whether to use the internal or (if available) the > external regex. Well, I somehow though that this was only for the benefit of those platform that don't provide any regex stuff in their libc. But from looking e.g. at the diff executable on a Solaris machine, it looks like it really contains GNU regex linked into it. > If you have only a BSD regex (either as a part of libc or as > a standalone dll) I doubt that these programs will use the > BSD flavor but instead link the internal GNU regex statically > (about 10 KB / executable). Seems like this is in fact true. So yes, it makes sense to provide a DLL containing GNU regex independent of whatever is included in libc. BTW, what would happens if say emxc.dll contained some regex function (e.g. BSD regex)? Would an external, different DLL providing GNU regex be found and used by autoconf? > Sure. But whether we use a standalone regex.dll or regex is > included into a libc.dll, that's only a packaging problem > (any maybe a GNU vs. BSD license problem). The question is > whether we need (or want to use) an external _GNU_ regex > to avoid linking that _GNU_ regex statically by those GNU > programs. OK, I got the point. Regards, Stefan