Program (not task) Activation

Program (not task) Activation

[Jeremy T Smith]

I'm using Rational Apex 2.4.1 to develop Ada95 on an SGI in the 
flight simulation world.  I have been provided certain code 
modules from the real aircraft that I cannot modify due to 
validation restrictions.  Can anyone suggest a way to kick these 
off as a series of independant executables, not tasks, from 
within Ada95?  They must be launched as if from the command line, 
with certain setup options passed as command line parameters.  
The rest of the simulation environment is now running correctly, 
but we're stuck on this one.  Thanks.

-- 
Jeremy Smith
real_time@compuserve.com
Voice: 603-753-4927
Fax: 603-753-4967

Re: Program (not task) Activation

[Robert I. Eachus]

In article <#CDmPrma9GA.300@ntawwabp.compuserve.com> Jeremy T Smith <75534.2075@CompuServe.COM> writes:

                        Can anyone suggest a way to kick these 
   off as a series of independant executables, not tasks, from 
   within Ada95?  They must be launched as if from the command line, 
   with certain setup options passed as command line parameters.  
   The rest of the simulation environment is now running correctly, 
   but we're stuck on this one.  Thanks.

   I assume that the SGI computer you are using supports some version
of the Unix "system" call, or some equivalent functionality.  (You
didn't specify which SGI model or OS you are using.)  Is there some
reason that just making such a call with the appropriate string won't
work?
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Program (not task) Activation

[Do-While Jones]

>In article <#CDmPrma9GA.300@ntawwabp.compuserve.com> Jeremy T Smith <75534.2075@CompuServe.COM> writes:
>
>                        Can anyone suggest a way to kick these 
>   off as a series of independant executables, not tasks, from 
>   within Ada95?  They must be launched as if from the command line, 
>   with certain setup options passed as command line parameters.  
>   The rest of the simulation environment is now running correctly, 
>   but we're stuck on this one.  Thanks.
>

An easy way to do this is to make a UNIX shell command from inside your
Ada program.  I've included the code I use below. 

There are two package bodies.  One is for Telesoft (Ada 83) on the SUN. 
The other is for GNAT on the SGI.  I've also included two demo programs.
The first demo program calls the "ls" command.  The second demo program
calls a bogus command to test the error detection logic. 

Just for fun, I tried compiling and running these UNIX Interface
components on my brand-new Windows 95 machine.  (I used the ui02kb02.ada
body.)  The first demo program ran correctly.  Windows 95 responded by
displaying a correct directory listing.  The second demo program made
Windows display "bad command or filename", but it didn't raise the
expected exception. 

Does anyone know why Windows 95 did not return an error code?

Do-While Jones

            +--------------------------------+
            |    Know                 Ada    |
            |        [Ada's Portrait]        |
            |    Will              Travel    |
            | wire do_while@ridgecrest.ca.us |
            +--------------------------------+

-------------------------------------------------------------
--                      ui02ks01.ada
--                      24 January 1995

--                      Do-While Jones
--                      324 Traci Lane
--                      Ridgecrest, CA 93555
--                      (760) 375-4607

package SHELL is

  procedure Command(ARGUMENT : string);
    -- Executes the shell command with the given string
    -- ARGUMENT.  For example, the statement below lists
    -- all the files beginning with ui02.

    --    SHELL.Command("ls ui02*");

    -- Raises SHELL.COMMAND_ERROR if it fails.

  COMMAND_ERROR : exception;

  -- The following functions are useful diagnostics if
  -- COMMAND_ERROR is raised.  They are intended only
  -- for debugging.

  function Error_Code return integer;
    -- Tells you the result code returned by the system call.

  function Invalid_Command return string;
    -- Tells you what string was rejected by the system call.

end SHELL;


-------------------------------------------------------------
--                      ui02kb01.ada
--                      24 January 1995

--                      Do-While Jones
--                      324 Traci Lane
--                      Ridgecrest, CA 93555
--                      (760) 375-4607

-- This body works for the Telesoft Ada compiler on
-- the Sun.

with SYSTEM,
     STANDARD_INTEGERS,  -- part AA01
     ASCII_UTILITIES;    -- part AA02

package body SHELL is

  type UNIX_results is
    new STANDARD_INTEGERS.Integer_32;

  RESULT : UNIX_results;

  BAD_COMMAND_STRING : string(1..70);
  BAD_STRING_LENGTH  : natural := 0;

  function unix_call(addr : SYSTEM.Address)
    return UNIX_results;
  pragma Interface(C, unix_call);
  pragma Interface_Information
    (unix_call, "_system");
  
  procedure Command(ARGUMENT : string) is
    C_STRING : constant string :=
      ARGUMENT & ASCII.NUL;
  begin
    RESULT := unix_call(C_STRING(1)'ADDRESS);
    if RESULT /= 0 then
      ASCII_UTILITIES.String_Copy(
        FROM => ARGUMENT,
        TO   => BAD_COMMAND_STRING);
      BAD_STRING_LENGTH := ARGUMENT'LENGTH;
      raise COMMAND_ERROR;
    end if;
  end Command;

  function Error_Code return integer is
  begin
    return integer(RESULT);
  end Error_Code;

  function Invalid_Command return string is
  begin
    return BAD_COMMAND_STRING(1..BAD_STRING_LENGTH);
  end Invalid_Command;

end SHELL;


-------------------------------------------------------------
--                      ui02kb02.ada
--                      10 April 1997

--                      Do-While Jones
--                      324 Traci Lane
--                      Ridgecrest, CA 93555
--                      (760) 375-4607

-- This body works for the Gnat (Ada 95) compiler on Silicon
-- Graphics.

with SYSTEM,
     STANDARD_INTEGERS,  -- part AA01
     ASCII_UTILITIES;    -- part AA02

package body SHELL is

  type UNIX_results is
    new STANDARD_INTEGERS.Integer_32;

  RESULT : UNIX_results;

  BAD_COMMAND_STRING : string(1..70);
  BAD_STRING_LENGTH  : natural := 0;

  function unix_call(addr : SYSTEM.Address)
    return UNIX_results;
  pragma IMPORT(C, unix_call, "system");
  
  procedure Command(ARGUMENT : string) is
    C_STRING : constant string :=
      ARGUMENT & ASCII.NUL;
  begin
    RESULT := unix_call(C_STRING(1)'ADDRESS);
    if RESULT /= 0 then
      ASCII_UTILITIES.String_Copy(
        FROM => ARGUMENT,
        TO   => BAD_COMMAND_STRING);
      BAD_STRING_LENGTH := ARGUMENT'LENGTH;
      raise COMMAND_ERROR;
    end if;
  end Command;

  function Error_Code return integer is
  begin
    return integer(RESULT);
  end Error_Code;

  function Invalid_Command return string is
  begin
    return BAD_COMMAND_STRING(1..BAD_STRING_LENGTH);
  end Invalid_Command;

end SHELL;
-------------------------------------------------------------
--                      ui02td01.ada
--                      24 January 1995

--                      Do-While Jones
--                      324 Traci Lane
--                      Ridgecrest, CA 93555
--                      (760) 375-4607

with TEXT_IO,
     SHELL;  -- part UI02

procedure UI02TD01 is
begin
  TEXT_IO.New_Line;
  TEXT_IO.Put_Line("The files beginning with ""ui02"" are:");

  SHELL.Command("ls ui02*");

  TEXT_IO.New_Line;

end UI02TD01;

-------------------------------------------------------------
--                      ui02td02.ada
--                      24 January 1995

--                      Do-While Jones
--                      324 Traci Lane
--                      Ridgecrest, CA 93555
--                      (760) 375-4607

with TEXT_IO,
     SHELL;  -- part UI02

procedure UI02TD02 is
begin
  TEXT_IO.New_Line;
  TEXT_IO.Put_Line("Trying ""nonesuch with arguments"" "
    & "which should raise an exception.");
  TEXT_IO.New_Line;

  SHELL.Command("nonesuch with arguments");

  -- Should never get here.
  TEXT_IO.Put_Line("FAILED to raise the exception.");

exception
  when SHELL.COMMAND_ERROR =>
    -- Should jump to here.
    TEXT_IO.New_Line;
    TEXT_IO.Put_Line("SHELL.COMMAND_ERROR was raised.");
    TEXT_IO.Put_Line("The offending command is "
      & SHELL.Invalid_Command & ".");
    TEXT_IO.Put_Line("Error number is"
      & integer'IMAGE(SHELL.Error_Code)
      & ".");
end UI02TD02;

Re: Program (not task) Activation

[Jerry van Dijk]

Do-While Jones (do_while@ridgecrest.ca.us) wrote:

: Does anyone know why Windows 95 did not return an error code?

If you are using GNAT 3.10p on a Win95 machine, GNAT calls the system()
function from the MS RTS:

	int system( const char *command );

	If command is NULL and the command interpreter is found, the function
	returns a nonzero value. If the command interpreter is not found, it
	returns 0 and sets errno to ENOENT. If command is not NULL, system
	returns the value that is returned by the command interpreter. It
	returns the value 0 only if the command interpreter returns the value 0.
	A return value of - 1 indicates an error, and errno is set to one of the
	following values:

	E2BIG    Argument list (which is system-dependent) is too big.
	ENOENT   Command interpreter cannot be found.
	ENOEXEC  Command-interpreter file has invalid format and is not executable.
	ENOMEM   Not enough memory is available to execute command; or available
	         memory has been corrupted; or invalid block exists, indicating
	         that process making call was not allocated properly.

	You must explicitly flush (using fflush or _flushall) or close any
	stream before calling system.

Also, since you are using Ada95, why the difficult code. A portable way
to call system() in Ada95 could be:

-- demo.adb
with Commands; use Commands;

procedure Demo is
   Result : Integer;
begin
   Result := System_Command ("cat demo.adb");
end Demo;

-- Commands.ads
package Commands is

   function System_Command (Argument : String) return Integer;

end Commands;

-- Command.adb
with Interfaces.C; use Interfaces.C;

package body Commands is

   function System (S : char_array) return int;
   pragma Import (C, System, "system");

   function System_Command (Argument : String) return Integer is
   begin
      return Integer (System (To_C (Argument)));
   end System_Command;

end Commands;
-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada

Re: Program (not task) Activation

[Michael F Brenner]

This confirms that Jerry's demo program to call system works on 
gnat3.10 on NT 4.0 when you add a file cat.bat containing the string:
     TYPE %1

However, this code reflects the underlying runtime system's refusal to 
distinguish between:
    (CASE I) A program which runs and fails.
    (CASE II) A program which does not exist (say, program name spelt wrong) 

To show this, lines were added to demo.adb to test the following commands:

  (a) type an existing file:                                cat demo.adb
  (b) type a non-exiting file:                              cat demo.adZ
  (c) run an existing program that sets the condition code: exitcode 7
  (d) run a non-existing program:                           exitcodZ 7
  (e) run rabbits:                                          demo 

Result a:  (1) It typed the file demo.adb (as expected).
           (2) It returned condition code 0 (as expected).
           (3) It displayed no error messages (as expected).

Result b:  (1) It did not type the non-existing file (as expected).
           (2) It returned 1 (as expected). 
           (3) It printed the INCORRECT error message: The name 
               specified is not recognized as an internal or 
               external command, operable program or batch file.

Result c:  (1) It appeared to do nothing (as expected).
           (2) It returned condition code 7 (as expected).
           (3) It displayed no error messages (as expected).

Result d:  (1) It appeared to do nothing (as expected).
           (2) It returned condition code 1 (as expected).
           (3) It printed the CORRECT error message: The name
               specified is not recognized as an internal or
               external command, operable program or batch file.

Result e:  (1) It spawned itself, which spawned itself... (as expected).
           (2) Each of the spawned Selfs return condition code 0 (as expected).
           (3) It displayed no error messages until cancelled (as expected).

Jerry's code, and Jerry's demo with enhancements:

-- Commands.ads
package Commands is
   function System_Command (Argument : String) return Integer;
end Commands;

-- Command.adb
with Interfaces.C; use Interfaces.C;

package body Commands is

   function System (S : char_array) return int;
   pragma Import (C, System, "system");

   function System_Command (Argument : String) return Integer is
   begin
      return Integer (System (To_C (Argument)));
   end System_Command;

end Commands;
--
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada
End of article 71031 (of 71034) -- what next? [npq]

-- demo.adb
with Commands; use Commands;
with text_io;
procedure Demo2 is
   Result : Integer;
begin
   Result := System_Command ("cat demo.adb");
   text_io.put_line ("The result of executing the command cat demo.adb was " &
                     integer'image (result));
   Result := System_Command ("cat demo.adZ");
   text_io.put_line ("The result of executing the command cat demo.adZ was " &
                     integer'image (result));
   Result := System_Command ("exitcode 1");
   text_io.put_line ("The result of executing the command was " &
                     integer'image (result));
   Result := System_Command ("demo");
   text_io.put_line ("The result of executing the command demo was " &
                     integer'image (result));

end Demo2;

Re: Program (not task) Activation

[Do-While Jones]

Jerry van Dijk posted a useful demo program, which Michael Brenner
expanded to include tests to make sure the expected error code were
returned.

Michael's claimed results can't really be the results from the program he
included in his message because there are five results, but only four test
cases.  He clearly (and very kindly) deleted the "rabbits"  test (which
would have recursively called itself until the stack crashed).  He also
changed exitcode 1 to exitcode 7.  But these are minor changes.  He
probably edited his test program and forgot to revise the results.  (Maybe
he inserted an old copy of the program file in his message.)  Anyway, it
isn't important.

What is important is that when he ran his test on NT 4.0, he got
non-zero results when he should have.  When I ran his program on Windows
95, I got zero every time.  (I couldn't run his "exitcode" program because
that must have been a C program he wrote but failed to include in
the message.)

So, my original question ("Does anyone know why Windows 95 did not return
an error code?") still stands.

Jerry asked, "Also, since you are using Ada 95, why the difficult code?"

The short answer is that this was legacy Ada 83 code written for UNIX.  I
just compiled it on Windows 95 and was surprised that it worked at all.

The long answer is that I wanted to make the system call safer and more
Ada-like.

In C, procedures are written as functions.  I hate that.  I wrote
SHELL.Command as a procedure that RAISES AN EXCEPTION if it fails.  This
relieves application programs of having to check the result to see if it
is zero or not.  If I knew the values of E2BIG, ENOENT, etc., I would
make my SHELL package even more difficult by adding another function that
converts the error value to a string ("Argument list too big.", "Command
interpreter not found", etc.)  

I don't like to have to remember to check a function result to see if a
procedure failed or not.  I made the SHELL.Command procedure difficult so
that programs that call SHELL.Command could be simple. 

Do-While Jones

            +--------------------------------+
            |    Know                 Ada    |
            |        [Ada's Portrait]        |
            |    Will              Travel    |
            | wire do_while@ridgecrest.ca.us |
            +--------------------------------+

Re: Program (not task) Activation

[Jerry van Dijk]

Do-While Jones (do_while@ridgecrest.ca.us) wrote:

: Jerry van Dijk posted a useful demo program, which Michael Brenner
: expanded to include tests to make sure the expected error code were
: returned.

: What is important is that when he ran his test on NT 4.0, he got
: non-zero results when he should have.  When I ran his program on Windows
: 95, I got zero every time.  (I couldn't run his "exitcode" program because
: that must have been a C program he wrote but failed to include in
: the message.)

: So, my original question ("Does anyone know why Windows 95 did not return
: an error code?") still stands.

The answer seems to be: the system() call does not behave as specified,
it seems error returns from programs are caught by the system() code and
not passed back to the calling program.

I tried to verify this by first testing it with a program compiled with
the Microsoft Visual C++ v5.0 compiler:

	/***************************************************************/
	/*                                                             */
	/* The MS documentation specifies the following cases for the  */
	/* system() call:                                              */
	/*                                                             */
	/* 1. Command is ""                                            */
	/*                                                             */
	/*    a. Command interpreter not found -> returns 0, errno set */
	/*    b. Command interpreter found     -> returns non-zero     */
	/*                                                             */
	/*    This is meant to test for the presence of a command      */
	/*    interpreter                                              */
	/*                                                             */
	/* 2. Command is not ""                                        */
	/*                                                             */
	/*    a. Return value of command interpreter                   */
	/*    b. Returns -1 id canse of error -> errno set             */
	/*                                                             */
	/*    This is supposed to be the return code of the command    */
	/*                                                             */
	/***************************************************************/

	#include <stdio.h>
	#include <stdlib.h>

	int main(void)
	{
	   int rc;

	   /* Check for command interpreter  */
	   puts("\nCalling without argument:");
	   rc = system("");
	   if (rc == 0) {
	      perror("system() returned 0");
	   }
	   else {
	      printf("system() returned %d, command interpreter found\n", rc);
	   }
	
	   /* Run a legal command */
	   puts("\nCalling with legal argument:");
	   rc = system("dir > nul");
	    if (rc == -1) {
	      perror("system() returned -1");
	   }
	   else {
	      printf("system() returned %d, command succeded\n", rc);
	   }

	   /* Run an illegal command */
	   puts("\nCalling with illegal argument:");
	   rc = system("xyyz1 > nul");
	    if (rc == -1) {
	      perror("system() returned -1");
	   }
	   else {
	      printf("system() returned %d, command succeded\n", rc);
	   }

	   return EXIT_SUCCESS;
	}

Next, I did the same using Ada:

	-----------------------------------------------------------------
	--
	-- The MS documentation specifies the following cases for the
	-- system() call:
	--
	-- 1. Command is ""
	--
	--    a. Command interpreter not found -> returns 0, errno set
	--    b. Command interpreter found     -> returns non-zero
	--
	--    This is meant to test for the presence of a command
	--    interpreter
	--
	-- 2. Command is not ""
	--
	--    a. Return value of command interpreter
	--    b. Returns -1 id canse of error -> errno set
	--
	--    This is supposed to be the return code of the command
	--
	-----------------------------------------------------------------
	
	with Ada.Text_IO;      use Ada.Text_IO;
	with Interfaces.C;     use Interfaces.C;
	with Ada.Command_Line; use Ada.Command_Line;
	
	procedure Test is
	
	   function System (Argument : String) return Integer is
	      function c_system (Argument : char_array) return int;
	      pragma Import (C, c_system, "system");
	   begin
	      return Integer (c_system (To_C (Argument)));
	   end System;
	
	   procedure Perror (Text : String) is
	      function c_perror (Text : char_array) return int;
	      pragma Import (C, c_perror, "perror");
	      Temp : int;
	   begin
	      Temp := c_perror (To_C (Text));
	   end Perror;
	
	   Return_Value : Integer;

	begin

	   -- Check for command interpreter
	   New_Line;
	   Put_Line ("Calling without argument:");
	   Return_Value := System("");
	   if Return_Value = 0 then
	      Perror("system() returned 0");
	   else
	      Put_Line ("system() returned" &
	                Integer'Image (Return_Value) &
	                "command interpreter not found");
	   end if;
	
	   -- Run a legal command
	   New_Line;
	   Put_Line ("Calling with legal argument:");
	   Return_Value := System("");
	   if Return_Value = -1 then
	      Perror ("system() returned -1");
	   else
	      Put_Line ("system() returned" &
	                Integer'Image (Return_Value) &
	                ", command succeded");
	   end if;
	
	   -- Run an illegal command
	   New_Line;
	   Put_Line ("Calling with illegal argument:");
	   Return_Value := System("xyyz1 > nul");
	   if Return_Value = -1 then
	      Perror ("system() returned -1");
	   else
	      Put_Line ("system() returned" &
	                Integer'Image (Return_Value) &
	                ", command succeded");
	   end if;
	
	   Set_Exit_Status (Success);
	
	end;

Both programs produced identical output:

	Calling without argument:
	system() returned 0: No error

	Calling with legal argument:
	system() returned 0, command succeded

	Calling with illegal argument:
	De opdracht of bestandsnaam is onjuist.
	system() returned 0, command succeded

: Jerry asked, "Also, since you are using Ada 95, why the difficult code?"

: The short answer is that this was legacy Ada 83 code written for UNIX.  I
: just compiled it on Windows 95 and was surprised that it worked at all.

: The long answer is that I wanted to make the system call safer and more
: Ada-like.

Yes, I understand using the exception mechanism, I do the same in my code.
I just wondered why you didn't use the Interfaces.C package.

: If I knew the values of E2BIG, ENOENT, etc.

Look in /usr/mingw32/include/errno.h

regards,
Jerry.

-- 
-- Jerry van Dijk  | email: jdijk@acm.org
-- Leiden, Holland | member Team-Ada

Re: Program (not task) Activation

[Do-While Jones]

I really want to thank Jerry and Michael for the help they have been
giving me on this problem.  The two programs that Jerry supplied in his
last message show that he has put more than casual effort into solving my
problem. 

I'm especially grateful because this is a Windows 95 problem (or maybe a
gcc version 2.7.2 problem) rather than an Ada problem.  Both of Jerry's
test programs (C and Ada) returned error codes of 0 in every case.  So, my
version of Windows 95 (4.00.950B, which came pre-installed on a new
Gateway 2000 a couple of weeks ago) doesn't work like his version of
Windows 95.  (Should I be surprised?) 

I guess I need to take this discussion to a Windows 95 news group.

Do-While Jones

            +--------------------------------+
            |    Know                 Ada    |
            |        [Ada's Portrait]        |
            |    Will              Travel    |
            | wire do_while@ridgecrest.ca.us |
            +--------------------------------+

Re: Program (not task) Activation

[Do-While Jones]

In article <6i7d46$9ik$1@owens.ridgecrest.ca.us>,
Do-While Jones <do_while@ridgecrest.ca.us> wrote:
>Both of Jerry's
>test programs (C and Ada) returned error codes of 0 in every case.  So, my
>version of Windows 95 (4.00.950B, which came pre-installed on a new
>Gateway 2000 a couple of weeks ago) doesn't work like his version of
>Windows 95.  (Should I be surprised?) 
>

Oops!  I just re-read Jerry's message.  The C program didn't work on
his system, either.  So, it is a consistent Windows 95 problem.  (Should
that make me feel better?)

DWJ