Error "Not a typewriter" when printing from an application

[Chuck Sims]

One of my customers is running the following command from within an application:

lp -d

The file never seems to make it to the print queue and he gets the following error messages (from the syslog):

the print commandline return code: 35072
the print commandline return code: 25
the print commandline return code: Not a typewriter

According to the customer, this problem just started happening a couple of weeks ago.

The command works fine when run from the command line.

Does anyone have any suggestions?

Thanks...

- Chuck Sims

[James R. Ferguson]

Hi Chuck:

The infamous "Not a typewriter" message occurs when a process is not associated with a terminal but attempts to interact with it. 'stty' and 'tset' command found in standard $HOME/.profile files are common sources of the message when the 'profile' is sourced for a crontask. A correct work-around is to condionally execute interactive code thusly:

...
if [ -t 0 ]; then
...do terminal-oriented things...
else
...skip terminal-oriented things...
fi

Regards!

...JRF...

[Steven E. Protter]

My Oracle startup scripts do that all the time, because of the way Oracle writes their stock startup scripts.

I've learned to ignore it in those circumstances. I like the approach in the prior answer. To bad nobody ever taught Oracle how to write a shell script.

SEP

[Bill Hassell]

It may not be the Oracle scripts that have the problem. Most often, it is su - oracle which will login using standard /etc/profile and .profile files. The problem is that interactive terminal commands (tabs, stty, ttytype, tput, tset and so on) are not properly 'protected' in the profile files. Code like this should be added to /etc/profile and .profile files:

if [ -o interactive ]
then
eval $(ttytype -s)
tabs
... other interactive terminal commands ...
fi

Of course, if Oracle scripts have these commands imbedded inside their scripts, then the same rules apply.

As always, when things work OK from a 'standard' login versus a batch job, the culprit is the differences between a 'real' login with a controlling terminal versus batch jobs.

[Chuck Sims]

Aloha,

Thanks to those who responded to my question/problem. It solution to the problem turned out to be something completely different than was suggested. For what it's worth, here is what we found.

We are running CA's eTrust Access Control on the server that was having the problem. (In retrospect, I probably should have mentioned that in my original post.) eAC keeps very close track of who you are and what permissions you have. So, even if you su to another user (prdusr, in this case), eAC knows who you are and will only let you have the permissions appropriate to your account (fortunately, this doesn't apply to root).

The application that was having the printing problem had been stopped and restarted by one of our application engineers. The engineer had su'd to prdusr and started the application, but eAC knew that the enginer had started the process and assigned the appropriate ID to it. Unfortunately, the engineer's permissions weren't sufficient to allow the application to print. We fixed the problem by stopping the application and restarting it as root.

Again, thanks for your responses and suggestions.

- Chuck Sims