stty : : not a typewriter message

[Keith Bevan_1]

Below is an mail extract from one of my colleagues which I would be pleased to hear advice upon:-

HP-UX is producing a message
stty: : Not a typewriter (note the 2 colons!)
I want to suppress this properly, but can't see exactly where the culprit is. Do you know?

This occurs (a) when executing a !echo something-or-other from with an isql subshell, and (b) when executing a .!sh on a command line within vi.

[Ramkumar Devanathan · Accepted solution]

hi,

read this -

> This is caused by the 'stty' settings you have in
> your user profile (either ~/.profile or /etc/profile)
> Try commenting them out and then login again.
>
> Rcp is notorious for failing for this reason.
> For example, the following is an excerpt of the man page
> for csh on HPUX:
>
> WARNINGS
> The .cshrc file should be structured such that it cannot generate any
> output on standard output or standard error, including occasions when
> it is invoked without an affiliated terminal. rcp(1) causes .cshrc to
> be sourced, and any output generated by this file, even to standard
> error causes problems. Commands such as stty(1) should be placed in
> .login, not in .cshrc, so that their output cannot affect rcp(1)..

also, see this link -

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

HTH.

- ramd.

[James R. Ferguson]

Hi:

In lieu of unconditionally defeating the 'stty' logic found in a '.profile', you can make the execution conditional when the process is associated with a terminal, giving the "best of both worlds":

...
if [ -t 0 ]; then
stty ...
fi

Regards!

...JRF...

[Bill Hassell]

This is a VERY common problem, often found in running cron jobs and other batch jobs. The problem is that when su is used to login within a script, all the commands in the profiles are run (that's good) but some of them are meaningless in a batch job (ie, stty, tabs, ttytype, tput, tset, etc). So these commands must be protected. The sysadmin must rewrite the profiles to only run terminal commands IF the script has a real terminal attached. Put the test code into:

/etc/profile
/etc/csh.login
$HOME/.profile
$HOME/.cshrc
$HOME/.kshrc

and whatever additional shell profiles might be on the system. It is often useful to separate all the interactive commands into a separate file and source that file only if interactive.

[Jeff Crump]

Bill Hassell responded:

"The sysadmin must rewrite the profiles to only run terminal commands IF the script has a real terminal attached."

Bill: Can you give an example of HOW to do this (what the code would look like)?

Thanks,

Jeff

[John Payne_2]

Jeff,

Have the profile find out if the session is interactive:

case $- in
*i* ) export INTERACTIVE=/sbin/true
;;
* ) export INTERACTIVE=/sbin/false
;;

esac

Then you can you can change you terminal commands:

if [$INTERACTIVE]
then
/sbin/stty {insert whatever here}
etc.
etc.
fi


Hope it helps.

John

[Jeff Crump]

John:

Thanks. CAn I tell jsut by looking at the profile?

The profile looks like this:

# @(#)B.11.11_LR

# DEFAULT user .profile file (/usr/bin/sh initialization)

# Set up the terminal:
if [ "$TERM" = "" ]
then
eval ` tset -s -Q -m ':?hp' `
else
eval ` tset -s -Q `
fi
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs

# Set up the search paths
PATH=$PATH:.

# Set up the shell environment
set -u
trap "echo 'logout'" 0

#Set up the shell variables
EDITOR=vi
export EDITOR

# Set up for application
#. abcde_env

The last line should be uncommented but it's commented because of the errors I was getting ... this _env actually puts up some screen options and I'm not sure how to pass the screen answer to it via a script!

For example: After I su to this person and get their profile (with the _env) a screen comes up for them to choose 1, 2, 3, 4, or 5.

I also need to figure out how to pass a choice ... any help there as well?

Thanks!

Jeff

[bhavin asokan]

hi,

similar type problem was there in my system.i think system is not able to determine the terminal type.
then i included the following line in my .profile

export TERM=vt100

the problem got solved.

regds,

[Bill Hassell]

As John pointed out, you need to encapsulate or protect every interactive terminal command in /etc/profile and .profile. Let's start with your example .profile:

1. Test for interactive in /etc/profile as in:

case $- in
*i* ) export INTERACTIVE=/sbin/true ;;
* ) export INTERACTIVE=/sbin/false ;;
esac

2. Put all the terminal (interactive commands inside an interactive section:

if $INTERACTIVE
then
... terminal code
fi


3. GET RID of this tset code:

# Set up the terminal:
if [ "$TERM" = "" ]
then
eval ` tset -s -Q -m ':?hp' `
else
eval ` tset -s -Q `
fi
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff
tabs

and replace all of the above with:

if $INTERACTIVE
then
eval $(ttytype -s)
stty erase "^H" kill "^U" intr "^C" eof "^D"
stty hupcl ixon ixoff -parity
stty susp \^Z dsusp \^Y
tabs
fi

Now, the interactive (terminal) commands ttytype, stty and tabs will not be run if the script is being run in batch (ie, cron or at) . The tset command is deprecated (obsolete) for modern terminals and emulators. Use ttytype and remove all tests concerning the $TERM value. $TERM should never be hardcoded. Use the ttytype command to ask the terminal what it is.