Re: Qshell hidden input -- MIDRANGE-L

On Wed, 17 Sep 2003, Urbanek, Marty wrote:
> 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.

The API you're using detects whether descriptor 0 is connected to a
"Generic Terminal" (i.e. a terminal created with the Generic Terminal
APIs) the API you're calling doesn't know whether it's a different kind
of terminal or not...

The Qp0zSetTerminalMode() API is specific to the "generic terminal" APIs,
it cannot affect the input style of anything else -- so if you're not
running things in a Generic Terminal, you don't want to use that API.

The "is_a_term = Qp0zIsATerminal()" code is there for that purpose,
you won't run the Qp0zSetTerminalMode() API unless you're in a generic
terminal.

I suggest using a display file or an OS/400 command if you want to get
a password from the regular OS/400 command-line.


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

Yes... because QShell uses the Generic Terminal API for it's display.

>
> 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".

Hmmm... I can't explain that one...   Yeah, it looks like argv[0], but I
don't see why you'd get that on stdin...   strange.   Probably the fgets()
call is failing with an error (which I didn't check for) and therefore the
contents of the "pw" variable are just whatever happened to be in the area
of memory that got allocated to it.  (C doesn't initialize storage unless
you explcitly tell it to)

If you wanted to make the code more robust, you could check for an
error when calling fgets()...


> 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?

Yes, that should work, since you'd be providing the Generic Terminal,
which should then be detected and used correctly.    I don't see why you'd
want to go through all of that, though?  A display file would be much
easier.

Good Luck