Re: Qshell hidden input

Scott,

Thanks a million. That helps a lot. I have a followup question if you
wouldn't mind.

This program works as described when called from a shell script (which IS
what I need). However, in experimenting with it, I found that it does not
work the same if you call it directly from an OS/400 command line, i.e. CALL
GETPW. In this case, the input is still accepted and processed correctly,
but it is echoed to the screen.

The literal reason is because is_a_term is not true in this scenario, but
why? I don't understand why descriptor 0 "is not connected to a terminal".
The fgets and fprintf still function, therefore stdin/out are still talking
to my terminal (somehow), but obviously not the same way as when I am in a
qshell script.

If I call the program directly from qshell (but without a script) i.e.
/qsys.lib/qgpl.lib/getpw.pgm then again, it works.

If I call the qshell script from an OS/400 command line, i.e. QSH
CMD('/home/mydir/getpw.sh') it runs, but the fgets (stdin) is satisfied by
what appears to be the name of the C program and the library in which it
resides, almost like argv[0], like:
"QGPL                           GETPW".

Based on your explanation of the "2-job approach", is this behavior because
without the interactive qshell session (with or without shell script) there
is no existing "Generic Terminal" whose descriptors we can "borrow"?

Would it then follow that if I wanted to do the same thing from CL instead
of shell script, that I would have to go through the process of creating a
generic terminal, via Qp0zStartTerminal, Qp0zRunTerminal, (other stuff),
Qp0zEndTerminal?

Thanks again,
-Marty

------------------------------

date: Fri, 12 Sep 2003 14:44:58 -0500 (CDT)
from: Scott Klement <klemscot@xxxxxxxxxxxx>
subject: Re: Qshell hidden input

...
The way that QSHELL works is that there are two jobs.  The first is your
interactive job (where you see the prompt, etc) the other is a background
job where teh actual programs are run.   They are connected by descriptors
0,1,2 (stdin, stdout, stderr) so that anything you type goes to stdin of
the other job, anything written to stderr or stdout gets printed on your
screen.

However, if you use a DSPF or a CMD object with the "system" command,
they do not attempt to use descriptors 0,1,2 for screen i/o, but rather
they try to talk to the screen directly.

What all of this means is that, when you do a "system" it runs in the
background (non-interactive) job.  That means that interactive programs
will fail.

...

The QSHELL uses something called "Generic Terminals" in order to implement
that 2-job approach I was discussing earlier.   There are Generic Terminal
APIs in the Information Center (Under "Unix-type APIs") that can do what
you're trying to do.

Here's a sample program that reads hidden input, and then echos it to
stdout.   Assuming you compiled this program into QGPL and called it
"GETPW", you'd use it in a script like this:

MYVAR=`/qsys.lib/qgpl.lib/getpw.pgm`

(make sure you use backquotes, regular quotes won't work)

Here's the sample code:

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

#define MAXPW 80

int main(int argc, char **argv) {

    char pw[MAXPW+1];
    int len;
    int is_a_term;

    is_a_term = Qp0zIsATerminal(0);

    if (is_a_term) {
       Qp0zSetTerminalMode(QP0Z_TERMINAL_INPUT_MODE,
                           QP0Z_TERMINAL_HIDDEN, NULL);
    }

    fgets(pw, MAXPW, stdin);

    len = strlen(pw);
    while (pw[--len]=='\r' || pw[len]=='\n') pw[len]='\0';

    if (is_a_term) {
        Qp0zSetTerminalMode(QP0Z_TERMINAL_INPUT_MODE,
                            QP0Z_TERMINAL_PREVIOUS, NULL);
    }

    fprintf(stdout, "%s", pw);

    return 0;
}