Access hpux remotely

[Matti_Kurkela]

Yes. Download the screen source code package here:

http://hpux.connect.org.uk/ftp/hpux/Sysadmin/screen-4.0.3/screen-4.0.3-src-11.11.tar.gz

The filename seems to indicate that the package is for HP-UX 11.11. Don't worry about that, you'll need just one file from that package, and that file can work in all HP-UX 11.* versions.

Find the "screeninfo.src" file inside it (located in screen-4.0.3/terminfo/screeninfo.src)

and add the information inside it to your system:

gunzip screen-4.0.3-src-11.11.tar.gz
tar xvf screen-4.0.3-src-11.11.tar
cd screen-4.0.3/terminfo
tic screeninfo.src

After that, your system should be able to recognize the "screen" terminal type, and commands like "clear", "top" etc. should work within the screen sessions.

Apparently the creator of the screen-4.0.3 .depots has forgotten to include a post-install script to the depot that would add the terminal type information automatically.

[Dennis Handly]

>forgotten to include a post-install script to the depot

More accurately a configure control script since it would have to be done on each NFS diskless system (if those still existed :-).

[chindi]

Hi Matti ,

You were spot on again.

Thanks again.

One small nagging thing alias set .profile is not working , any reason why ?

For ex alias c ='clear'  not working for a user 

[Matti_Kurkela]

If the user is configured with a different shell, e.g. tcsh or the (scummy) csh, it might run another login script instead of .profile.

If the HP-UX default /usr/bin/sh shell is used, the actual login shell will execute .profile, but the encapsulated sub-shells started by script or screen might not. Environment variables can be inherited from the (grand)parent process by the subshell, but shell aliases cannot be inherited that way.

If it is not harmful to run the user's .profile twice, the easiest workaround would be to add

export ENV=$HOME/.profile

 in the user's .profile. This tells the sub-shells to execute .profile too, so they would also get the alias definitions.

But if the user's .profile contains something that must run only once per login, a slightly more complicated solution is needed.

For example, if the user's .profile contains settings that add something to existing environment variable values, like "export PATH=$HOME/bin:$PATH", making sub-shells execute .profile would cause the user's PATH to contain those elements two or more times (e.g. the PATH value in the sub-shell would be something like /home/username/bin:/home/username/bin/:..). At best this is unnecessary repetition, and it might actually be harmful with some application-specific environment variables.

In that case, the alias definitions must first be moved into another file, for example ~/.sh_aliases.

Then, the .profile should be set to read the .sh_aliases file, and set the ENV variable so that the sub-shells will read the .sh_aliases file only:

# read the aliases from a separate file
. $HOME/.sh_aliases
# make the sub-shells read the aliases file too
export ENV=$HOME/.sh_aliases

After this modification, any commands that must run at login only should go to .profile, and commands that must run at each time a sub-shell is started should go to .sh_aliases.

[chindi]

Thanks Matti .