OpenEuphoria

1. command_line() bug in ex.exe 2.4

• Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 02, 2004
• 466 views
• Last edited Nov 03, 2004

Hello Rob, hello all,

I ran the following small test program on Windows 98:

-- program 'cmd.ex'
constant CMD = command_line()
for i = 3 to length(CMD) do
   puts(1, "-" & CMD[i] & "-\n")
end for
if getc(0) then end if

a) When calling it like this:
      exw.exe cmd.ex "c:\long dirname\"
   it displays, as I expected:
      -c:\long dirname\-

b) But when calling it like this:
      ex.exe cmd.ex "c:\long dirname\"
   it displays:
      -c:\long dirname"-

   It might look as if the backslash acts as an escape character here.
   But I think this isn't true, because in that case the first backslash
   should cause an error. Also, this should be consistent on all
   supported platforms IMHO.
   Calling
      ex.exe cmd.ex "c:\long dirname\\"
   displays
      -c:\long dirname\"-

   In order to achieve the desired result, I have to omit the second
   double quote character:
      ex.exe cmd.ex "c:\long dirname\
   displays
      -c:\long dirname\-

   Calling
      ex.exe cmd.ex "c:\long dirname\" "d:\long dirname\"
   displays
      -c:\long dirname" -
      -d:\long-
      -dirname"-

Regards,
   Juergen

-- 
A: Because it considerably reduces the readability of the text.
Q: Why?
A: Top posting.
Q: What is annoying in e-mail and news?

3. Re: command_line() bug in ex.exe 2.4

• Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 03, 2004
• 433 views
• Last edited Nov 04, 2004

Robert Craig wrote:

> Juergen Luethje wrote:
>> I ran the following small test program on Windows 98:
>> }}}
<eucode>
>> -- program 'cmd.ex'
>> constant CMD = command_line()
>> for i = 3 to length(CMD) do
>>    puts(1, "-" & CMD[i] & "-\n")
>> end for
>> if getc(0) then end if
>> </eucode>
{{{

>>
>> a) When calling it like this:
>>       exw.exe cmd.ex "c:\long dirname\"
>>    it displays, as I expected:
>>       -c:\long dirname\-
>>
>> b) But when calling it like this:
>>       ex.exe cmd.ex "c:\long dirname\"
>>    it displays:
>>       -c:\long dirname"-
>>
>>    It might look as if the backslash acts as an escape character here.
>>    But I think this isn't true, because in that case the first backslash
>>    should cause an error. Also, this should be consistent on all
>>    supported platforms IMHO.
>>    Calling
>>       ex.exe cmd.ex "c:\long dirname\\"
>>    displays
>>       -c:\long dirname\"-
>>
>>    In order to achieve the desired result, I have to omit the second
>>    double quote character:
>>       ex.exe cmd.ex "c:\long dirname\
>>    displays
>>       -c:\long dirname\-
>>
>>    Calling
>>       ex.exe cmd.ex "c:\long dirname\" "d:\long dirname\"
>>    displays
>>       -c:\long dirname" -
>>       -d:\long-
>>       -dirname"-
>
> The DOS command line is not handled the way you would like,
> but I don't have control over that. I just take the command line
> arguments as the system provides them to me. (Same on Linux
> and FreeBSD).
>
> For Windows, I get the command line as one long string,
> and I have to break it up into separate arguments, taking
> quotes into account. If there was something wrong,
> I might be able to correct it. But apparently you like the
> way exw does things.

Yes, exw.exe handles the command line in the way I (and probably most
other programmers) expect it. For the behaviour of ex.exe however, I
have no other word than 'strange'.

Who would expect that the command line
   ex.exe cmd.ex "c:\long dirname\" "d:\long dirname\"
would be split into (without the - characters)
   -c:\long dirname" -
   -d:\long-
   -dirname"-    ?

Who can tell me the rule for this, where is it documented?
When I want my Euphoria program to handle the command line correctly,
I need to know what command line options my program receives, don't I?

You write that ex.exe just takes the command line arguments as the
system provides them to it. AFAIK you use Watcom C for building ex.exe.
That means that "the system" for ex.exe consists at least of DOS and
Watcom C, right?

Let's see how DOS (DOS shell on Windows 98 here) itself handles command
line arguments:

---------------------------------------------------
@echo off
rem -- cmd.bat
rem -- display each command line argument in a line
:again
if %1!==! goto end
echo -%1-
shift
goto again
:end
---------------------------------------------------


Calling
   cmd.bat c:\long dirname\
displays:
   -c:\long-
   -dirname\-

Calling
   cmd.bat "c:\long dirname\"
displays:
   -"c:\long dirname\"-

Calling
   cmd.bat "c:\long dirname\" "d:\long dirname\"
displays
   -"c:\long dirname\"-
   -"d:\long dirname\"-

... as expected, and like exw.exe does it. (I don't care whether or not
both double quote characters that surround an argument are preserved.)


> I don't necessarily agree that Euphoria's
> command line arguments must be completely consistent
> across all platforms.

I would be helpful for developement of cross platform programs.

> The O/S and the command shell
> can process the command line before the program sees it.
> Even between DOS and Windows, I think there may be
> subtle differences beyond what you've observed.

Yes maybe. But despite all platform issues and beyond personal taste,
ex.exe's handling of the command line is obviously buggy, after the
information that I currently have probably caused by the Watcom C
compiler.

Regards,
   Juergen

-- 
A: Because it considerably reduces the readability of the text.
Q: Why?
A: Top posting.
Q: What is annoying in e-mail and news?

5. Re: command_line() bug in ex.exe 2.4

• Posted by Bernie Ryan <xotron at bluefrog.com> Nov 04, 2004
• 450 views

Robert Craig wrote:
>  
> The DOS command line is not handled the way you would like, 
> but I don't have control over that. I just take the command line 
> arguments as the system provides them to me. (Same on Linux
> and FreeBSD).
> 
> For Windows, I get the command line as one long string,
> and I have to break it up into separate arguments, taking
> quotes into account. If there was something wrong, 
> I might be able to correct it. But apparently you like the
> way exw does things.
> 
> I don't necessarily agree that Euphoria's 
> command line arguments must be completely consistent 
> across all platforms. The O/S and the command shell 
> can process the command line before the program sees it.
> Even between DOS and Windows, I think there may be 
> subtle differences beyond what you've observed.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
> 

Rob:

Here are the rules that microsoft uses to parse the command.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/progs_12.asp

Bernie

My files in archive:
w32engin.ew mixedlib.e eu_engin.e win32eru.ew

Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan

7. Re: command_line() bug in ex.exe 2.4

• Posted by "Juergen Luethje" <j.lue at gmx.de> Nov 04, 2004
• 471 views

Bernie Ryan wrote:

<snip>

> Here are the rules that microsoft uses to parse the command.
>  
>   http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/progs_12.asp

That's interesting, thanks.

I would not like that those rules apply to the command line parsing of
ex.exe though ...

a) because it's different from standard Euphoria rules:
   In Euphoria, a backslash in a literal string is always an escape
   character, not only when it preceds a double quotation mark or other
   backslashes which preced a double quotation mark.
   It doesn't make much sense to have C rules in Euphoria.

