RE: QzshSystem API

[Scott Klement <klemscot@xxxxxxxxxxxx>]

On Wed, 3 Sep 2003, Joel Cochran wrote:
>
> I thought of the %trim() thing but still no joy.  I've made the
> slightest progress: QzshCheckShellCommand() validated the 'ls' command
> (but not 'ls -l') but the QzshSystem() API still returns a "No such path
> or directory" message.
>

According to the documentation to the QzshCheckShellCommand() API:

    The QzshCheckShellCommand() function finds the specified shell command
    by searching:

        * for a built-in utility, then
        * in each directory in the list specified by path or the PATH
            environment variable in turn.

    An application can use QzshCheckShellCommand() to verify that command
    exists and the user has authority to command before running it.

This seems to match exactly your experiences.  It says that it searches
for a command called 'ls' in the paths specified in the 2nd parm.   That
works, because it finds a command called 'ls'

In your second example, it's looking for a command called 'ls -l'.  There
is no command by that name (and there shouldn't be!!!) so the API is
worked as designed.

You seem to expect QzshCheckShellCommand() to validate the syntax of
the parameters of the command -- it doesn't do that.  It just looks for
a command.   It is valid in Unix (but a bad idea!) for command names to
have spaces in them.

> Unfortunately I need to get this done, so I guess I'll have to try to
> issue the command the old fashioned way with system or QCMDEXC.  The
> problem is that when I do that within a program the user is prompted to
> press Enter to close the shell.  I need to make this transparent to the
> user, but the command doesn't appear to have a 'quiet' mode.

Well, for mkdir you could just use the API... that'd be much easier...

The following code appears to work for me, *if* I run it from STRQSH:

     d qsh             pr            10i 0 extproc('QzshSystem')
     d  shCommand                      *   value options( *string )

     d checkShellCmd   pr            10i 0 extproc('QzshCheckShellCommand')
     d  shCommand                      *   value options( *string )
     d  path                           *   value options( *string )

     d write           pr            10I 0 extproc('write')
     D  fd                           10I 0 value
     D  data                           *   value
     D  size                         10I 0 value

     D inLocal         s            100A   varying
     D localDir        s            100A   varying
     D cmdString       s            300A   varying
     D qshErrorCode    s             10I 0
     D errorMessage    s            200A
     D rc              s             10I 0
     D NEWLINE         c                   x'25'

      /free
          cmdString = 'cp -R /datacds /home/klemscot/datacds' + NEWLINE;
          qshErrorCode = qsh( cmdString );

          cmdstring = 'qshErrorCode = ' + %char(qShErrorCode) + NEWLINE;
          callp write(1: %addr(cmdString)+2: %len(cmdString));

          if (qshErrorCode <> 0);
             errorMessage = %str( strerror( errno ) ) + NEWLINE;
             callp write(1: %addr(errorMessage)+2: %len(errorMessage));
          endif;

        *inlr = *on;
      /end-free

(The write() stuff is just there for debugging)

In order to make it run without using STRQSH, you'd have to set up the
descriptors 0,1,2 which are expected to always work for a Unix program.
RPG doesn't do that for you by default (though, ILE C or Java probably do)

Here's a message that I posted in the past that relates to dealing with
opening those descriptors.  In fact, you may find that entire thread
to be instructive.
   http://archive.midrange.com/rpg400-l/200204/msg00195.html

You could also open those descriptors using the Generic Terminal APIs,
but that'll leave you running two jobs (just like QSHell).  Unfortunately,
I don't have an example of this handy.


> This is really getting frustrating for something that should be
> simple...

Keep in mind that you're trying to use a programming language that doesn't
exist in Unix environments to run Unix commands on a non-Unix system.
It doesn't seem to me that it should be simple.  (Though, it'd be nice if
it were!)