the dreaded tty

[Jerome Salyers]

hi,
i'm running a script on HPUX 11 (not 11i) from the root crontab which has to switch users at one point to call a database script... i can redirect the output to /dev/null or what have you, but i'm still getting a mail telling me:
ttytype: could not open /dev/tty for reading
stty: not a typewriter

i've tried entering in the root and other user's profile

if [[ -t 0 ]];
then mesg -n
fi

but this doesn't have any effect... i also tested using

if [[ -t 0 ]];
then echo "hello\n"
fi

but this doesn't show up in the output mail... but if i run the script from the command line with

if [[ -t 1 ]];
then echo "hi\n"
fi

i see this in standard output...

can anyone give me some advise?

thanks in advance

jerome

i did run a te

[Robert-Jan Goossens · Accepted solution]

You could check these.

http://bizforums.itrc.hp.com/cm/QuestionAnswer/1,,0xd7983a1c04ffd61190050090279cd0f9,00.html

Kind regards,

Robert-Jan.

[Steven E. Protter]

cron jobs don't run with a terminal or stty settings.

If you want to make those messages go away, your script needs a TERM setting such as

TERM=vt100
export TERM

and a few of your stty settings as well.

You don't have to do anything about such messages though.

I am not able to understand your objective from your post.

P

[Jerome Salyers]

hi, steve...

the objective is stop mails that have only the message

ttytype: could not...
stty: Not a type...

in them... i have a mail server that receives mails from over 100 different servers who are all running similar cron jobs and if i'm getting 7 or 8 mails per server per day, all filled with this message, it's tedious...

besides, i feel that getting rid of the reason for the mails is much cleaner than just filtering them out...

thanks for your reply...

jerome

[Jean-Louis Phelix]

Hi,

Your idea is correct, but stty errors go to error descriptor.

This one generates a mail :

at now <<+++
su - user -c date > /tmp/out
+++

While this one (with error descriptor closed) doesn't :

at now <<+++
su - user -c date > /tmp/out 2>&-
+++

Regards

[Duncan Edmonstone]

I've said it before, and I'll say it again... I'm not a fan of using 'su - user -c cmd' in scripts when you can just do an 'su user -c cmd'

There's a couple of good reasons for this:

1. You don't get any irritating tty messages!

2. Your script doesn't stop working when the user adds something stupid to his .profile (like a menu!) or changes something in it.

'But I need the users environment variables' is the usual response to this suggestion... well just set em and export em before you call su.

So typically:

su - oracle -c "startdb.sh"

becomes:

export ORACLE_HOME=/oracle
export ORACLE_SID=PRD
su oracle -c "startdb.sh"

or something like that anyway...

I know your not on 11i but just be aware of this gotcha with 11i su command:


On HP-UX 11i there is an enhancement to the security mechanism of the su command which means that the environment variables LD_LIBRARY_PATH, SHLIB_PATH and LD_PRELOAD are not exported to the child process. There are two ways to get around this without resorting to using ???su ??? user ???c cmd???:
1. Just reset the environment variable, e.g:
su oracle ???c ???startora.sh???
becomes:
su oracle ???c ???export SHLIB_PATH=${SHLIB_PATH};startora.sh
2. or install patch PHCO_27781. This introduces a parameter SU_KEEP_ENV_VARS in the file /etc/default/security. Adding the following line to /etc/default/security would make su behave like it did in 11.00 and 10.20:
SU_KEEP_ENV_VARS=LD_LIBRARY_PATH,SHLIB_PATH,LD_PRELOAD

HTH

Duncan