b) because Euphoria should behave as similar as possible on all
   supported platforms.


However, the rules at the web page mentioned above make sense to me,
e.g.:
"If an even number of backslashes is followed by a double quotation mark,
then one backslash (\) is placed in the argv array for every pair of
backslashes (\\), and the double quotation mark (") is interpreted as a
string delimiter."

Unfortunately, this is *not* the way ex.exe parses the command line.
Trying the examples from the above MS page with ex.exe, we'll already
see some differences:

-- program 'args.ex'
constant CMD = command_line()
for i = 3 to length(CMD) do
   puts(1, "\t" & CMD[i])
end for
puts(1, "\n")

------------------------------
@echo off
rem -- program 'args_test.bat'
ex args.ex "a b c" d e
ex args.ex "ab\"c" "\\" d
ex args.ex a\\\b d"e f"g h
ex args.ex a\\\"b c d
ex args.ex a\\\\"b c" d e
------------------------------

Regards,
   Juergen

-- 
 /"\  ASCII ribbon campain  |    |\      _,,,---,,_
 \ /  against HTML in       |    /,`.-'`'    -.  ;-;;,_
  X   e-mail and news,      |   |,4-  ) )-,_..;\ (  `'-'
 / \  and unneeded MIME     |  '---''(_/--'  `-'\_)

9. Re: command_line() bug in ex.exe 2.4

• Posted by Robert Craig <rds at RapidEuphoria.com> Nov 05, 2004
• 425 views

Juergen Luethje wrote:
> }}}
<eucode>
> -- program cmd_line.ex
> include machine.e
> constant DOS32 = 1
> 
> function cmd_line()
>    sequence registers
>    integer PSPaddr
> 
>    if platform() != DOS32 then return -1 end if
> 
>    registers = repeat(0, 10)
>    registers[REG_AX] = #6200
>    registers = dos_interrupt(#21, registers)
>    PSPaddr = registers[REG_BX]*#10
>    return peek({PSPaddr+#81, peek(PSPaddr+#80)})
> end function
> 
> puts(1, "-" & cmd_line() & "-\n")
> </eucode>
{{{

> 
> This works fine for me in a DOS box on Win 98 (using Eu 2.4).
> Calling on the command line
>    ex.exe cmd_line.ex "c:\long dirname\" "d:\long dirname\" 123
> displays
>    - cmd_line.ex "c:\long dirname\" "d:\long dirname\" 123-
> 
> Rob, I can (try to) gather more comprehensive information about this
> point, if you want me to do so.

It's interesting that you got the DOS interrupt to work.
I'll make a note of this and look at it maybe for 2.6.
In general I'm a bit leary of coding DOS interrupts.
I'd rather call a C routine.
I know that some interrupts don't work the same (or at all)
on all versions of DOS. Maybe you can put this change
into the new Public Domain source for 2.5 and people can
test it better on more platforms.

Regards,
   Rob Craig
   Rapid Deployment Software
   http://www.RapidEuphoria.com