Is there some way of calling a system command?

[Aldebaran]

I am a newbie Ada-programmer and need help with this topic.
In C one can launch a system command, for instance through
the following function.

system("ls ");

or in JAVA

exec("ls");

Is there some similar way of calling a system command in ADA?
Thanks in advance

[jimmaure...@worldnet.att.net]

The easiest way is to simply call the C system command.
The example below was run on my Windows XP system.

with Interfaces.C.Strings;
use Interfaces.C.Strings;

procedure System_Example is
function System_Call(Command : Chars_Ptr) return Interfaces.C.Int;
pragma Import(Convention => C, Entity => System_Call,
External_Name => "system");
Rc : Interfaces.C.Int;

begin
Rc := System_Call(New_String("dir"));

end System_Example;

The important part of the example is the creation of a function
specification I have named System_Call. That function specification
take a parameter of Chars_Ptr, which corresponds to a C char *.
The function specification is used as the Ada interface to the C
system call. The compiler is notified of that association through
the pragma Import. That pragma causes the compiler to link the C
system command and call it whenever System_Call is called in the
Ada code.

Jim Rogers

[Aldebaran]

It works fine.
Thank you.

Aldebaran

[Michel Simeon]

I am learning Ada and does not know C.
I tried your approach to call an othe program from Ada and it worked, except
for one problem: the calling program will wait for the return parameter (Rc
in your exemple) and thus freeze till the other one is closed.
Could i do something similar but withour the retrun parameter ?

--
Michel Simeon

<jimmaure...@worldnet.att.net> wrote in message
news:1150031952.3...@i40g2000cwc.googlegroups.com...

[Ludovic Brenta]

Michel Simeon writes :

> I am learning Ada and does not know C.
> I tried your approach to call an othe program from Ada and it worked, except
> for one problem: the calling program will wait for the return parameter (Rc
> in your exemple) and thus freeze till the other one is closed.
> Could i do something similar but withour the retrun parameter ?

See GNAT.OS_Lib.Non_Blocking_Spawn, GNAT.Expect.Non_Blocking_Spawn.

--
Ludovic Brenta.

[Michel Simeon]

Thank you for your answer, it worked for what I wanted to do.

I had not realized that in addition to Ada per se I should also look into
what GNAT is offering.

--
Michel Simeon

"Ludovic Brenta" <lud...@ludovic-brenta.org> wrote in message
news:1150380670....@y41g2000cwy.googlegroups.com...

[tolkamp]

Op zondag 11 juni 2006 15:19:12 UTC+2 schreef jimmaure...@worldnet.att.net:

Thank you for your reaction.
For me this is not very understandable.
Where must I put the directory path to the executable?
Is this "dir" in Rc := System_Call(New_String("dir"));?

[adambe...@gmail.com]

On Tuesday, November 26, 2013 7:35:26 AM UTC-8, tolkamp wrote:
> Op zondag 11 juni 2006 15:19:12 UTC+2 schreef jimmaure...@worldnet.att.net:

> > The easiest way is to simply call the C system command.
> > The example below was run on my Windows XP system.
>
> > with Interfaces.C.Strings;
> > use Interfaces.C.Strings;
>
> > procedure System_Example is
> > function System_Call(Command : Chars_Ptr) return Interfaces.C.Int;
> > pragma Import(Convention => C, Entity => System_Call,
> > External_Name => "system");
> > Rc : Interfaces.C.Int;
>
> > begin
> > Rc := System_Call(New_String("dir"));
> > end System_Example;

> > The important part of the example is the creation of a function
> > specification I have named System_Call. That function specification
> > take a parameter of Chars_Ptr, which corresponds to a C char *.
> > The function specification is used as the Ada interface to the C
> > system call. The compiler is notified of that association through
> > the pragma Import. That pragma causes the compiler to link the C
> > system command and call it whenever System_Call is called in the
> > Ada code.

> Thank you for your reaction.
> For me this is not very understandable.
> Where must I put the directory path to the executable?
> Is this "dir" in Rc := System_Call(New_String("dir"));?

No, "dir" is the command. The effect of this statement is that it will execute the "dir" command just as if a user had typed it into the Command Prompt window. On Windows, "dir" causes a directory listing to appear on the screen.

System_Call (that is, the C system() routine) more or less requires a string that is something the user would type in a shell or a Command Prompt window. So if you want to include the directory path, just include it as part of the command, same as you would if you typed it in yourself:

Rc := System_Call(New_String("c:\users\abc\subdirectory\mytool"));

or use the Ada.Directories and possibly Ada.Directories.Hierarchical_File_Names to create the file name:

Dir : constant String := "c:\users\abc\subdirectory";

Rc := System.Call(New_String(Ada.Directories.Compose(Dir, "mytool")));

-- Adam

[Per Sandberg]

Why not just
GNAT.OS_Lib.spawn
or
GNAT.Expect.*
?
/Persan

[tolkamp]

Op dinsdag 26 november 2013 17:10:32 UTC+1 schreef adambe...@gmail.com:

Thank you for your explanation. Now it works, the extra program is started.
The only disadvantage is that the Ada code below the procedure System_Example is suspended untill the extra started program is terminated. Is there a possibility that the Ada program continues while the extra program runs?

[Jeffrey Carter]

On 11/26/2013 11:24 AM, Per Sandberg wrote:
> Why not just
> GNAT.OS_Lib.spawn
> or
> GNAT.Expect.*
> ?

A. One is using another compiler

B. One wishes to write portable code

--
Jeff Carter
"I'm a kike, a yid, a heebie, a hook nose! I'm Kosher,
Mum! I'm a Red Sea pedestrian, and proud of it!"
Monty Python's Life of Brian
77

