From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Tue, 12 Feb 2002 04:15:07 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 133 ************************************************** Monday 11 February 2002 Number 133 ************************************************** Subjects for today 1 Re: Multimedia headers : Jack Troughton 2 Re: Shells... : Jack Troughton 3 Shell troubles : John Poltorak 4 Re: Shell troubles : csaba.raduly at sophos.com 5 Re: make 3.79.1 and OS/2 "features" : csaba.raduly at sophos.com 6 Re: Shell troubles : John Poltorak 7 Re: Multimedia headers : Gerhard Arnecke" 8 Re: Multimedia headers : John Poltorak 9 SLANG : John Poltorak 10 Re: Multimedia headers : Gerhard Arnecke" 11 Shells... : John Poltorak 12 Re: Multimedia headers : Gerhard Arnecke" 13 Re: EMX C-library extensions : Stefan Neis 14 Re: EMX C-library extensions : Stefan Neis 15 Re: EMX C-library extensions : MS" 16 Re: Shells... : John Poltorak 17 Re: GCC 3.0.2 problems : MS" 18 Building SLANG : John Poltorak 19 Re: GCC 3.0.2 problems : pla at cland.ru 20 Re: Multimedia headers : John Poltorak 21 Re: Multimedia headers : John Poltorak 22 Re: Multimedia headers : Holger Veit 23 cat.exe fails for long command lines whe called from unix-like shell : Thomas Hoffmann **= Email 1 ==========================** Date: Tue, 12 Feb 2002 07:33:50 -0500 From: Jack Troughton Subject: Re: Multimedia headers John Poltorak wrote: > > On Tue, Feb 12, 2002 at 10:26:09AM +0100, Gerhard Arnecke wrote: > > John, > > > > I can upload these headers as the newest version. Please give me the exact address > > and directory. The lenght of the file is a little more than 1.5 MB. Then one can extract the > > mmpm/2 header files, and if there is another wish one can access every time. > > I guess you could upload stuff to ftp://unixos2.com/incoming, or maybe > ftp://www.eyup.org/ ... although I'm not sure if we should include the > OS/2 toolkit in UnixOS/2... It is likely that many people would already > have it installed in its own location, so incorporating it into the > standard UnixOS/2 headers would create unnecessary duplication. You might also run into IP issues... unixos2 doesn't "own" the os2tk. I think you're better off including pointers to it on the website and in the docs, for those people that don't have the latest versions of warp. Regards, Jack **= Email 2 ==========================** Date: Tue, 12 Feb 2002 07:41:22 -0500 From: Jack Troughton Subject: Re: Shells... John Poltorak wrote: > > On Sun, Jan 27, 2002 at 10:21:17AM +1100, Alex Newman wrote: > > With regard to sh(ells): I come across conflicting advice from various > > people: some say to use ksh nad make a copy of ksh.exe to /bin/sh.exe; > > others say to use bash. And pretty well everyone say that all ported the > > un*x shells are broken in one way or another. So which one (and wich > > version?) is the "canonical" shell for emx shell and/or unixos/2(aka > > posix2?)? > > I think this is something which needs quite a bit of discussion... > > There are so many different shells around, and even so many different > builds of those shells, that it is not even obvious which bash or ksh > someone may be referring to, when they either recommend or criticise a > particular shell. Perhaps a different approach is better. Instead of creating "broken" versions of various *nix shells on OS/2 to consider the particularities of our platform, someone should consider creating a new shell (emxsh? os2sh?) that has the correct assumptions built in from the ground up and can properly interpret existing shell scripts. This avoids creating problems for *nix people coming here and finding what they would consider wacky behaviour when they use their fave tool on our platform... Just a thought... I have no doubt that would be a pretty huge project. OTOH, I'm not necessarily talking about a "from scratch" implementation... it could largely be based on an existing shell. It's just that by giving it a new name we could help avoid conflicts. It would also perhaps make things easier on people writing multiplatform apps on *nix... they could perhaps save a lot of work by ifdefing the platform to OS/2 and declaring os2sh as the shell of choice on that platform. Regards, Jack **= Email 3 ==========================** Date: Tue, 12 Feb 2002 08:31:15 +0000 From: John Poltorak Subject: Shell troubles Using SH.EXE from PDKSH, I get problems displaying the path. Can anyone else confirm these results? c:\>cat paf.sh echo "$PATH" c:\>set path=C:\USR\BIN; c:\>sh paf.sh C:\USR\BIN; c:\>set path=c:\usr\bin; c:\>sh paf.sh c:\usin; It appears that lower case is treated differently by the shell Some other shells seem to work OK, but not when the script is run using EXTPROC. Can anyone explain what may be happening here? It looks as though my shell isn't working correctly. -- John **= Email 4 ==========================** Date: Tue, 12 Feb 2002 10:01:05 +0000 From: csaba.raduly at sophos.com Subject: Re: Shell troubles On 12/02/2002 08:31:15 owner-os2-unix wrote: >Using SH.EXE from PDKSH, I get problems displaying the path. Can anyone >else confirm these results? > >c:\>cat paf.sh >echo "$PATH" > > >c:\>set path=C:\USR\BIN; >c:\>sh paf.sh >C:\USR\BIN; > > >c:\>set path=c:\usr\bin; >c:\>sh paf.sh >c:\usin; > > >It appears that lower case is treated differently by the shell > Serves you right for using backslashes :-) sh is interpreting the $PATH variable. The "\b" is interpreted as BACKSPACE ( ASCII 8 ), so the shell prints: c : \ u s r i n ^^^ ^__________ blotted over after the backspace \u has no special meaning, passed through Redirect its output to a printer, and see 'r' and 'i' superimposed. Moral of story: use forward slashes. Many shells "inherit" the OS/2 PATH environment variable. If this particular shell doesn't convert backslashes to slashes in its $PATH, you need to do it manually; something like this: set path=`echo $PATH | sed -e "s/\\\\/\\//"` Note also that for shell scripts, the path separator (IFS) is the colon, not the semicolon. Thus, most scripts (e.g. configure)-: would chop "c:/usr/bin;c:/emx/bin" into c /usr/bin;c /emx/bin Not what we (long-time DOS/OS2 users) would expect. -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 5 ==========================** Date: Tue, 12 Feb 2002 10:14:36 +0000 From: csaba.raduly at sophos.com Subject: Re: make 3.79.1 and OS/2 "features" On 11/02/2002 21:32:17 Andreas Buening wrote: >csaba.raduly at sophos.com wrote: >> >> On 09/02/2002 19:11:11 Andreas Buening wrote: > >[snip] > >> >2) FAT filesystems round file time to the nearest even second? >> >(does this also apply to VFAT, FAT32?) >> >> Yes. The "seconds" field is five bits wide, hence it can only count >> up to 31. This inherent to the FAT filesystem's file control block >> structure. > >What kind of idiot invents such crap? > Micros~1 ? (well, that's probably unfair; they might have inherited that from CP/M) The correct answer is: a real engineer, short on memory and disk space. To quote from bsedos.h: typedef struct _FTIME /* ftime */ { UINT twosecs : 5; UINT minutes : 6; UINT hours : 5; } FTIME; typedef FTIME *PFTIME; You need 5 bits for the hour, six bits for the minute. Assigning only five bits to the "seconds", the whole thing fits into two bytes. >> >> Absolutely. I doubt anybody has cc.exe, unless it's a copy of gcc. >> "#define GCC_IS_NATIVE" might be worth setting, although >> this changes the defaults for $LEX and $YACC to flex and bison. > >But does this matter? There is no native yacc/lex or bison/flex >on OS/2. > It matters for those who write minimal makefiles, like this: --- begin --- CFLAGS= -g -O LIBS=-lsocket foo : foo.c bar.c --- end --- and rely on the predefined rules and implicit dependencies. GNU make by default predefines the "classic" set: CC=cc LEX=lex YACC=yacc If "#define GCC_IS_NATIVE", then it defines CC=gcc, so we don't have to start or makefiles with CC=gcc CXX=g++ A side-effect of "#define GCC_IS_NATIVE" is that LEX=flex YACC=bison As we have both lex/yacc and flex/bison available, it's no big deal. GCC_IS_NATIVE is the opposite of "cc (the old K&R style C compiler, available with old Unices) is the native compiler" (you have to remember the environment GNU grew up :) -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: csaba.raduly at sophos.com http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 **= Email 6 ==========================** Date: Tue, 12 Feb 2002 10:21:31 +0000 From: John Poltorak Subject: Re: Shell troubles On Tue, Feb 12, 2002 at 10:01:05AM +0000, csaba.raduly at sophos.com wrote: > > On 12/02/2002 08:31:15 owner-os2-unix wrote: > > >Using SH.EXE from PDKSH, I get problems displaying the path. Can anyone > >else confirm these results? > > > >c:\>cat paf.sh > >echo "$PATH" > > > > > >c:\>set path=C:\USR\BIN; > >c:\>sh paf.sh > >C:\USR\BIN; > > > > > >c:\>set path=c:\usr\bin; > >c:\>sh paf.sh > >c:\usin; > > > > > >It appears that lower case is treated differently by the shell > > > > Serves you right for using backslashes :-) > sh is interpreting the $PATH variable. The "\b" is interpreted as > BACKSPACE ( ASCII 8 ), so the shell prints: > > c : \ u s r i n > ^^^ ^__________ blotted over after the backspace > \u has no special meaning, passed through > > Redirect its output to a printer, and see 'r' and 'i' > superimposed. Thanks for the explanation. This has been driving me nuts for ages. I thought it was something to do with the shell treating uppercase differently but it's all due to '\b' being misinterpreted... > Moral of story: use forward slashes. I think the lesson for me is to start using ASH instead which, IMV, behaves correctly. > Many shells "inherit" the OS/2 PATH environment variable. ... except they don't if that PATH includes \b. > If this particular shell doesn't convert backslashes to slashes > in its $PATH, you need to do it manually; something like this: > > set path=`echo $PATH | sed -e "s/\\\\/\\//"` > > but you do need lots of backslashes> > > Note also that for shell scripts, the path separator (IFS) > is the colon, not the semicolon. Thus, most scripts (e.g. configure)-: > would chop "c:/usr/bin;c:/emx/bin" into > > c > /usr/bin;c > /emx/bin > > Not what we (long-time DOS/OS2 users) would expect. I guess we need to adopt a shell which works in an OS/2 friendly way. Until now I thought sh.exe from PDKSH did so... > -- > Csaba Ráduly, Software Engineer Sophos Anti-Virus > email: csaba.raduly at sophos.com http://www.sophos.com > US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933 > -- John **= Email 7 ==========================** Date: Tue, 12 Feb 2002 10:26:09 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: Multimedia headers John, I can upload these headers as the newest version. Please give me the exact address and directory. The lenght of the file is a little more than 1.5 MB. Then one can extract the mmpm/2 header files, and if there is another wish one can access every time. GA **= Email 8 ==========================** Date: Tue, 12 Feb 2002 10:43:22 +0000 From: John Poltorak Subject: Re: Multimedia headers On Tue, Feb 12, 2002 at 10:26:09AM +0100, Gerhard Arnecke wrote: > John, > > I can upload these headers as the newest version. Please give me the exact address > and directory. The lenght of the file is a little more than 1.5 MB. Then one can extract the > mmpm/2 header files, and if there is another wish one can access every time. I guess you could upload stuff to ftp://unixos2.com/incoming, or maybe ftp://www.eyup.org/ ... although I'm not sure if we should include the OS/2 toolkit in UnixOS/2... It is likely that many people would already have it installed in its own location, so incorporating it into the standard UnixOS/2 headers would create unnecessary duplication. > GA > > > -- John **= Email 9 ==========================** Date: Tue, 12 Feb 2002 11:13:55 +0000 From: John Poltorak Subject: SLANG The Makefile which is used for building SLANG includes:- CC = gcc -Zmtd -DEMX_VIDEO CFLAGS = -DOS2 -D__os2__ P = / O = o # Object extension SRCDIR = .# Location of sources OBJDIR = emxobjs# Location of objects TARGET = $(OBJDIR)/slang.a COMPILE_CMD = $(CC) -c $(CFLAGS) -o # LIBDEPS = TOUCH = touch COPY = cp Should any of this be changed for a UnixOS/2 package? I think the target should be libslang.a as is standard on Unix, and since we now have a linker which will locate this file through '-lslang' and don't see any need to be different. How about the CFLAGS? Are they set optimally? -- John **= Email 10 ==========================** Date: Tue, 12 Feb 2002 12:01:24 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: Multimedia headers >I'm not sure if we should include the OS/2 toolkit in UnixOS/2... No. it's only the set of headers. I'm not authorized lincesed material to distribute under my responsibility. Look ahead and decide waht you want. You can delete all what isn't wanted. And: the whole toolkit ha sa length of several MBs. GA **= Email 11 ==========================** Date: Tue, 12 Feb 2002 12:01:57 +0000 From: John Poltorak Subject: Shells... On Sun, Jan 27, 2002 at 10:21:17AM +1100, Alex Newman wrote: > With regard to sh(ells): I come across conflicting advice from various > people: some say to use ksh nad make a copy of ksh.exe to /bin/sh.exe; > others say to use bash. And pretty well everyone say that all ported the > un*x shells are broken in one way or another. So which one (and wich > version?) is the "canonical" shell for emx shell and/or unixos/2(aka > posix2?)? I think this is something which needs quite a bit of discussion... There are so many different shells around, and even so many different builds of those shells, that it is not even obvious which bash or ksh someone may be referring to, when they either recommend or criticise a particular shell. I have been using the sh.exe which comes with PDKSH 5.2.14 for some time and have only just found out that it screws up my PATH if it inherits a string with '\b' as in 'c:\bin' in it, so I'm thinking of moving to ASH for building apps in future. I'd like to know what other people recommend. Does anyone use ZSHELL? > Or does it depend on which sh a particular package was > ported/compiled on? > > Has anyone else tried (and had success with!) tcsh 6.072? Talking of TCSH... wonder if there's any chance of an update... > Cheers, > > Alex Newman -- John **= Email 12 ==========================** Date: Tue, 12 Feb 2002 12:12:21 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: Multimedia headers I've uploaded the file DETK45HE.ZIP to ftp://unixos2.com/incoming which includes the header files of OS/2 WARP Developer's Toolkit 4.5 and the library MMPM2.LIB **= Email 13 ==========================** Date: Tue, 12 Feb 2002 12:15:07 +0100 (CET) From: Stefan Neis Subject: Re: EMX C-library extensions On Mon, 11 Feb 2002, MS wrote: > It is missing all the mentioned fct. from ctype.h. I added the declarations (and definitions) to ctype.h to > circumvent this problem, but I do not feel very comfortable with it. AFAICT, this was done in emxfix04 already. At least my ctype.h contains some such "extern inline" functions within #ifdef __cplusplus and the contained doc-file says: o : don't define macros when compiling C++ Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 14 ==========================** Date: Tue, 12 Feb 2002 12:18:21 +0100 (CET) From: Stefan Neis Subject: Re: EMX C-library extensions On Mon, 11 Feb 2002, MS wrote: > On Mon, 11 Feb 2002 21:47:30 +0000, John Poltorak wrote: > > Okay, in the meantime I found the posix2 website and dug through the cvs repository. My problem had > already been solved (well, the same way I did it...). > It just seems there has not been much activity on the > posix2 project lately. For me it's working reliably. There are some problems with sockets which are annyoing, though. > Does anyone have more detailled information about the status of this > project? Waiting to be released as libemu, which includes "some" added functionality and bug fixes... Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 15 ==========================** Date: Tue, 12 Feb 2002 12:39:20 +0100 (MEZ) From: "MS" Subject: Re: EMX C-library extensions On Tue, 12 Feb 2002 12:15:07 +0100 (CET), Stefan Neis wrote: Hello Stefan, thanks for your very helpful answer. >AFAICT, this was done in emxfix04 already. At least my >ctype.h contains some such "extern inline" functions within >#ifdef __cplusplus and the contained doc-file says: >o : don't define macros when compiling C++ > Aaaaargh. I was looking at the dates of emxfix04.zip and emxrt.zip, figured I would not need to install it because dates are equal. I should have taken a look into. Anyway, the solution in emxfix04 is the same I handcrafted into ctype.h... STLport-4.5.1 is compiling now with gcc3.0.2, have to test it though. Regards, Martin Schafföner **= Email 16 ==========================** Date: Tue, 12 Feb 2002 13:58:05 +0000 From: John Poltorak Subject: Re: Shells... On Tue, Feb 12, 2002 at 07:41:22AM -0500, Jack Troughton wrote: > John Poltorak wrote: > > > > On Sun, Jan 27, 2002 at 10:21:17AM +1100, Alex Newman wrote: > > > With regard to sh(ells): I come across conflicting advice from various > > > people: some say to use ksh nad make a copy of ksh.exe to /bin/sh.exe; > > > others say to use bash. And pretty well everyone say that all ported the > > > un*x shells are broken in one way or another. So which one (and wich > > > version?) is the "canonical" shell for emx shell and/or unixos/2(aka > > > posix2?)? > > > > I think this is something which needs quite a bit of discussion... > > > > There are so many different shells around, and even so many different > > builds of those shells, that it is not even obvious which bash or ksh > > someone may be referring to, when they either recommend or criticise a > > particular shell. > > Perhaps a different approach is better. Instead of creating "broken" > versions of various *nix shells on OS/2 to consider the particularities > of our platform, someone should consider creating a new shell (emxsh? > os2sh?) that has the correct assumptions built in from the ground up and > can properly interpret existing shell scripts. I don't think anyone creates broken versions on purpose... What I'd like to do is identify and catalogue various broken features in different ports and see whether there is any prospect of a fix and I wouldn't hold my breath for a new shell as I don't think anyone has the time, expertise and inclination to do it. > Just a thought... I have no doubt that would be a pretty huge project. > OTOH, I'm not necessarily talking about a "from scratch" > implementation... it could largely be based on an existing shell. If it's based on an existing shell, then it isn't really a new shell. Personally, I'd like to see someone revive the OS/2 port of ASH, which is a fairly small implementation of sh without most of the bells and whistles in bash and ksh, but still usable for shell scripts which is my main concern. > It's just that by giving it a new name we could help avoid conflicts. I don't think the name matters too much if it works properly. You can always rename it as sh.exe. > It > would also perhaps make things easier on people writing multiplatform > apps on *nix... they could perhaps save a lot of work by ifdefing the > platform to OS/2 and declaring os2sh as the shell of choice on that > platform. > > Regards, > > Jack -- John **= Email 17 ==========================** Date: Tue, 12 Feb 2002 15:45:24 +0100 (MEZ) From: "MS" Subject: Re: GCC 3.0.2 problems On Tue, 12 Feb 2002 18:23:53 +0300, pla at cland.ru wrote: >You do not have EMX fix 09d4 developer (!) fix installed. 100% sure. Yeah, I did a fresh EMX installation for testing gcc 3.0.2 and did not pay attention that emxfix also includes updates headers / libs. Now it is installed, and even STLport is compiling and working! (Background: OpenOffice requires STLport, so I figured having the requirements first is the best way to start.) Thanks for the answer, there will be more questions... Martin Schafföner **= Email 18 ==========================** Date: Tue, 12 Feb 2002 16:30:46 +0000 From: John Poltorak Subject: Building SLANG Can anyone see if this batch file will build SLANG? :- (adjust paths to suit) set path=c:\usr\bin;c:\emx\bin;c:\usr\local\bin;c:\os2; set C_INCLUDE_PATH=u:/usr/include/ncurses;c:/emx/include set LIBRARY_PATH=c:/emx/lib; set CPLUS_INCLUDE_PATH=c:/emx/include;c:/emx/include/cpp set repository=c:\repository set workdir=c:\workdir set home=c:/home set CC=gcc set SHELL=c:/bin/sh md %repository% cd %repository% test -f slang-1.4.5.tar.gz || wget ftp://space.mit.edu/pub/davis/slang/v1.4/slang-1.4.5.tar.gz md %workdir% cd %workdir% tar zxf %repository%/slang-1.4.5.tar.gz cd slang-1.4.5 cd src setlocal md \tmpslang copy mkfiles\mkmake.exe \tmpslang copy mkfiles\makefile.all \tmpslang cd \tmpslang echo mkmake OS2 EMX ^< makefile.all ^>makefile > \tmpslang\slang.bat \tmpslang\slang.bat endlocal copy \tmpslang\makefile make It works here OK, although it does need to run a DOS batch file, so if you have PROTECTONLY=yes it won't work. -- John **= Email 19 ==========================** Date: Tue, 12 Feb 2002 18:23:53 +0300 From: pla at cland.ru Subject: Re: GCC 3.0.2 problems >On Sun, Feb 10, 2002 at 09:56:21PM +0100, MS wrote: >> Hello people, >> >> I have narrowed down the problem with building STLport on OS/2. STLport is including which in >> turn includes some other headers. I always get the errors: >> >> D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:59: `isalnum' not declared >> D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:60: `isalpha' not declared >> D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:61: `iscntrl' not declared >> D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:62: `isdigit' not declared >> D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:63: `isgraph' not declared >> D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:64: `islower' not declared >> D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:65: `isprint' not declared >> D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:66: `ispunct' not declared >> D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:67: `isspace' not declared >> D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:68: `isupper' not declared >> D:/DEVEL/C/EMX/include/g++-v3/bits/std_cctype.h:69: `isxdigit' not declared You do not have EMX fix 09d4 developer (!) fix installed. 100% sure. Bye! **= Email 20 ==========================** Date: Tue, 12 Feb 2002 20:03:25 +0000 From: John Poltorak Subject: Re: Multimedia headers On Tue, Feb 12, 2002 at 12:12:21PM +0100, Gerhard Arnecke wrote: > I've uploaded the file DETK45HE.ZIP to ftp://unixos2.com/incoming which includes the > header files of OS/2 WARP Developer's Toolkit 4.5 and the library MMPM2.LIB Thanks, I'm having a look now and find it very confusing... I'm trying to identify the files with a view to locating the original sources, but everything seems different to what I have. All the headers which are common to EMX/GCC are newer releases so I'd like to use these headers instead of the ones in EMX, assuming they are suitable replacements. BTW I have the IBM Developers Toolbox CD but finding the Warp Toolkit isn't easy among 100CDs. Any idea about which CD and filename I should look for? -- John **= Email 21 ==========================** Date: Tue, 12 Feb 2002 21:46:00 +0000 From: John Poltorak Subject: Re: Multimedia headers On Tue, Feb 12, 2002 at 10:00:28PM +0100, Holger Veit wrote: > On Tue, Feb 12, 2002 at 08:03:25PM +0000, John Poltorak wrote: > [...] > > BTW I have the IBM Developers Toolbox CD but finding the Warp Toolkit > > isn't easy among 100CDs. Any idea about which CD and filename I should > > look for? > > The best source for now is one of the eCS or Software Choice MCP/ACP > CDs. OK, I found it now on eCS 3 \IBMMISC\DEVTOOLKIT\TOOLKIT.ZIP. This confuses me no end... Now there is such a great overlap between the IBM supplied headers and those in EMX. What to do? Are the ones in the toolkit usable by EMX/GCC ? One thing I hate about IBM's packaging is their total disregard for file datestamps. The same file can appear in a hundred places and each one bears a different datestamp. I guess we are free to distribute any of the headers which don't contain an IBM copyright... > Holger > > -- > Please update your tables to my new e-mail address: > holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) > -- John **= Email 22 ==========================** Date: Tue, 12 Feb 2002 22:00:28 +0100 From: Holger Veit Subject: Re: Multimedia headers On Tue, Feb 12, 2002 at 08:03:25PM +0000, John Poltorak wrote: [...] > BTW I have the IBM Developers Toolbox CD but finding the Warp Toolkit > isn't easy among 100CDs. Any idea about which CD and filename I should > look for? The best source for now is one of the eCS or Software Choice MCP/ACP CDs. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 23 ==========================** Date: Tue, 12 Feb 2002 23:37:45 +0100 From: Thomas Hoffmann Subject: cat.exe fails for long command lines whe called from unix-like shell When I try to execute a concatenation with a "long" command line, calling cat when working under a unix-like shell, it barfs with: [1|zappa|~/work/R/rwork141/src/library/base]cat .../../../../../../../tmp/ctt/1234567890/1234567890/*.Rd >nul bash.exe: Execution failed because of module "Dˇĺ" bash.exe: g:/BIN/cat.exe: No such file or directory or (ash.exe): # cat ../../../../../../../tmp/ctt/1234567890/1234567890/*.Rd >nul cat: No such file or directory ksh.exe fails with a similar message. When calling the same command through cmd.exe, everything works fine. I suspect this has something to do with the cmd line expansion by unix type shells, wheras cmd.exe gives the cmd line "as is" to cat.exe. To give an estimation of the size of the expanded cmd line: the threshold for "stopping to work" is at approx. 500 *.Rd files, each 10...20 chars long, which gives w/ the longish path above ca. 32000 chars: does that ring a bell? Could one do anything about this without touching the src of the shells? (extending the stack size, e.g.) Regards, Thomas. -- Thomas Hoffmann Telephone: 49-351-4598831 thoffman at zappa.sax.de Dresden, Germany ..sig under construction ...