Command Line on windows

Command Line on windows

[RasikaSrinivasan]

I am trying to write a command line utility and an expected argument
is a wildcard.

but it appears the wildcard is always "expanded to the list of file
names". for example, i create test_cli.adb with the following :

with Text_Io;
with Gnat.Command_Line ;

procedure Test_Cli is

begin
   while Gnat.Command_Line.Getopt("-v") /= Ascii.Nul
   loop
      null ;
   end loop ;
   Text_Io.Put("Argument ");
Text_Io.Put_Line( Gnat.Command_Line.Get_Argument ) ;
end Test_Cli ;


build it with gnatmake test_cli and then
test_cli abcdefghijkl <--- works as expected
test_cli *.adb <--- simply prints test_cli.adb
test_cli *.x <- works as i expect - just prints "*.x"

is there a way to turn of such automatic expansion (in windows)

thanks for any input. srini

Re: Command Line on windows

[Gautier]

Not solving your problem, but you'd prefer to use Ada.Command_Line which 
is standard and with Ada strings instead of C strings.
_________________________________________________________
Gautier's Ada programming -- http://sf.net/users/gdemont/

NB: For a direct answer, e-mail address on the Web site!

Re: Command Line on windows

[RasikaSrinivasan]

On Sep 12, 8:25 am, Gautier <gaut...@fakeaddress.nil> wrote:
> Not solving your problem, but you'd prefer to use Ada.Command_Line which
> is standard and with Ada strings instead of C strings.
> _________________________________________________________
> Gautier's Ada programming --http://sf.net/users/gdemont/
>
> NB: For a direct answer, e-mail address on the Web site!

unfortunately ada.command_line says the behaviour is implementation
defined.

in fact the following is a test of my original attempt :

with Text_Io; use Text_Io;
with Ada.Command_Line;

procedure Test_Cli is
begin
   Put_Line(Ada.Command_Line.Argument(1));
end Test_Cli ;

this when compiled with gnat - produced results similar to
gnat.command_line. That is why I thought gnat.command_line might work
better.

   function Get_Argument (Do_Expansion : Boolean := False) return
String;
   --  Returns the next element on the command line which is not a
switch.
   --  This function should not be called before Getopt has returned
   --  ASCII.NUL.

the do_expansion led me to believe i could turn it off.

any other ideas?

of course specifying for example "*.adb" (within quotations) does
disable it but i guess that is the unix behaviour expected.

thanks, srini

Re: Command Line on windows

[Gautier]

> any other ideas?

Maybe look in the run-time library sources (body of GNAT.Command_Line 
and further). I guess it calls a GNU function that expands the wildcards 
and there is an option or another function that doesn't.
If you find something, I'm curious about the solution (same problem for 
the zipada / unzipada utilities).

G.

Re: Command Line on windows

[Jeffrey R. Carter]

RasikaSrinivasan@gmail.com wrote:
> 
> but it appears the wildcard is always "expanded to the list of file
> names". for example, i create test_cli.adb with the following :

This appears to be a "feature" of GNAT, apparently to make programs behave the 
same on Windows as on Linux, where wildcards are expanded by the shell.

-- 
Jeff Carter
"Now look, Col. Batguano, if that really is your name."
Dr. Strangelove
31

Re: Command Line on windows

[Adam Beneschan]

On Sep 12, 8:18 am, "Jeffrey R. Carter"
<spam.jrcarter....@spam.acm.org> wrote:
> RasikaSriniva...@gmail.com wrote:
>
> > but it appears the wildcard is always "expanded to the list of file
> > names". for example, i create test_cli.adb with the following :
>
> This appears to be a "feature" of GNAT, apparently to make programs behave the
> same on Windows as on Linux, where wildcards are expanded by the shell.

You can get around this by calling GetCommandLine yourself; this will
get Windows to give you the original command line, unprocessed by
GNAT.  See

http://msdn.microsoft.com/en-us/library/ms683156(VS.85).aspx

But you'll have to deal with the null terminator yourself
(Interfaces.C.Strings should help here) and parse the arguments
yourself.

                               -- Adam

Re: Command Line on windows

[Jean-Pierre Rosen]

Gautier a �crit :
>> any other ideas?
> 
> Maybe look in the run-time library sources (body of GNAT.Command_Line 
> and further). I guess it calls a GNU function that expands the wildcards 
> and there is an option or another function that doesn't.
> If you find something, I'm curious about the solution (same problem for 
> the zipada / unzipada utilities).
> 
> G.
AFAIK, the problem is not with Gnat, but with cygwin. It does the 
expansion as Unix would have done, to ease portability for Unix 
applications. Well, this is an explanation, but no solution...

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Command Line on windows

[Keith Thompson]

Jean-Pierre Rosen <rosen@adalog.fr> writes:
> Gautier a �crit :
>>> any other ideas?
>> Maybe look in the run-time library sources (body of
>> GNAT.Command_Line and further). I guess it calls a GNU function that
>> expands the wildcards and there is an option or another function
>> that doesn't.
>> If you find something, I'm curious about the solution (same problem
>> for the zipada / unzipada utilities).
>> G.
> AFAIK, the problem is not with Gnat, but with cygwin. It does the
> expansion as Unix would have done, to ease portability for Unix
> applications. Well, this is an explanation, but no solution...

I don't think the original poster mentioned Cygwin.

If he is using Cygwin, the solution is to escape the wildcard:

    some_command "foo*"
    some_command 'foo*'
    some_command foo\*

But if he's not using Cygwin, he's probably invoking the command from
a Windows command prompt -- and in that case I don't know of a
solution.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

Re: Command Line on windows

[Pascal Obry]

Jean-Pierre Rosen a �crit :
> AFAIK, the problem is not with Gnat, but with cygwin. It does the
> expansion as Unix would have done, to ease portability for Unix
> applications. Well, this is an explanation, but no solution...

In fact no. This is controlled by the MingW runtime. Take CRT_noglob.o
from a MingW distribution and link your executable with it. This will
disable file expansion on the command line.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.net
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595