[adambe...@gmail.com]

On Tuesday, November 26, 2013 10:54:37 AM UTC-8, tolkamp wrote:

> Thank you for your explanation. Now it works, the extra program is started.
>
> The only disadvantage is that the Ada code below the procedure System_Example is suspended untill the extra started program is terminated. Is there a possibility that the Ada program continues while the extra program runs?

You could try putting it in a task. GNAT and other compilers will cause the task to run in another thread (depending on the OS, I think), so it should probably work, but I won't make any guarantees. C library routines may do stuff that could interfere with the Ada code that handles tasking.

Other than that: if you're using GNAT, try one of the other suggested library routines GNAT provides. If you're using another compiler, perhaps they provide libraries with similar functionality, or else you'll have to figure out what OS calls will do the job and use Import pragmas to call them yourself. Ada just doesn't have a standardized mechanism for spawning other programs or commands. It looks like one was discussed in 2004 (AI95-371), but it didn't get approved.

-- Adam

[Dmitry A. Kazakov]

On Tue, 26 Nov 2013 11:58:18 -0700, Jeffrey Carter wrote:

> On 11/26/2013 11:24 AM, Per Sandberg wrote:
>> Why not just
>> GNAT.OS_Lib.spawn
>> or
>> GNAT.Expect.*
>> ?
>
> A. One is using another compiler
>
> B. One wishes to write portable code

It is rather debatable what would be more portable calling to system or
using GNAT's OS_Lib.

In more realistic cases, when some sort of process communication is
involved, system is not an option. Even OS_Lib is quite complicated for
asynchronous calls with pipes etc.

I wish there were some standard Ada library with proxy task interface for
an outstanding system process.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Dirk Heinrichs]

adambe...@gmail.com wrote:

> You could try putting it in a task. GNAT and other compilers will cause
> the task to run in another thread (depending on the OS, I think), so it
> should probably work, but I won't make any guarantees. C library routines
> may do stuff that could interfere with the Ada code that handles tasking.

AFAIK Gnat's System.Os_Lib says you shouldn't.

> Other than that: if you're using GNAT, try one of the other suggested
> library routines GNAT provides. If you're using another compiler, perhaps
> they provide libraries with similar functionality, or else you'll have to
> figure out what OS calls will do the job and use Import pragmas to call
> them yourself. Ada just doesn't have a standardized mechanism for
> spawning other programs or commands. It looks like one was discussed in
> 2004 (AI95-371), but it didn't get approved.

There's also SpawnManager (http://www.codelabs.ch/spawn-manager/index.html),
which was developed to solve System.OsLib's restriction.

HTH...

Dirk
--
Dirk Heinrichs <dirk.he...@altum.de>
Tel: +49 (0)2471 209385 | Mobil: +49 (0)176 34473913
GPG Public Key C2E467BB | Jabber: dirk.he...@altum.de

[Randy Brukardt]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> wrote in message
news:avzjtrmvmln0$.64z4rbzdot6g$.dlg@40tude.net...
...

> I wish there were some standard Ada library with proxy task interface for
> an outstanding system process.

We tried to define such things for Ada 2005, but gave up because the
description was necessarily in terms of Windows or Linux, and that's not
appropriate for a target-independent programming language. I believe there
were some other technical issues as well (one would have to look up the
minute of the meeting(s) that discussed AI95-0371-1, there isn't much in the
AI or it's mail).

Randy.

[Georg Bauhaus]

On 26.11.13 20:49, adambe...@gmail.com wrote:
> On Tuesday, November 26, 2013 10:54:37 AM UTC-8, tolkamp wrote:
>
>> >Thank you for your explanation. Now it works, the extra program is started.
>> >
>> >The only disadvantage is that the Ada code below the procedure System_Example is suspended untill the extra started program is terminated. Is there a possibility that the Ada program continues while the extra program runs?
> You could try putting it in a task.

I'd also try the "start" command available with Windows(TM) and
see if it makes the Ada program continue while the "start"-ed
program runs at the same time. (That is, you'd use "start" like
"dir", with the to-be-run program among the arguments passed to
"start".)

[Jacob Sparre Andersen]

Adam <adambe...@gmail.com> wrote:

> Ada just doesn't have a standardized mechanism for spawning other
> programs or commands. It looks like one was discussed in 2004
> (AI95-371), but it didn't get approved.

Technically the POSIX API is standardised - even if it isn't a part of
the LRM itself.

Greetings,

Jacob
--
"Common sense is not common at all."

[Eryndlia Mavourneen]

On Wednesday, November 27, 2013 1:02:54 AM UTC-6, Georg Bauhaus wrote:

"spawn", of course, implies that the new process be a child process of the spawning process. It also can be desirable to create an independent process, and it sounds as if the Windows "start" command does this, although I don't believe it is so easily done on Linux/POSIX systems. Of course, it is trivial on VMS. :-)

-- Eryndlia Mavourneen (KK1T)

[tolkamp]

Op dinsdag 26 november 2013 20:49:25 UTC+1 schreef adambe...@gmail.com:

Thank you for your suggestion for putting it in a task. It costs me some time to get it right but now it works very well. Again thank you very much for your help.

-- Fred --

[Per Sandberg]

On Tue, 26 Nov 2013 11:58:18 -0700
Jeffrey Carter <spam.jrc...@spam.not.acm.org> wrote:

> On 11/26/2013 11:24 AM, Per Sandberg wrote:
> > Why not just
> > GNAT.OS_Lib.spawn
> > or
> > GNAT.Expect.*
> > ?
>
> A. One is using another compiler
>
> B. One wishes to write portable code
>

A: The sources are there under GPL and would be easy to port to any
compiler.
B: Se A
/Per