.profile not executing in xterm via exceed

[support_5]

Hi all,

this is probably a no-brainer, but I can't seem to get this to work.

We have a few clients who run Hummingbird Exceed (an X server for windows PC's) and connect to a few HP boxes of ours. Now, the problems is that when they launch a tool that starts xterms for them etc, they cannot get thier .profile to be executed at login, stopping thier normal environment to be set up.

I think the way Exceed does this is via a rexec command. I've tried adding a '-ls' to the command line options for the xterm, but no use. Ive tried copying the .profile to a .kshrc, but no use either. So I'm stumped, how do you get the client to run the .profile etc at login time?

You can also tell Exceed to use different login protocols, like remsh, which I've tried, but they don't help either, exactly the same thing happens, they get a "$" prompt with no environment set up.

[[ One more thing to note on the side, in the section where you can tell exceed what command line options to send to the xterm, I've added things like "-bg seagreen" and such things, and I noted that the xterm that came up was still always plain black text against write background. Strange!!! And yet I know that the options do get issued, because the default option is the "-display xxx" setting, and when I modify that to another linux box, I find that the xterm does get displayed on that linux box, but other things like the -bg directive get ignored or something. ]]

Any ideas? (will assign points)

Thank you.

- Andrew Gray

[Michael Tully]

Your most likely referring to the .dtprofile file in the users home directory. The file does provide some good examples from within it.

[KCS_1]

Hi,


Did you set a variable DTSOURCEPROFILE in /.dtprofile?

# vi /.dtprofile
------------------------
DTSOURCEPROFILE = true
-------------------------


By default, the desktop doesn't read your standard $HOME/.profile or $HOME/.login file.


Have a look at more deatiled contents in /.dtprofile

[Steven E. Protter]

To pick a nit:

.profile does not execute. It sources. It asssigns environment variables. It walks like s script and talks like a script but doens't need execute permisssions.

Couple of issues. I notices when I upgraded from Hummingbird Exceed 7 to 9 that my environment worked much better. The Escape K and other keyboard functions worked better than before.

I'm not sure why, but the client you choose is a factor.

To be certain of environment variables however in CDE you need the .dtprofile set up and then you should get normal environment source at login.

SEP

[T G Manikandan]

Uncomment

DTSOURCEPROFILE=true

in $HOME/.dtprofile

[Jeroen Peereboom]

Andrew,

add a line
*loginShell: true
to files like
/usr/dt/app-defaults/C/Dtterm and Xterm.

(Usually I also add: *saveLines=1000).

This will change the behavior of these programs systemwide.

Be aware that if you start dtterm from CDE, you may have to redefine the CDE HOME session, otherwise you will still have 'old' terminal sessions.

.Xdefaults may also be a file to use.

Hope this helps.

JP.

[support_5]

Thanks for the responses.

Just to clarify, I am using plain old xterm with no window manager running (because exceed looks after the windows itself).

I managed to find a strange behaviour with exceed.

when I specified the command as "xterm -display @d&@" I wouldn't get the window reading the .profile, however, if I manually typed the ip address of my pc as in "xterm -display 192.168.1.2", it would work fine! So there must be something funny in the way exceed handles the variable "@d&@". So that's my workaround at the moment. Thankfully, all the pc's have static IP addresses, if they were dynamic, then this would be a problem!

go figure.

also, specifying the "-ls" directive to xterm didn't make any difference.

Thanks for the help!

- Andrew Gray

[Steve Lewis · Accepted solution]

I use PuTTY on PC and Linux for X-Windows these days, but previously with Xterm in Exceed I used this command (all in the command line) which does run the login shell:

xterm -d @d -ls +j -T `hostname` -n `hostname` -sl 500 -sb -cr blue -ms red

[support_5]

the @d seemed to fix whatever it was that was causing problems.... seems exceed was trying to use "@d&@", but replacing that in the -display setting with a "@d" seemed to be all that was required to fix it. Dunno what the go was there.

Also, a right click on the exceed task bar -> tools -> client startup -> new
opens a window which seems to work heaps better than the client wizard.

Thanks all.

- Andy Gray