From: UnixOS2 Archive To: "UnixOS2 Archive" Date: Wed, 13 Feb 2002 04:15:13 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 134 ************************************************** Tuesday 12 February 2002 Number 134 ************************************************** Subjects for today 1 Re: Shell troubles : Andreas Buening 2 Re: Make 3.79.1 : Andreas Buening 3 Re: cat.exe fails for long command lines whe called from unix-like shell : Jerrold Heyman 4 Re: Shell startup file : Charles R. Hunter" 5 Re: Shell troubles : John Poltorak 6 Re: cat.exe fails for long command lines whe called from unix-like shell : John Poltorak 7 Re: Shell troubles : John Poltorak 8 Re: Shell troubles : csaba.raduly at sophos.com 9 Re: Shell troubles : John Poltorak 10 Re: Shell troubles : John Poltorak 11 Re: cat.exe fails for long command lines whe called from unix-like shell : Stefan Neis 12 Re: Multimedia headers : Holger Veit 13 Re: cat.exe fails for long command lines whe called from unix-like shell : Holger Veit 14 Shell startup file : John Poltorak 15 Re: IBM OS/2 Developer's Toolkit 4.5 : Gerhard Arnecke" 16 Re: IBM OS/2 Developer's Toolkit 4.5 : John Poltorak 17 Re: Shell startup file : John Poltorak 18 Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS : Gerhard Arnecke" 19 Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS : Holger Veit 20 Re: cat.exe fails for long command lines whe called from unix-like shell : Holger Veit 21 arpa headers : John Poltorak 22 Re: Shell troubles : Alex Newman" 23 Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS : Gerhard Arnecke" 24 Re: arpa headers : Holger Veit 25 Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS : Gerhard Arnecke" 26 Re: Shells... : Nicholas Sheppard 27 Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS : Stepan Kazakov 28 Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS : Stepan Kazakov **= Email 1 ==========================** Date: Wed, 13 Feb 2002 00:16:40 +0100 From: Andreas Buening Subject: Re: Shell troubles John Poltorak wrote: > > On Tue, Feb 12, 2002 at 10:01:05AM +0000, csaba.raduly at sophos.com wrote: [snip] > > 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... This seems to be a feature (not a bug) of ksh only. bash can handle '\' in $PATH (tested on Linux). However, "\b" is only interpreted as backspace if you "echo" your PATH. Internally the '\' is preserved. > > 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/\\\\/\\//"` It depends on which shell you're using how many backslashes you need. [DISCLAIMER] 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 2 ==========================** Date: Wed, 13 Feb 2002 00:17:36 +0100 From: Andreas Buening Subject: Re: Make 3.79.1 John Poltorak wrote: > > Just wondering if any progress has been made with Make 3.79.1... > > Andreas has gone very quiet since he asked about the location of the > latest ported source. Don't know if this is a good or a bad sign. It means that I haven't had enough time. But to answer your question: I've started with the original make 3.79.1 source and the current status is: - SHELL=/bin/sh seems to work (make can compile itself) - default shell cmd implemented and seems to work, too - command.com for DOS mode implemented but not tested - REXX support not built in - configuration files just fixed not yet done: - determine system load for -j switch (is there any getloadavg() ?) - file system handling (how many FAT do we need?) - make's internal hash table: having inodes would be nice - intensive tests 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: Wed, 13 Feb 2002 08:08:39 -0600 (CST) From: Jerrold Heyman Subject: Re: cat.exe fails for long command lines whe called from unix-like shell On 13 February 2002 at 11:53, Holger Veit wrote: >On Wed, Feb 13, 2002 at 11:16:10AM +0100, Stefan Neis wrote: >> On Tue, Feb 12, 2002 at 11:37:45PM +0100, Thomas Hoffmann wrote: >>> >>> # cat ../../../../../../../tmp/ctt/1234567890/1234567890/*.Rd >nul >>> cat: No such file or directory >>> >>> ksh.exe fails with a similar message. >>> >>> 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: >> >> Did anybody try something similar on a Unix system? I suppose those >> shells might all use a static buffer for commandline expansion which >> would mean there is a built-in upper limit for its length. 32000 sounds >> like it might just be that limit... >> >> I don't think it's an EMX problem, since if it was, I don't think cat >> itself (when called from cmd) could expand it properly. > > It is an OS/2 limitation: DosExecPgm uses a combined 16 bit segment for > both the environment strings as well as the argument vector. The sum > mustn't exceed 64K. This is one reason why I don't like adding bazillions > of environment variables to CONFIG.SYS (%UNIXROOT% must be enough), they > reduce the available space for arguments. ...Thinking about this a bit > more, it should be possible to inject the environment vector in a different > way - you could call DosExecPgm with a NULL for the env argument, so not to > inherit ENV from the parent - this is OTOH no problem, because I tap the > DosExecPgm API anyway, so I can feed the program anything I like it to see... > Hmmm, so this should work. But the limit for the argv vector =64K remains > for now. > > Holger This problem doesn't just exist on OS/2. I support the Cygnus tools on NT (along with EMX on OS/2) for internal development, and have run across the same problem concerning large path names. After debugging for a while, we came to the conclusion that it was an NT filesystem/pathname length issue. In our case it was the cp command that was failing - even though if I did the equivalent command within a DOS prompt, it worked just fine... jerry Jerry Heyman 919.224.1442 | IBM SWG/Tivoli Software |"Software is the Build Infrastructure Architect| 3901 S Miami Blvd | difference between jheyman at dev.tivoli.com | RTP, NC 27709 | hardware and reality" http://www.acm.org/~heymanj **= Email 4 ==========================** Date: Wed, 13 Feb 2002 08:26:45 -0500 From: "Charles R. Hunter" Subject: Re: Shell startup file On Wed, Feb 13, 2002 at 01:07:29PM +0000, John Poltorak (jp at eyup.org) wrote: > > Does anyone know what global startup file is used with SH from PDKSH? > > I know that $HOME/kshrc.ksh is used as the user specific file. > > Also, should this file be used when running shells scripts? I find that it > doesn't, but maybe I'm doing something wrong... It is used if I start a > shell and go to a shell prompt, but if I run a shell script from the > command line, the startup file seems to be ignored. That is the correct behavior. startup scripts ( and global ones ) are only used in login shells. Some sheels differentiate between this like bash and tcsh. ( .login is only sourced on login, while .tcshrc is sourced on any exec of shell ) but IIRC none of them are sourced when called from #!/usr/local/bin/tcsh Charles > > > -- > John > -- Charles R. Hunter Director, Physics Computer Network Purdue University crh at physics.purdue.edu **= Email 5 ==========================** Date: Wed, 13 Feb 2002 09:06:29 +0000 From: John Poltorak Subject: Re: Shell troubles 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. > bash can handle > '\' in $PATH (tested on Linux). However, "\b" is only interpreted as > backspace if you "echo" your PATH. Internally the '\' is preserved. But if you want to convert '\' to '/' don't you need to use 'echo' ? > 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: Wed, 13 Feb 2002 09:16:56 +0000 From: John Poltorak Subject: Re: cat.exe fails for long command lines whe called from unix-like shell On Tue, Feb 12, 2002 at 11:37:45PM +0100, Thomas Hoffmann wrote: > > # 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: Is there an easy way to reproduce this behaviour? > does that ring a bell? > > Could one do anything about this without touching the src of the shells? > (extending the stack size, e.g.) Maybe it's an EMXRT constraint... > Regards, > Thomas. > > -- > Thomas Hoffmann Telephone: > 49-351-4598831 > thoffman at zappa.sax.de Dresden, > Germany > > ..sig under construction ... -- John **= Email 7 ==========================** Date: Wed, 13 Feb 2002 09:43:17 +0000 From: John Poltorak Subject: Re: Shell troubles On Wed, Feb 13, 2002 at 05:57:59PM +1100, Alex Newman wrote: > This \b-in-the-path thingy is driving me nuts. At least I know now > what's doing it! > > There was a rexx script (ChangeSlash.cmd) in a recent readline or > gettext release that purported to be able to change the \-es to > /-es...except that sh (alias (pd)ksh) choked on the \b (\ba2pro) before > the script could switch 'em around. It appears that a solution is available using the '-E' option to echo.exe:- C:\usr\bin>echo.exe --help Usage: C:\usr\bin\echo.exe [OPTION]... [STRING]... Echo the STRING(s) to standard output. -n do not output the trailing newline -e enable interpretation of the backslash-escaped characters listed below -E disable interpretation of those sequences in STRINGs --help display this help and exit (should be alone) --version output version information and exit (should be alone) Without -E, the following sequences are recognized and interpolated: \NNN the character whose ASCII code is NNN (octal) \\ backslash \a alert (BEL) \b backspace \c suppress trailing newline \f form feed \n new line \r carriage return \t horizontal tab \v vertical tab Report bugs to . > Cheers, > > Alex. > -- John **= Email 8 ==========================** Date: Wed, 13 Feb 2002 09:57:47 +0000 From: csaba.raduly at sophos.com Subject: Re: Shell troubles On 13/02/2002 09:06:29 owner-os2-unix 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. > He may in fact be right :-) Remember, backslash is only used for escaping and special characters on *ix. If \b, \t and suchlike are not expanded, it becomes inconvenient when you need those control characters. It's unlucky that OS/2 uses backslashes as the path separator :-) The shell could substitute \ for / in PATH however (at startup) -- 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 9 ==========================** Date: Wed, 13 Feb 2002 10:13:08 +0000 From: John Poltorak Subject: Re: Shell troubles On Wed, Feb 13, 2002 at 09:57:47AM +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. > > > > He may in fact be right :-) Possibly so... > Remember, backslash is only used for escaping and special characters > on *ix. If \b, \t and suchlike are not expanded, it becomes inconvenient > when you need those control characters. > > It's unlucky that OS/2 uses backslashes as the path separator :-) The escaping can be controlled by the use of '-e' and'-E' options in echo, as I have just discovered. I'd prefer '-E' to be the default on OS/2... > The shell could substitute \ for / in PATH however (at startup) How? That's what I was trying to do but it didn't work. Maybe defining the function 'echo' in kshrc.ksh will do the trick... > > -- > 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 10 ==========================** Date: Wed, 13 Feb 2002 11:11:58 +0000 From: John Poltorak Subject: Re: Shell troubles On Wed, Feb 13, 2002 at 09:57:47AM +0000, csaba.raduly at sophos.com wrote: > The shell could substitute \ for / in PATH however (at startup) I've got it working now with this line in my SH startup file:- export PATH=`echo -E $PATH |tr '\\\\' '/'` The startup file used is $HOME/kshrc.ksh which is user specific, so I'd prefer to use %ETC% but can't get it working from there. Maybe it uses a different filename there... According to the man page it should use /etc/profile or $HOME/.profile, but neither seem to work. > > -- > 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 11 ==========================** Date: Wed, 13 Feb 2002 11:16:10 +0100 (CET) From: Stefan Neis Subject: Re: cat.exe fails for long command lines whe called from unix-like shell On Tue, Feb 12, 2002 at 11:37:45PM +0100, Thomas Hoffmann wrote: > > # cat ../../../../../../../tmp/ctt/1234567890/1234567890/*.Rd >nul > cat: No such file or directory > > ksh.exe fails with a similar message. > > 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: Did anybody try something similar on a Unix system? I suppose those shells might all use a static buffer for commandline expansion which would mean there is a built-in upper limit for its length. 32000 sounds like it might just be that limit... I don't think it's an EMX problem, since if it was, I don't think cat itself (when called from cmd) could expand it properly. BTW, the "obvious" UNIX-like work-around would be to use find like in "find ../../../../../../../tmp/ctt/1234567890/1234567890/ -name '*.Rd' -exec cat \{} >nul \; " Regards, Stefan -- Micro$oft is not an answer. It is a question. The answer is 'no'. **= Email 12 ==========================** Date: Wed, 13 Feb 2002 11:45:32 +0100 From: Holger Veit Subject: Re: Multimedia headers On Tue, Feb 12, 2002 at 09:46:00PM +0000, John Poltorak wrote: > 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: [...] > > 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 ? (almost) both directions: it is possible to use the TK headers in EMX; there should be instructions in the EMX docs how to add them to EMX, and you could also lift os2emx.h to a non-EMX development environment (like LIBEMU - it shouldn't be too difficult to offer both features to LIBEMU). The drawback with os2emx.h is that it is rather outdated, and does not contain the more elaborated features of the TK, e.g. MMPM, WPS, and recent TCPIP headers. The latter could be a problem, since with TCPIP32.DLL available I intend to take advantage of it, of course. The TK tools, docs, and examples are either available from elsewhere or are not really needed unless you are working at the bleeding edge. > 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... Almost all headers do, unfortunately. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 13 ==========================** Date: Wed, 13 Feb 2002 11:53:32 +0100 From: Holger Veit Subject: Re: cat.exe fails for long command lines whe called from unix-like shell On Wed, Feb 13, 2002 at 11:16:10AM +0100, Stefan Neis wrote: > On Tue, Feb 12, 2002 at 11:37:45PM +0100, Thomas Hoffmann wrote: > > > > # cat ../../../../../../../tmp/ctt/1234567890/1234567890/*.Rd >nul > > cat: No such file or directory > > > > ksh.exe fails with a similar message. > > > > 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: > > Did anybody try something similar on a Unix system? I suppose those > shells might all use a static buffer for commandline expansion which > would mean there is a built-in upper limit for its length. 32000 sounds > like it might just be that limit... > > I don't think it's an EMX problem, since if it was, I don't think cat > itself (when called from cmd) could expand it properly. It is an OS/2 limitation: DosExecPgm uses a combined 16 bit segment for both the environment strings as well as the argument vector. The sum mustn't exceed 64K. This is one reason why I don't like adding bazillions of environment variables to CONFIG.SYS (%UNIXROOT% must be enough), they reduce the available space for arguments. ...Thinking about this a bit more, it should be possible to inject the environment vector in a different way - you could call DosExecPgm with a NULL for the env argument, so not to inherit ENV from the parent - this is OTOH no problem, because I tap the DosExecPgm API anyway, so I can feed the program anything I like it to see... Hmmm, so this should work. But the limit for the argv vector =64K remains for now. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 14 ==========================** Date: Wed, 13 Feb 2002 13:07:29 +0000 From: John Poltorak Subject: Shell startup file Does anyone know what global startup file is used with SH from PDKSH? I know that $HOME/kshrc.ksh is used as the user specific file. Also, should this file be used when running shells scripts? I find that it doesn't, but maybe I'm doing something wrong... It is used if I start a shell and go to a shell prompt, but if I run a shell script from the command line, the startup file seems to be ignored. -- John **= Email 15 ==========================** Date: Wed, 13 Feb 2002 13:44:48 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: IBM OS/2 Developer's Toolkit 4.5 John, you can find the wanted Toolkit v4.5 on CD P59. You can find the Developer's Toolkit for OS/2 Warp 4.0 (Merlin) on CD P10. You can find the Developer's Toolkit for OS/2 Warp 4.0 Update(CSD4) on CD P11. Isuppose you have subscribed the professional level. **= Email 16 ==========================** Date: Wed, 13 Feb 2002 13:56:34 +0000 From: John Poltorak Subject: Re: IBM OS/2 Developer's Toolkit 4.5 On Wed, Feb 13, 2002 at 01:44:48PM +0100, Gerhard Arnecke wrote: > John, > > you can find the wanted Toolkit v4.5 on CD P59. Got it, thanks. What I'd like to do is compare the files in the h\arpa directory against those in FreeBSD, but I can't locate them. I can find them in GLIBC easily enough, but interestingly condition 3 of Redistribution is ommitted from the GLIBC version. > Isuppose you have subscribed the professional level. I got the Member level originally but I think it got merged into the professional level. -- John **= Email 17 ==========================** Date: Wed, 13 Feb 2002 14:55:12 +0000 From: John Poltorak Subject: Re: Shell startup file On Wed, Feb 13, 2002 at 08:26:45AM -0500, Charles R. Hunter wrote: > On Wed, Feb 13, 2002 at 01:07:29PM +0000, John Poltorak (jp at eyup.org) wrote: > > Also, should this file be used when running shells scripts? I find that it > > doesn't, but maybe I'm doing something wrong... It is used if I start a > > shell and go to a shell prompt, but if I run a shell script from the > > command line, the startup file seems to be ignored. > > > That is the correct behavior. startup scripts ( > and global ones ) are only used in login shells. > Some sheels differentiate between this like bash and tcsh. > ( .login is only sourced on login, while .tcshrc is sourced on any > exec of shell ) but IIRC none of them are sourced when called from > #!/usr/local/bin/tcsh 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'? > > Charles > -- > Charles R. Hunter > Director, Physics Computer Network > Purdue University crh at physics.purdue.edu -- John **= Email 18 ==========================** Date: Wed, 13 Feb 2002 15:06:09 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS Is there any interest in 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? GA **= Email 19 ==========================** Date: Wed, 13 Feb 2002 16:16:04 +0100 From: Holger Veit Subject: Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS On Wed, Feb 13, 2002 at 03:06:09PM +0100, Gerhard Arnecke wrote: > Is there any interest in > > 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? Me Too Unless unixos2.com has some place, send them to me (holger.veit at ais.fhg.de) attached to a mail (I accept LAAAAAAAARGE files). I'll put them here to some FTP server directory. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 20 ==========================** Date: Wed, 13 Feb 2002 16:25:55 +0100 From: Holger Veit Subject: Re: cat.exe fails for long command lines whe called from unix-like shell On Wed, Feb 13, 2002 at 08:08:39AM -0600, Jerrold Heyman wrote: > On 13 February 2002 at 11:53, Holger Veit wrote: > >On Wed, Feb 13, 2002 at 11:16:10AM +0100, Stefan Neis wrote: > >> On Tue, Feb 12, 2002 at 11:37:45PM +0100, Thomas Hoffmann wrote: > >>> > >>> # cat ../../../../../../../tmp/ctt/1234567890/1234567890/*.Rd >nul > >>> cat: No such file or directory [...] > > It is an OS/2 limitation: DosExecPgm uses a combined 16 bit segment for > > both the environment strings as well as the argument vector. The sum > > mustn't exceed 64K. This is one reason why I don't like adding bazillions > > of environment variables to CONFIG.SYS (%UNIXROOT% must be enough), they > > reduce the available space for arguments. ...Thinking about this a bit > > more, it should be possible to inject the environment vector in a different > > way - you could call DosExecPgm with a NULL for the env argument, so not to > > inherit ENV from the parent - this is OTOH no problem, because I tap the > > DosExecPgm API anyway, so I can feed the program anything I like it to see... > > Hmmm, so this should work. But the limit for the argv vector =64K remains > > for now. > > > > Holger > > This problem doesn't just exist on OS/2. I support the Cygnus tools on NT > (along with EMX on OS/2) for internal development, and have run across the > same problem concerning large path names. After debugging for a while, > we came to the conclusion that it was an NT filesystem/pathname length > issue. > > In our case it was the cp command that was failing - even though if I did > the equivalent command within a DOS prompt, it worked just fine... filesystem/pathname length is a different issue than the problem above. It is clear that ../../../../../../../tmp/ctt/1234567890/1234567890/*.Rd is a pathological name which *might* result in a fully decoded name longer than 260 chars depending on what it resolved to (and symbolic links might add more to the whole confusion. It is not a file system issue as well, because the filesystem won't see the argv vector; it is passed one decoded filename after the other, and should allow access to any number of files by a process unless the maximum number of open files per process is exhausted (DosQuery/SetMaxFH). The culprit is the wildcard expansion of the shell which constructs an extremely lengthy argv vector. Doing _wildargs() expansion in the program itself, as suggested for DOS/OS2 apps, will in contrast work here, but is of course not Unix compatible. Unix typically does not have a 16 bit limit on argv and envp. That issue (restrictions on DosExecPgm) is hard to fix completely, because the code behind that, in DOSCALL1.DLL and OS2KRNL is extremely scattered with 16 bit calls which don't like segments > 64K. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 21 ==========================** Date: Wed, 13 Feb 2002 16:43:57 +0000 From: John Poltorak Subject: arpa headers On the face of it I should be able to replace the headers in EMX using the ones in BSD here:- ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/include/arpa/ Of these ftp.h and telnet.h look like drop in replacements. tftp.h is missing from EMX. Is there any reason to exclude it now? The other files have '#include's for sys/types.h sys/cdefs.h machine/endian.h machine/ansi.h There is no ansi.h in EMX, but the others do exist. Should we be aiming at getting in line with FreeBSD? -- John **= Email 22 ==========================** Date: Wed, 13 Feb 2002 17:57:59 +1100 (EDT) From: "Alex Newman" Subject: Re: Shell troubles This \b-in-the-path thingy is driving me nuts. At least I know now what's doing it! There was a rexx script (ChangeSlash.cmd) in a recent readline or gettext release that purported to be able to change the \-es to /-es...except that sh (alias (pd)ksh) choked on the \b (\ba2pro) before the script could switch 'em around. A suitably pruned version of the rexx script happily switched things about in YAOS. I guess the only way around this is to start the shell itself from a cmd file, and set the path without any "\b[...];" entries (nothing useful wrt compiling things uses path-dirs starting with b anyway). Or run ChangeSlash.cmd from said startup file... Interestingly, YAOS (1.81 on this system) understands /-es in paths, maybe I'll play around with putting c-slash.cmd in the cmd file that starts YAOS (in a decent sized window). On Tue, 12 Feb 2002 10:21:31 +0000, John Poltorak wrote: > 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... Cheers, Alex. **= Email 23 ==========================** Date: Wed, 13 Feb 2002 18:03:38 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS Please help me. In which file of these one can find map files for AFOS2.SYS, SOCKETS.SYS and SOCKETSK.SYS: ic32579.zip 114,929 1/22/2002[02:30:38] IBM Testcase replacement Telnet. ic32777.zip 104,475 2/5/2002[13:41:46] IBM Testcase replacement DHCPCD.EXE ic32802.zip 621,741 2/8/2002[17:39:24] IBM Testcase files for TCP/IP v4.32 ic32802new.zip 621,744 2/12/2002[16:04:06] IBM Testcase files for TCP/IP v4.32 pmr21559-2.zip 513,217 2/5/2002[17:52:12] Replacement SYS files for TCP/IP v4.32 **= Email 24 ==========================** Date: Wed, 13 Feb 2002 18:08:58 +0100 From: Holger Veit Subject: Re: arpa headers On Wed, Feb 13, 2002 at 04:43:57PM +0000, John Poltorak wrote: > On the face of it I should be able to replace the headers in EMX using the > ones in BSD here:- > > ftp://ftp.freebsd.org/pub/FreeBSD/FreeBSD-current/src/include/arpa/ > > Of these ftp.h and telnet.h look like drop in replacements. Yes. They are however not really useful unless you really want to write telnet or ftp daemons or clients. They are IMHO relics from the time the internet was called Arpanet. > tftp.h is missing from EMX. Is there any reason to exclude it now? No reason, but the same as for ftp.h and telnet.h applies: what will adding them give you? > The other files have '#include's for > > sys/types.h > sys/cdefs.h > machine/endian.h > machine/ansi.h > > There is no ansi.h in EMX, but the others do exist. > > Should we be aiming at getting in line with FreeBSD? It is probably not worth the trouble trying to slowly migrate EMX towards BSD/LIBEMU. Adding some headers like the above ones does not solve any problem for normal app porting. Besides, is a rather critical header file, as well as some of the machine headers. You should better not mess with them, unless you are absolutely sure what is in there (and that their content is compatible with EMX - this is the big problem with POSIX/2 and sockets, n'est pas, Stefan :-)?). You're going break EMX itself quite easily. Holger -- Please update your tables to my new e-mail address: holger.veit$ais.fhg.de (replace the '$' with ' at ' -- spam-protection) **= Email 25 ==========================** Date: Wed, 13 Feb 2002 19:18:17 +0100 (MEZ) From: "Gerhard Arnecke" Subject: Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS IDA for Sym files. This is for disassembling, isn't it? Map files are derived from the source with original addresses. But there are several types of MAP files. And here I mean MAP files with special options and lists. So one can work with different goals with these files. And one can use for automatic error finding with some TRACE routines only with MAP files. **= Email 26 ==========================** Date: Wed, 13 Feb 2002 21:18:12 +1000 (EST) From: Nicholas Sheppard Subject: Re: Shells... On Tue, 12 Feb 2002, Jack Troughton wrote: > 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 probably isn't quite what you/we want, but... A few years ago I started a project to write a shell from the ground up that was a bit of an experiment in configurability and portability. The aim was to have a config.h that had all the shell special characters #defined in it so that you could decide whether or not you wanted forward or backward slashes for directory separators, etc., as well as change the names of the built-in commands, and things like whether or not the shell did globbing. The reason I say it probably isn't quite what you want is that I designed it as a CMD-like shell; ultimately the aim was to add some of the nice features of Unix shells like filename completion to the usual OS/2 type environment. So, if I ever reached my goal of making it portable to Unix, it would probably be the opposite of what you want here: a Unix shell that ran OS/2 scripts. It fell by the wayside after a while; I think I realised/decided that I'd bitten off more than I could chew or something. It could do a few simple things like run programmes, show directories, etc., but I never got around to more sophisticated features like control structures and pipes, and it's not particularly reliable at doing even the things it does do. Every now and again I think of resurrecting it but I've never quite had the time/energy. Personally, I don't have any particular interest in running Unix scripts on my OS/2 machine, but I think Jack is probably right. Massage OS/2 and #ifdefs all you like, it's still OS/2 and something as close to the system as a shell has to recognise that somewhere along the line. OS/2 isn't a buggy version of Unix, it's a different OS altogether and needs to be treated as such in matters like what a PATH variable looks like, what ".EXE" means, etc. Anyway, that's a bit of a ramble, make of it what you will. Nik S. **= Email 27 ==========================** Date: Wed, 13 Feb 2002 21:57:28 -0500 From: Stepan Kazakov Subject: Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS Gerhard Arnecke wrote: > Please help me. In which file of these one can find map files for AFOS2.SYS, > SOCKETS.SYS and SOCKETSK.SYS: first of all - .map files not interesting. only .sym is good :) IDA working with .sym-s very good. > ic32802new.zip 621,744 2/12/2002[16:04:06] IBM Testcase files for TCP/IP v4.32 this is only you need. Archive: ic32802new.zip Length EAs ACLs Date Time Name ------ --- ---- ---- ---- ---- 319488 72 0 12-02-02 16:41 afinet.sys 318464 72 0 12-02-02 16:41 afinetk.sys 219136 72 0 12-02-02 16:40 aflean.sys 777 0 0 12-02-02 17:04 readme.txt 120320 72 0 30-01-02 17:11 sockets.sys 128512 72 0 30-01-02 17:11 socketsk.sys 0 0 0 12-02-02 17:01 sym/ 19844 0 0 12-02-02 16:41 sym/afinet.sym 19892 0 0 12-02-02 16:41 sym/afinetk.sym 16100 0 0 12-02-02 16:41 sym/aflean.sym 11220 0 0 30-01-02 17:11 sym/sockets.sym 12100 0 0 30-01-02 17:11 sym/socketsk.sym ------ ----- ----- ------- 1185853 360 0 12 files and remember, only 4.3 stack now supported by IBM, all fixes only for 4.3.. the latest 4.3 stack - in acp2. -- madded. [Red Hot Chili Hackers] **= Email 28 ==========================** Date: Wed, 13 Feb 2002 23:02:10 -0500 From: Stepan Kazakov Subject: Re: files for AFOS2.SYS,SOCKETS.SYS and SOCKETSK.SYS Gerhard Arnecke wrote: > IDA for Sym files. This is for disassembling, isn't it? yep :) > Map files are derived from the source with original addresses. But there are several > types of MAP files. And here I mean MAP files with special options and lists. aha > So one can work with different goals with these files. And one can use for automatic error > finding with some TRACE routines only with MAP files. hmm. afaik trapdump utils supports SYM & kernel debugger too. or you are speaking about some other kind of TRACEing ? -- madded. [Red Hot Chili Hackers]