Scripting issue where it wants a tty

[Bernie Vande Griend]

I have a third party application for imaging that comes with its own scripts/programs. Their scripts were written to be used interactively, but usually I can get around that by using a here document. "<I have one though that this does not work for, it is insisting to be tied to a tty.
Example:
MY_tool <logoff name=myname
ENDTHIS

I get the error, "Not a tty."
I keep thinking there may be another shell or perl method to trick the "MY_tool" program into thinking I'm really on a tty. Any ideas?

[Bill McNAMARA_1]

search for typewriter in the forums search!:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xcfb23fa720f3d5118ff40090279cd0f9,00.html

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x27ed5f260cafd4118fef0090279cd0f9,00.html

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x2697e7613948d5118fef0090279cd0f9,00.html

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x73e66c96588ad4118fef0090279cd0f9,00.html

Later,
Bill

[Krishna Prasad]

Does directing output to /dev/null help?

[Volker Borowski]

Hello,
Could it be that a .cshrc or .kshrc file executes a set command or similar.

You need an "if" clause in this script to avoid execution when run from cron.

Volker

[Ralph Grothe]

There is the prominent Tcl application Expect, written by Don Libes, which was particularily designed to automate processes that are bound to a tty, and otherwise can only be run interactively.

Myself not being a friend of Tcl, I would rather go for the Perl port of Expect.

You can get it (as all Perl goodies) from CPAN.

http://cpan.valueclick.com/modules/by-module/Expect/

In the readme above you will also find the URL of the Tcl original.

HTH
Ralph

[SHABU KHAN]

Bernie,

As stated earlier, you need validation routines like an if statement:

if [ "`tty 2>&1`" = "not a tty" ]; then
print "This is run from cron or ssh or whatever"
else
print "You are running from a tty"
fi

HOpe this helps !

-Shabu

[Bernie Vande Griend]

I didn't do a very good job of explaining this. I'm not running this from cron, ssh, etc, I'm running it straight from the ksh shell and still get the "No tty." message. It also doesn't matter if I use the csh or POSIX sh shells. It is not an issue with /etc/profile, .profile, etc. Think of it like this, I want to run an interact command non-interactively, one that normally needs a tty. Basically, from the same shell it works if I interact with it, but does not, if I try to send the commands strings right to it from the same shell. Sending output to /dev/null does not help, tried various forms of that already. Using expect may work, I have not tried that yet. Don't really want to install it on this system, but I may give it a try.

[support_5]

Hi,

I actually don't think this is a problem. Obviously in the script that gets called there is a command in there to run a "tty" or something like that. A tty command will give an error "not a tty" if run in the way you are describing, but it will not halt the script. The only problem I can see is if it tries to capture the output of the tty command to an environment variable and then examine this environment variable. This is because the environment variable will now say something like "not a tty" instead of something like "/dev/pts/34". If the script does this, then it needs to be modified to handle the fact that it isn't a tty. But if it doesn't do this, then I don't think it's going to cause a problem to the correct execution of the script. A bit game, I know.

For example, many .profiles use various tty commands. if yours does, then run the following and see what happens:
echo "" | . ./.profile
you will see that you get an error saying:
stty: : Not a typewriter
or
not a tty
but the .profile script still finishes okay.

Hope this helps.

- Andy Gray

[Bernie Vande Griend]

Sorry, it is a problem as it does halt the script. It is a security tool and it is apparently checking the tty before allowing it to run. The vendor told me there was no way to get around it, but I was hoping maybe I could trick it into thinking I was really running it interactively. Again, expect may be may best bet. Thanks anyway.

[Mark Greene_1]

have you tried directing output to /dev/tty? or if that did not work, actually determining to which tty the parent process is attached and directing the output there?

mark

[Krishna Prasad]

Would it be a bad thing if you send it to /dev/console ?

[Bernie Vande Griend]

Thanks Mark and Ron. I've tried every method of directing output I can think of including those you suggest, but it doesn't help.

Example:
My_tool </dev/console 2>&1
logoff user=myuser
ENDIT

Still get the no tty error wherever I direct the output.
Seems to me I need to trick the input somehow so it thinks I'm on a tty or /dev/console, etc, but I'm not sure if that's possible.

[Mark Greene_1]

have you tried it like this:

My_tool <TERM=vt100 # or whatever is appropriate
logoff user=myuser >/dev/tty 2>&1
ENDIT

