Re: Weird problems with Qp2RunPase

[Scott Klement <rpg400-l@xxxxxxxxxxxxxxxx>]

Hi Charles,

> Now what's weird is that if instead of using the short option form,
> ie. -o, I try to use the long option form, --output, I get an error
> message saying invalid option.

Heh...  you didn't post your code for the long options, you posted your 
code for the short options -- the one that worked -- which makes it hard 
for me to tell you what you're doing wrong with the long ones.  But, I 
can make an educated guess...

> At the least, I get the error with the -o and the -r options.  Perhaps
> because the long options have a space, '--output myfile.gpg'.

Yep... that helps to confirm that my guess is correct :)

> Ok I seemed to have a partial answer....
> When I used '--output=myfile.gpg', it worked!

That also helps confirm it...

You probably already know this, but...  Just to make sure we're on the 
same page, what you're doing is running a program.  When you type this:

     gpg --no-tty --yes --batch -oSomeFile

That's the Unix way of performing a program call. It's equivalent to the 
following command in our traditional i5/OS environment:

     CALL PGM(gpg) PARM('--no-tty' '--yes' '--batch' '-oSomeFile')

So it's nothing more than a program call with parameters passed.  That 
might seem strange to an i5/OS programmer, where a *CMD object would be 
required to call a program without using the CALL command -- but in Unix 
there's no such thing as a *CMD object.  A command name is nothing more 
than a program that's run.

In the absence of any quotes (which is the case here) the Unix shell 
breaks up the parameters by any spaces or tabs in the command line. So 
each time you see a space in the above Unix command-line, it separates 
it into a another parameter.

Okay -- on to your program....

>          parms(1) = ENCRYPT_PROGRAM + x'00';
>          parms(2) = '--no-tty' + x'00';
>          parms(3) = '--yes' + x'00';
>          parms(4) = '--batch' + x'00';
>          parms(5) = '-o' + destFile + x'00';
>          parms(6) = '-e' + x'00';
>          parms(7) = '-r' + recipient + x'00';
>          parms(8) = '--no-permission-warning' + x'00';
>          parms(9) = sourceFile + x'00';

You'll note that when you use this API, there's no Unix shell involved. 
 You are invoking the program directly, rather than going through a 
shell like you are on the command line.   There's no code to separate 
that parameters out by the spaces in them.  YOU have to do that by 
putting each parameter in it's own array element.

And you've done that in the example above.

But if you change the example to this:

          parms(5) = '--output ' + destFile + x'00';

Now you've created a problem.  A Unix shell would not have passed both 
--output and "destFile" in the same parameter.  Why not?  Because 
there's a space between them.  So a Unix shell would've done this instead:

          parms(5) = '--output' + x'00';
          parms(6) = destFile + x'00';

Because of the space, it separates it into two parameters.  While GPG 
COULD have been written to handle this situation, it wasn't, because it 
was designed with the assumption that it'll be called from a Unix shell.

Personally, I find it easier to use the shell included with PASE, and 
let it handle the parsing of the command for me.  That way, I don't have 
to muck around with separating the parameters according to these rules. 
To do that, make the first parameter be the shell rather than the 
program.  Use -c for the second parameter (this tells the shell to run a 
command) and pass the whole command string, just like you'd type it 
interactively, as the 3rd parameter.

For example (untested):

          parms(1) = '/QOpenSys/usr/bin/-sh' + x'00';
          parms(2) = '-c' + x'00';
          parms(3) = 'gpg --no-tty --yes --batch'
                   + ' -o' + destFile
                   + ' -e'
                   + ' -r' + recipient
                   + ' --no-permission-warning'
                   + ' ' + sourceFile + x'00';

In this circumstance, the actual program you're running is the shell 
itself (-sh is the PASE version of the Korn Shell).  You're only passing
two parameters to the shell.  -c to tell it to run a command, and the 
WHOLE command string in the 3rd parameter (that's why you only need to 
add x'00' once, at the end of the whole command string)

This is basically the Unix equivalent of calling QCMDEXC.  You send a 
whole command string in one parameter, and it'll take care of parsing 
the command and passing the right parameters to the program.  It'll also 
search your PATH for the program, so it's no longer necessary to specify 
a fully-qualified path for the 'gpg' program name.  (though, you can if 
you really want to.)

And using this technique, the long command options should work just 
fine, because the shell parses them, just as it does when you type the 
command in the command line.

Granted, this technique does use slightly more CPU resources, so if you 
need to run this thousands of times in a loop, your original code would 
be more efficient.  But for only a dozen or so calls, you won't even 
notice it.

Hope that helps...