Date: Sat, 20 Dec 2003 00:04:03 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600 Subject: [UnixOS2_Archive] No. 274 ************************************************** Friday 19 December 2003 Number 274 ************************************************** Subjects for today 1 Re: Strange cmd.exe behaviour (was: Make bugs?) : Stefan Neis 2 Re: Strange cmd.exe behaviour (was: Make bugs?) : Andreas Buening 3 Re: Strange cmd.exe behaviour (was: Make bugs?) : Andreas Buening 4 Re: Strange cmd.exe behaviour (was: Make bugs?) : Dave and Natalie" **= Email 1 ==========================** Date: Thu, 18 Dec 2003 14:20:38 +0100 (CET) From: Stefan Neis Subject: Re: Strange cmd.exe behaviour (was: Make bugs?) > Btw, is there any documentation of how cmd processes strings? AFAIK, it just doesn't process them at all, the only relevant thing should be that "foo bar" is treated as one single string (length 9), same as "foo bar (length 8), AFAICS. Spaces after an even number of quotes are treated as separating strings... > c:\bin\echo.exe .\"foo bar" gives ."foo bar That's \bin\echo.exe doing the processing (maybe EMX's _wildcard()?). > echo .\"foo bar" gives .\"foo bar" > dir .\"foo bar" shows directory 'foo bar' Use them "as is", as expected (with dir ignoring the quotes, as these are "optional" in file names and only used to "escape" spaces. BTW, dir .\foo" "bar or dir ".\foo bar" do the same). > ls.exe .\"foo bar" complains > ls.exe: ."foo: No such file or directory > ls.exe: bar: No such file or directory ls.exe doing processing (_wildcard()?). > Is there a phisosophy behind this? Yes: Let the program itself decide what it wants to do with it's arguments instead of passing "garbled" stuff to it. Most Unix programs (when ported to OS/2) call things like _wildcard at the beginning to "emulate" the missing expansion of the shell (just imagine "grep something *" looking only into a file named '*'), but "native" programs don't do such expansions. To be honest, I didn't realise that this is not only relevant for wildcard expansion, but also for quoting, however I don't think it's very surprising ... > And, is this behavour th > same on all OS/2 versions? AFAIK, yes. Even WinNT's cmd.exe behaves "mostly identical". Regards, Stefan **= Email 2 ==========================** Date: Thu, 18 Dec 2003 14:54:23 +0100 From: Andreas Buening Subject: Re: Strange cmd.exe behaviour (was: Make bugs?) Stefan Neis wrote: > > > Btw, is there any documentation of how cmd processes strings? > > AFAIK, it just doesn't process them at all, the only relevant thing > should be that "foo bar" is treated as one single string (length 9), > same as "foo bar (length 8), AFAICS. Spaces after an even number of > quotes are treated as separating strings... Hmm. > > c:\bin\echo.exe .\"foo bar" gives ."foo bar > > That's \bin\echo.exe doing the processing (maybe EMX's _wildcard()?). No, this has nothing to do with _wildcard(). I've just written a {for(i=0;i > echo .\"foo bar" gives .\"foo bar" > > dir .\"foo bar" shows directory 'foo bar' > > Use them "as is", as expected (with dir ignoring the quotes, as these > are "optional" in file names and only used to "escape" spaces. BTW, > dir .\foo" "bar or dir ".\foo bar" do the same). This is what I would expect. > > ls.exe .\"foo bar" complains > > ls.exe: ."foo: No such file or directory > > ls.exe: bar: No such file or directory > > ls.exe doing processing (_wildcard()?). > > > Is there a phisosophy behind this? > > Yes: Let the program itself decide what it wants to do with it's > arguments instead of passing "garbled" stuff to it. Most Unix programs > (when ported to OS/2) call things like _wildcard at the beginning to > "emulate" the missing expansion of the shell (just imagine > "grep something *" looking only into a file named '*'), but "native" > programs don't do such expansions. > > To be honest, I didn't realise that this is not only relevant for > wildcard expansion, but also for quoting, however I don't think it's > very surprising ... Then, please enter 'c:\bin\echo.exe "Helll\bo, World\a!"' (without the single quotes but with the full filename of echo.exe) and enjoy. And then imagine what happens if anybody tries to open a file \bin\some_file. It just doesn't exist because this string is translated to '^Hin\some_file' which obviously is an illegal name. > > And, is this behavour th > > same on all OS/2 versions? > > AFAIK, yes. Even WinNT's cmd.exe behaves "mostly identical". This doesn't really make me feel better. Bye, Andreas **= Email 3 ==========================** Date: Thu, 18 Dec 2003 15:17:00 +0100 From: Andreas Buening Subject: Re: Strange cmd.exe behaviour (was: Make bugs?) Andreas Buening wrote: > > Then, please enter 'c:\bin\echo.exe "Helll\bo, World\a!"' > (without the single quotes but with the full filename of echo.exe) > and enjoy. And then imagine what happens if anybody tries to open > a file \bin\some_file. It just doesn't exist because this string > is translated to '^Hin\some_file' which obviously is an illegal name. Sorry, ignore that. That's just an feature of echo. :-( But if EMX interprets \" combinations then copy \"some where"\file . and cp \"some where"\file . is something completely different. The latter is identical (in sh notation) cp '"some' 'where\file' . This is absolutely unexpected if I use cmd. Bye, Andreas **= Email 4 ==========================** Date: Thu, 18 Dec 2003 23:37:35 -0800 From: "Dave and Natalie" Subject: Re: Strange cmd.exe behaviour (was: Make bugs?) On Thu, 18 Dec 2003 12:11:11 +0100, Andreas Buening wrote: >Okay, that shouldn't be. >Another question: Do you think >sed "s/%/\""/g..." >is correctly quoted? There seems to be an unmatched double quote. It seems correctly quoted to me, 4 double quotes, 2 in the middle and one at each end. The command does work if entered on a command line (as one line, removing the backslashes. same error in makefile even if given as one line) >Btw, is there any documentation of how cmd processes strings? I don't know. There is a little in the OS/2 Warp Command Reference, eg echo, cmd. but not much. > >c:\bin\echo.exe .\"foo bar" gives ."foo bar >echo .\"foo bar" gives .\"foo bar" >dir .\"foo bar" shows directory 'foo bar' >ls.exe .\"foo bar" complains >ls.exe: ."foo: No such file or directory >ls.exe: bar: No such file or directory > >The builtin "echo" command seems to print a line as is: >(" -> ", \" -> \") >Other builtin commands like "dir" remove double quotes and >ignore backslash-escaped quotes like \": >(" -> , \" -> \") >For external commands double quotes are removed and backslash- >escaped quotes are supported: >(" -> , \" -> ") > >Is there a phisosophy behind this? And, is this behavour the >same on all OS/2 versions? Tried it with the cmd.exe from OS/2 ver 2.1, gave the same error. Out of curiousity tried using 4os2 as the command shell, it complained about char #10 instead of char #11. I can't really follow the sed command and at first thought it was related to the uppercase bug, maybe uppercasing some punctuation. Really the author should of used sh as the shell then he wouldn't have to wrote that hack. Still it is strange that it works on the command line or in old makes. Dave New Email Address - please update your Address book dave_yeo at paralynx.com