HTH
mark

[Paula J Frazer-Campbell]

Hi

Lateral thinking

Run a cronjob on another server to telnet to the server with the script - login and fire up the script and when finished leave.


Paula

[Bernie Vande Griend]

Thanks Mark. Think of MY_tool as a program with its own language. Once you execute it, you can no longer use shells commands inside it, so the syntax you propose would not work.

Paula, thanks. Your idea was was my final option, which should work. In fact, I could even use the cron on the server itself to use expect and then telnet back to itself. I don't really like this idea because I'd have to put the password in the script and its very unelegant. But it should work and if I really need to automate this, its probably my only choice left. When I get the time to install TCL/TK/expect I'll give this a try.

[Jordan Bean]

Bernie, tell us again what type of program MY_tool is. Is it a unix shell script? Or is it a compiled binary? If it's a binary, this won't work.

If it's a shell script, it may be possible to circumvent the tty restriction without actually providing a tty and without modifying the script. Examine the script and look for the use of the commands tty or pty.

If it's a POSIX shell script, then it may check like this:

tty || exit

if tty -s
then
continue()
else
echo "Not a tty"
fi

if ! tty -s
then
echo "Not a tty"
exit
fi

if [ -t 0 ]
then
echo "You are out of luck here"
exit
fi

If it is using tty or pty, alias them to true or false (whichever is appropriate) before sourcing the script:

alias tty=true
. script <

[Bernie Vande Griend]

Sorry Jordan, it's a binary from a 3rd party vendor. This would be a piece of cake if My_tool was a shell script. Your information is good (as is everyone else's above) if you're dealing with scripts or cleaning up /etc/profile or .profile.

[Mark Greene_1]

have you contacted the vendor to see if there are specific environment variables or command line options you can set?

just a thought,
mark

btw, which vendor?

[Bernie Vande Griend]

Thanks Mark. I mentioned earlier that the vendor- FileNet, says there is no way to run the script non-interactively, it wasn't designed for that. And they have no options to get around it either. Thus I opened this post to see if I could use a UNIX shell trick instead.

[A. Clay Stephenson]

Hi Bernie:

After reading all this, I can see two options:

Plan A: Relatively easy but messy (and you've already mentioned it) Loop output from one tty port to another.

Plan B: Elegent but technically difficult. Write and install a pseudo-tty device driver so that the isatty(0) function returns 0 and thus the application thinks stdin is a tty device (because it is). The idea is that your can write to this pseudo device and store your input and then the read read from the buffer.

I did have to do something very much like this many years ago but I haven't done it in the HP-UX world.

Food for thought, Clay

[A. Clay Stephenson]

Hi Again:

Oops, I'm stupid, I meant to say so that isatty(0) returns a non-0 result.

Clay

[Carlos Fernandez Riera]

Redirection of standars file is an old trick.

I dont like to use /dev/console ( it could interact with syslogd). But i had do it some times using /dev/tty0p1 or similars.

New tecnichs is the use of a x-terminal device instead. You can open a window and just redirect to that /dev/... pts?

[Volker Borowski]

Hmm,

"it is a 3rd party binary".

Well I would expect a real binary to speak clearly to me if something is wrong, if it is well coded.
Conclusion: The message does NOT come from the program, but the program calls an operatingsystem-command via c-call "system" or so (stty, tset ....)
If you are lucky, "strings programname" gives you a clue what it is calling. May be you can patch this name with a hexeditor to call a program of yours, that does what the program needs, but fakes the tty flags....

No idea if this helps.
Volker

[Bernie Vande Griend]

Carlos, I know redirection is an old trick, but how do I do it? Redirecting the output doesn't help, are you talking about something else? I don't think an xterminal device would work either.
Volker: "if it is well coded". That's a good one. The code needs help which the vendor admitted. strings actually shows that "Not a tty" is inside the binary, that means they're doing their own checking. I see no external calls to other programs either.
Clay, you're on the right track. I don't have time or patience for plan B. I have gotten this to work using expect. I have to make my code much more complex for my issue, but this is probably the route I'll take. Thank you all for your help.

[Carlos Fernandez Riera]

Sorry ... sorry

Standard files:

standard-input file_despcriptor 0
standard-output file_despcriptor 1
standard-error file_despcriptor 2


my_program 0/dev/tty0p1 2>&1