su to different users, and run a command...

[Hanry Zhou]

I have the following script:

for ID in `cat users`
do
su - $ID<<-EOF
netstat -rn
EOF
done

The issue with this cripts is when I run it, and su to the next user, it always stop at the line of "TERM = (hp)", and I have to hit "RETURN" to let it continue.
I don't know where is this line coming from, and how to let the script continue without hitting "RETURN".

Thanks!

[Steven E. Protter]

su - username -c "commandline"

make sure TERM is set in the script.

SEP

[Sanjay_6]

Hi,

The term entry comes from the profile of the user. To remove that from happening, change the profile to disable evaulating TERM variable. Do this under the section "setup the terminal" in the .profile.

Hope this helps.

Regds

[Hanry Zhou]

Steven,

You did not understand my question.

For a reason, I can't use su - user -c "commandline", I have to do the way I showed you in last message.

Why I need to setup TERM, and where I should do that.

[Bill Hassell]

This is due to su - where a full login (run /etc/profile and .profile) is performed. That's good in that you'll inherit the same environment as a normal user login, but /etc/profile *and* .profile must both be rewritten to be 'batch safe'. This also goes for cron and at too. The request is coming from ttytype or tset, tools that try to identify the terminal. But in batch mode, you want to bypass these tests. The easiest is to use tty to test if there is a controlling terminal and if so, bypass the real-terminal-only code as in:

if tty -s
then
eval $(ttytype -s)
tabs
...etc...
fi

This avoids error messages like "not a typewriter" and hangs waiting to automatically identify a terminal using tset or ttytype.

[Hanry Zhou]

Sanjay,

There are a lot of users involvied, so by changing every one of .profile is not practical. Besides, I doubt that is the cause. Since there is no such line "TERM = (hp)" in several user's .profile. I've just checked out.

[Hanry Zhou]

Bill,

Yours sounds the solution, although I don't quite udnerstand it.

Where I should put your codes, in my scripts?
Where in my scripts?

[A. Clay Stephenson]

No, the test goes in each user's .profile.

[Steven E. Protter]

After reading the thread, I understand it less.

for ID in `cat users`
do
su - $ID<<-EOF
netstat -rn
EOF
done

can it be changed to:


for ID in `cat users`
do
su $ID<<-EOF
netstat -rn
EOF
done


That will negate the need to load the user profile and the TERM variable. Bill's code in the .profile would allow your code to work unmodified.

SEO

[Bill Hassell]

The line TERM = (hp) is a string inside the ttytype program. You don't have to change every .profile since the 'standard' .profile tests for $TERM and if not set, will run tset. So you can protect the ttytype command in /etc/profile for everyone (strongly recommended). Be sure to protect any other interactive commands you may have added. It turns out that tabs will default to hp internally if TERM is not set or set to an unknown value.

A couple of notes about profiles: the Bourne (/usr/old/bin/sh) and POSIX shells (HP-UX sh and ksh) will run /etc/profile first followed by $HOME/.profile, assuming you are using the default files (copies are kept in /usr/newconfig). So global changes are best kept in /etc/profile. This true for normal telnet logins as well as su - logins.

Now since users can change their .profile, I like to use a standard .profile and keep it in /etc/skel. This location is where SAM and useradd get the default files for a new user's $HOME directory. Now, when a user decides to experiment with .profile, I simply move their broken .profile and put the default one (/etc/skel/.profile) back (or have them do it).

Now for workstations (ie, Xwindows and VUE/CDE, etc), it gets complicated. The default action for xterm,hpterm and dtterm is to bypass all profiles (don't ask why) so these initialization files are skipped. Now you can edit .dtprofile and change DTSOURCEPROFILE=true but this still skips /etc/profile completely. The best fix is to restore the 'normal' login procedure to the Xwindow terminals by specifying -ls when starting xterm, hpterm or dtterm, or (even easier), do this in the $HOME directory of the machine that is running Xwindows and supplying the terminal programs:

echo 'loginShell:true' >> $HOME/.Xdefaults

There are other features you can put into .Xdefaults--see the man pages for the terminal emulators.