From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Thu, 14 Feb 2002 04:15:18 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 135 ************************************************** Wednesday 13 February 2002 Number 135 ************************************************** Subjects for today 1 Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS : IanM" 2 NCURSES configure script for EMX : John Poltorak 3 strstream.h : John Poltorak 4 Re: Use of MAP file : Gerhard Arnecke" 5 Re: strstream.h : Mentore Siesto 6 Re: strstream.h : Holger Veit 7 Re: checking whether make sets ${MAKE}... : Henry Sobotka 8 Re: checking whether make sets ${MAKE}... : Thomas E. Dickey" 9 Re: checking whether make sets ${MAKE}... : Henry Sobotka 10 Re: Shell troubles : Thomas Dickey 11 Clearing BISON temporary files : John Poltorak 12 checking whether make sets ${MAKE}... : John Poltorak 13 Re: Shell troubles : Thomas Dickey 14 Re: checking whether make sets ${MAKE}... : John Poltorak 15 Re: checking whether make sets ${MAKE}... : John Poltorak 16 Re: checking whether make sets ${MAKE}... : John Poltorak 17 Re: Shell troubles : John Poltorak 18 Re: Shell startup file : Andreas Buening 19 Re: Shell troubles : Andreas Buening 20 Re: Autoconf 2.52h : John Poltorak 21 Re: Autoconf 2.52h : Andreas Buening 22 Re: Shell troubles : Andreas Buening **= Email 1 ==========================** Date: Thu, 14 Feb 2002 02:34:43 +1100 (EDT) From: "IanM" Subject: Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS Hi Gerhard > build R550 for the following Aurora files: > a. AFOS2.SYS (16.07.01) with *.SYM and *.MAP > b. SOCKETS.SYS(3.10.01) with *.SYM and .MAP > c. SOCKETSK.SYS(3.10.01) with *.SYM and .MAP > If yes, where should I upload these files? Updated testcase version's of these files are also available at http://www.os2site.com/sw/upgrades/tcpip/tcpip432/ and/or ftp://testcase.boulder.ibm.com/ps/fromibm/tcpip/ Cheers IanM http://www.os2site.com/ **= Email 2 ==========================** Date: Thu, 14 Feb 2002 09:00:16 +0000 From: John Poltorak Subject: NCURSES configure script for EMX The NCURSES tarball includes a README.emx which includes instructions for generating an EMX-specific configure script. I've followed those instructions are closely as I can, but because of the plethora of different versions of utils around, I have no way of knowing whether the configure script produced is correct. Is there one available which I can compare mine with? -- John **= Email 3 ==========================** Date: Thu, 14 Feb 2002 10:42:27 +0000 From: John Poltorak Subject: strstream.h When building NCURSES, I get an error:- ..\c++\cursesw.h:17: strstream.h: No such file or directory I was just about to ask where I should find it when noticing that a truncated version exists which gets renamed after running long.cmd. Just wondered how many people were aware of the need to do this... I guess a developers library package in UnixOS/2 should include the long filenames so there is no requirement to convert the files... -- John **= Email 4 ==========================** Date: Thu, 14 Feb 2002 11:39:36 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: Use of MAP file The standard use for a MAP file is: A 16-bit map file may have at least three sections. A 32-bit map file can have at least 4. The first section is built in the same sequence as the executable. The second section contains a list of all external symbols, sorted by the name of the symbol. USE: This is useful when a programmer who wants to find where some particular variable or routine is located. The third section contains a list of the same symbols, sorted by the location of the symbol. USE:This is useful when you know where something is, and want to find out if it has an external name, or what routine encompasses the address of interest. The fourth section of a 32-bit map file contains a list of locations where the compiled code for each input line begins. This can tell you almost immediately which line of code failed, once you know which program, and where within the program the failing instruction was located. And now a little for me unknown section. Who can show me to produce this special section of a MAP file: 0005:00000404 at BSSP:\R207\src\pmwp\wpcmdf.c 0005:00001470 at BSSP:\R207\src\pmwp\wpcnrvw.c 0005:00000F6C at BSSP:\R207\src\pmwp\wpdataf.c 0005:00000694 at BSSP:\R207\src\pmwp\wpdesk.c 0005:000006E4 at BSSP:\R207\src\pmwp\wpdisk.c 0005:00002CB4 at BSSP:\R207\src\pmwp\wpdiskcv.c 0005:00002D80 at BSSP:\R207\src\pmwp\wpdrives.c 0005:00002D20 at BSSP:\R207\src\pmwp\wpfilter.c 0005:00002960 at BSSP:\R207\src\pmwp\wpfinder.c 0005:00002CEC at BSSP:\R207\src\pmwp\wpfldrcv.c 0005:00002788 at BSSP:\R207\src\pmwp\wpfndfdr.c 0005:00002970 at BSSP:\R207\src\pmwp\wpfolder.c 0005:00000874 at BSSP:\R207\src\pmwp\wpfsys.c 0005:00000740 at BSSP:\R207\src\pmwp\wpicon.c 0005:0000279C at BSSP:\R207\src\pmwp\wplnchpd.c 0005:0000030C at BSSP:\R207\src\pmwp\wpmet.c 0005:00002DAC at BSSP:\R207\src\pmwp\wpminwin.c **= Email 5 ==========================** Date: Thu, 14 Feb 2002 11:57:56 +0100 (CET) From: Mentore Siesto Subject: Re: strstream.h On Thu, 14 Feb 2002, John Poltorak wrote: JP >When building NCURSES, I get an error:- JP > JP >..\c++\cursesw.h:17: strstream.h: No such file or directory I saw this file in my EMX tree before, IIRC. JP >I was just about to ask where I should find it when noticing that a JP >truncated version exists which gets renamed after running long.cmd. JP > JP >Just wondered how many people were aware of the need to do this... I did. Look at the entire EMX install procedure, and you will see when and how long.cmd is to be called (any time you use HPFS, which now means always on OS/2 systems). JP >I guess a developers library package in UnixOS/2 should include the long JP >filenames so there is no requirement to convert the files... Or, as long as we keep on using EMX, make a little install script which modifies CONFIG.SYS and calls long.cmd, among the other things. With the LIBEMU final release this should be no more necessary (I think). -- Mentore Siesto Team OS/2 Italia (http://www.teamos2.it) Home page: http://www.geocities.com/mentoruccio/ **= Email 6 ==========================** Date: Thu, 14 Feb 2002 12:27:26 +0100 From: Holger Veit Subject: Re: strstream.h On Thu, Feb 14, 2002 at 11:57:56AM +0100, Mentore Siesto wrote: > On Thu, 14 Feb 2002, John Poltorak wrote: > > JP >When building NCURSES, I get an error:- > JP > > JP >..\c++\cursesw.h:17: strstream.h: No such file or directory > > I saw this file in my EMX tree before, IIRC. It is in the alpha/emxtree.zip file from me in emx/include/cpp/strstream.h (short name strstrea.h) > JP >I was just about to ask where I should find it when noticing that a > JP >truncated version exists which gets renamed after running long.cmd. > JP > > JP >Just wondered how many people were aware of the need to do this... > > I did. Look at the entire EMX install procedure, and you will see when and > how long.cmd is to be called (any time you use HPFS, which now means > always on OS/2 systems). If we are now packaging an intermediate EMX plugin package, then we should already rely on HPFS and throw away the whole long/short garbage; the only thing to ship are the long versions. With repackaging, the LGPL still applies - reference to complete original sources, but it dosen't mean we have to ship the unmodified package (this is not Troll QT, BTW). > JP >I guess a developers library package in UnixOS/2 should include the long > JP >filenames so there is no requirement to convert the files... > > Or, as long as we keep on using EMX, make a little install script which > modifies CONFIG.SYS and calls long.cmd, among the other things. > With the LIBEMU final release this should be no more necessary (I think). LIBEMU will require HPFS or another longname filesystem, for sure. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 7 ==========================** Date: Thu, 14 Feb 2002 12:59:20 -0500 From: Henry Sobotka Subject: Re: checking whether make sets ${MAKE}... John Poltorak wrote: > > Can someone explain the purpose of this configure test? :- > > checking whether make sets ${MAKE}... > > Do I want it to be set and if so how? It tests whether make sets the variable MAKE for subsequent use in scripts. You should be getting a "yes" from GNU make without having to do anything. If you're seeing "no", it's a bug in autoconf that in 2.13 can be fixed by adding a semicolon to the sed test concerned in the definition of AC_PROG_MAKE_SET (in acspecific.m4 IIRC). h~ **= Email 8 ==========================** Date: Thu, 14 Feb 2002 13:45:27 -0500 (EST) From: "Thomas E. Dickey" Subject: Re: checking whether make sets ${MAKE}... On Thu, 14 Feb 2002, John Poltorak wrote: > > Can someone explain the purpose of this configure test? :- > > checking whether make sets ${MAKE}... > > Do I want it to be set and if so how? $(MAKE) is useful in recursive make's. Not all make-programs have a default value for the symbol, so - for those - one must provide the symbol if it's used. But conversely, setting it when the make-program already sets it will do odd things such as losing recursive options. -- T.E.Dickey http://invisible-island.net ftp://invisible-island.net **= Email 9 ==========================** Date: Thu, 14 Feb 2002 13:57:20 -0500 From: Henry Sobotka Subject: Re: checking whether make sets ${MAKE}... John Poltorak wrote: > > checking whether make sets ${MAKE}... ./configure.: ac_maketemp="make": not found > > I'd like to know whether this is an OS/2 issue before reporting it on the > autoconf list. > > If it's a problem with autoconf I may get it fixed, but I'm not sure how > to find the root cause. Does it depend on the version of Make being used? If make is accessible, then it may well be a problem with the test rather than with your environment. Find the relevant block in configure to see how it's testing for that feature. h~ **= Email 10 ==========================** Date: Thu, 14 Feb 2002 15:31:10 -0500 From: Thomas Dickey Subject: Re: Shell troubles On Thu, Feb 14, 2002 at 09:06:30PM +0100, Andreas Buening wrote: > and not a 90% compatible shell. Either that \b stuff is sh compatible > or it is not. Then either bash or ksh is wrong. > Unfortunately there seems to be no such standard, otherwise autoconf > wouldn't need code like ksh is standard (pdksh may/may not follow that standard; bash doesn't) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 11 ==========================** Date: Thu, 14 Feb 2002 15:41:45 +0000 From: John Poltorak Subject: Clearing BISON temporary files I've noticed a whole load of files in %TMP% which have been created by BISON; b.act.*, b.attrs.*, b.defs.*, b.tab.*. Do they normally get left around or is there an option for deleting them? Also, is there anyway to identify the originator of various temp files? I often have files dumped by some process and would like to be able to identify them in case for the purpose of doing a general tidy up periodically. There seem to be quite a few p[o,p,r]a* files around. Anyone know what they are? -- John **= Email 12 ==========================** Date: Thu, 14 Feb 2002 17:26:58 +0000 From: John Poltorak Subject: checking whether make sets ${MAKE}... Can someone explain the purpose of this configure test? :- checking whether make sets ${MAKE}... Do I want it to be set and if so how? -- John **= Email 13 ==========================** Date: Thu, 14 Feb 2002 17:51:53 -0500 From: Thomas Dickey Subject: Re: Shell troubles On Thu, Feb 14, 2002 at 11:05:07PM +0100, Andreas Buening wrote: > Thomas Dickey wrote: > > > > On Thu, Feb 14, 2002 at 09:06:30PM +0100, Andreas Buening wrote: > > > > > and not a 90% compatible shell. Either that \b stuff is sh compatible > > > or it is not. Then either bash or ksh is wrong. > > > Unfortunately there seems to be no such standard, otherwise autoconf > > > wouldn't need code like > > > > ksh is standard (pdksh may/may not follow that standard; bash doesn't) > > Is this for sure? Btw, is there a definition what features > /bin/sh exactly should have? (not) coincidentally, there's a parallel thread on autoconf at gnu.org: From autoconf-admin at gnu.org Thu Feb 14 17:48:39 2002 Return-Path: Received: from localhost (tom at localhost [127.0.0.1]) by invisible-island.net (8.10.2/8.10.2) with ESMTP id g1EMmdk00703 for ; Thu, 14 Feb 2002 17:48:39 -0500 Received: from herndon4.his.com by localhost with IMAP (fetchmail-5.4.0) for tom at localhost (single-drop); Thu, 14 Feb 2002 17:48:39 -0500 (EST) Received: from fencepost.gnu.org (we-refuse-to-spy-on-our-users at fencepost.gnu.org [199.232.76.164]) by herndon4.his.com (8.9.3/8.9.3) with ESMTP id RAA08157 for ; Thu, 14 Feb 2002 17:06:46 -0500 (EST) Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16bU1C-0008Hn-00; Thu, 14 Feb 2002 17:06:18 -0500 Received: from alcor.twinsun.com ([198.147.65.9]) by fencepost.gnu.org with esmtp (Exim 3.33 #1 (Debian)) id 16bTzA-00088v-00 for ; Thu, 14 Feb 2002 17:04:12 -0500 Received: from shade.twinsun.com ([192.54.239.27]) by alcor.twinsun.com (8.12.1/8.12.1) with ESMTP id g1EM3wrX021054; Thu, 14 Feb 2002 14:03:58 -0800 (PST) Received: (eggert at localhost) by shade.twinsun.com (8.11.6+Sun/8.11.6) id g1EM3wN01150; Thu, 14 Feb 2002 14:03:58 -0800 (PST) From: Paul Eggert Message-Id: <200202142203.g1EM3wN01150 at shade.twinsun.com> To: jp at eyup.org CC: autoconf at gnu.org In-reply-to: <20020214144901.I89 at eyup.org> (jp at eyup.org) Subject: Re: DOS path References: <20020213202120.Y89 at eyup.org> <200202132346.g1DNkNw04457 at shade.twinsun.com> <1013673240.28939.42.camel at bender.falconsoft.be> <20020214101846.D89 at eyup.org> <1013689868.30677.77.camel at bender.falconsoft.be> <20020214130912.H89 at eyup.org> <1013695665.30677.97.camel at bender.falconsoft.be> <20020214144901.I89 at eyup.org> Sender: autoconf-admin at gnu.org Errors-To: autoconf-admin at gnu.org X-BeenThere: autoconf at gnu.org X-Mailman-Version: 2.0.5 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Discussion list for the autoconf build system List-Unsubscribe: , List-Archive: Date: Thu, 14 Feb 2002 14:03:58 -0800 (PST) Status: RO Content-Length: 930 Lines: 24 > Date: Thu, 14 Feb 2002 14:49:01 +0000 > From: John Poltorak > > Again I must point out that the behaviour of ksh's echo could be > > considered broken; it requires an option to behave 'normally'. > > Is there a definitive view on this? POSIX 1003.2-1992 says that the results of echo are undefined if the first argument is '-n' or if any arguments contain a backslash. POSIX 1003.1-2001 requires the System V behavior, in which '-n' is not an option and in which escapes should be interpreted. > > The OS/2 porter of KSH considers that the default mode for ECHO should be > to interpret escape characters rather than ignore them. The OS/2 porter of KSH is correct; that's the only way to conform to both 1003.2-1992 and 1003.1-2001. Autoconf must be portable to older systems, though, so it should not use either -n or backslashes. (This is yet another reason for avoiding backslashes in file names. :-) -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net **= Email 14 ==========================** Date: Thu, 14 Feb 2002 18:27:51 +0000 From: John Poltorak Subject: Re: checking whether make sets ${MAKE}... On Thu, Feb 14, 2002 at 12:59:20PM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > Can someone explain the purpose of this configure test? :- > > > > checking whether make sets ${MAKE}... > > > > Do I want it to be set and if so how? > > It tests whether make sets the variable MAKE for subsequent use in > scripts. You should be getting a "yes" from GNU make without having to > do anything. If you're seeing "no", it's a bug in autoconf that in 2.13 > can be fixed by adding a semicolon to the sed test concerned in the > definition of AC_PROG_MAKE_SET (in acspecific.m4 IIRC). It used to get set, or rather I never noticed it, but now I'm trying v2.52g and get:- checking whether make sets ${MAKE}... ./configure.: ac_maketemp="make": not found I'd like to know whether this is an OS/2 issue before reporting it on the autoconf list. If it's a problem with autoconf I may get it fixed, but I'm not sure how to find the root cause. Does it depend on the version of Make being used? > h~ -- John **= Email 15 ==========================** Date: Thu, 14 Feb 2002 19:34:20 +0000 From: John Poltorak Subject: Re: checking whether make sets ${MAKE}... On Thu, Feb 14, 2002 at 01:57:20PM -0500, Henry Sobotka wrote: > John Poltorak wrote: > > > > checking whether make sets ${MAKE}... ./configure.: ac_maketemp="make": not found > > > > I'd like to know whether this is an OS/2 issue before reporting it on the > > autoconf list. > > > > If it's a problem with autoconf I may get it fixed, but I'm not sure how > > to find the root cause. Does it depend on the version of Make being used? > > If make is accessible, then it may well be a problem with the test > rather than with your environment. Find the relevant block in configure > to see how it's testing for that feature. This seems to be it:- echo "$as_me:$LINENO: checking whether ${MAKE-make} sets \${MAKE}" >&5 echo $ECHO_N "checking whether ${MAKE-make} sets \${MAKE}... $ECHO_C" >&6 set dummy ${MAKE-make}; ac_make=`echo "$2" | sed 'y,./+-,__p_,'` if eval "test \"\${ac_cv_prog_make_${ac_make}_set+set}\" = set"; then echo $ECHO_N "(cached) $ECHO_C" >&6 else cat >conftest.make <<\_ACEOF all: at echo 'ac_maketemp="${MAKE}"' _ACEOF # GNU make sometimes prints "make[1]: Entering...", which would confuse us. eval `${MAKE-make} -f conftest.make 2>/dev/null | grep temp=` if test -n "$ac_maketemp"; then eval ac_cv_prog_make_${ac_make}_set=yes else eval ac_cv_prog_make_${ac_make}_set=no fi rm -f conftest.make fi if eval "test \"`echo '$ac_cv_prog_make_'${ac_make}_set`\" = yes"; then echo "$as_me:$LINENO: result: yes" >&5 echo "${ECHO_T}yes" >&6 SET_MAKE= else echo "$as_me:$LINENO: result: no" >&5 echo "${ECHO_T}no" >&6 SET_MAKE="MAKE=${MAKE-make}" fi I can't make head nor tail of it... I guess it isn't easy to run it standalone... > h~ -- John **= Email 16 ==========================** Date: Thu, 14 Feb 2002 19:45:31 +0000 From: John Poltorak Subject: Re: checking whether make sets ${MAKE}... On Thu, Feb 14, 2002 at 01:57:20PM -0500, Henry Sobotka wrote: > If make is accessible, then it may well be a problem with the test > rather than with your environment. Find the relevant block in configure > to see how it's testing for that feature. I found what it was... I'd been using make v3.75 for some tests and forgot to restore v3.76.1. It's OK now. > h~ -- John **= Email 17 ==========================** Date: Thu, 14 Feb 2002 20:22:14 +0000 From: John Poltorak Subject: Re: Shell troubles On Thu, Feb 14, 2002 at 09:06:30PM +0100, Andreas Buening wrote: > > > > > > > > On Tue, Feb 12, 2002 at 10:01:05AM +0000, csaba.raduly at sophos.com wrote: > > > > > > > > sh is interpreting the $PATH variable. The "\b" is interpreted as > > > > > BACKSPACE ( ASCII 8 ), so the shell prints: > > > > > This seems to be a feature (not a bug) of ksh only. > > > > IZ will not accept it is a bug. IHV shells which do display '\b' are > > buggy. > > It _is_ a feature but only ksh has it. And in my opinion it is > a misfeature. It doesn't matter what a shell is doing when it is > used interactively but if I call /bin/sh then I expect /bin/sh > and not a 90% compatible shell. Either that \b stuff is sh compatible > or it is not. Then either bash or ksh is wrong. I guess we decide what standard we want to adopt for UnixOS/2... Which program should we use for /bin/sh? What are the candidates? I have no preferences either way and will defer to those who can see the bigger picture in making such a choice. > 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 18 ==========================** Date: Thu, 14 Feb 2002 21:06:09 +0100 From: Andreas Buening Subject: Re: Shell startup file John Poltorak wrote: > [snip] > So is there any way I can override the shell's default behaviour of > interpreting escape sequences such as '\b' as backspace when using 'echo'? You can define an alias (alias echo="echo -E") but that works only for interactive shells. 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 19 ==========================** Date: Thu, 14 Feb 2002 21:06:30 +0100 From: Andreas Buening Subject: Re: Shell troubles John Poltorak wrote: > > On Wed, Feb 13, 2002 at 12:16:40AM +0100, Andreas Buening wrote: > > John Poltorak wrote: > > > > > > On Tue, Feb 12, 2002 at 10:01:05AM +0000, csaba.raduly at sophos.com wrote: > > > > > > sh is interpreting the $PATH variable. The "\b" is interpreted as > > > > BACKSPACE ( ASCII 8 ), so the shell prints: > > > This seems to be a feature (not a bug) of ksh only. > > IZ will not accept it is a bug. IHV shells which do display '\b' are > buggy. It _is_ a feature but only ksh has it. And in my opinion it is a misfeature. It doesn't matter what a shell is doing when it is used interactively but if I call /bin/sh then I expect /bin/sh and not a 90% compatible shell. Either that \b stuff is sh compatible or it is not. Then either bash or ksh is wrong. Unfortunately there seems to be no such standard, otherwise autoconf wouldn't need code like case `echo "testing\c"; echo 1,2,3`,`echo -n testing; echo 1,2,3` in *c*,-n*) ECHO_N= ECHO_C=' ' ECHO_T=' ' ;; *c*,* ) ECHO_N=-n ECHO_C= ECHO_T= ;; *) ECHO_N= ECHO_C='\c' ECHO_T= ;; esac to determine some shell behavior. 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 20 ==========================** Date: Thu, 14 Feb 2002 22:19:16 +0000 From: John Poltorak Subject: Re: Autoconf 2.52h On Thu, Feb 14, 2002 at 11:02:32PM +0100, Andreas Buening wrote: > John Poltorak wrote: > > > > There's a new beta of Autoconf here:- > > > > ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.52h.tar.gz > > > > I can't get this on to install. There's some msgs about 'Command not > > found' which are reminiscent of some Make bugs I've seen. They didn't > > occur with the previous beta though. > > Yes, that's a make bug. Hopefully that will be fixed before too long ;-)... > However, there is also another bug, > so you cannot recreate autoconf's configure script. Is there a fix available for this? > 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 21 ==========================** Date: Thu, 14 Feb 2002 23:02:32 +0100 From: Andreas Buening Subject: Re: Autoconf 2.52h John Poltorak wrote: > > There's a new beta of Autoconf here:- > > ftp://alpha.gnu.org/gnu/autoconf/autoconf-2.52h.tar.gz > > I can't get this on to install. There's some msgs about 'Command not > found' which are reminiscent of some Make bugs I've seen. They didn't > occur with the previous beta though. Yes, that's a make bug. However, there is also another bug, so you cannot recreate autoconf's 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. **= Email 22 ==========================** Date: Thu, 14 Feb 2002 23:05:07 +0100 From: Andreas Buening Subject: Re: Shell troubles Thomas Dickey wrote: > > On Thu, Feb 14, 2002 at 09:06:30PM +0100, Andreas Buening wrote: > > > and not a 90% compatible shell. Either that \b stuff is sh compatible > > or it is not. Then either bash or ksh is wrong. > > Unfortunately there seems to be no such standard, otherwise autoconf > > wouldn't need code like > > ksh is standard (pdksh may/may not follow that standard; bash doesn't) Is this for sure? Btw, is there a definition what features /bin/sh exactly should have? 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.