Hummingbird Exceed setup?

[Michael D. Zorn]

(Not sure if this is the best forum - a search didn't turn up anything useful anywhere)

I'm connecting to an HP-UX 11.11, rp3410, with Exceed. When I open a terminal window, it looks like the .profile and the /etc/profile aren't being read. 'env' shows a lot of variables, but I'm not sure where they come from. I put print statements in both profiles.

Is the system supposed to read them when an Exceed terminal starts? I need to have some extra environment variables set for the database.

[DCE · Accepted solution]

If you are coming in via a graphical interface, you need to either put your customizations in $HOME/.dtprofile, and execute your .profile as the last line in the .dtprofile.

Gtraphics use .dtprofile, and by default do not read the .profile

[Marvin Strong]

As stated if you are using exceed to start CDE or you need

DTSOURCEPROFILE=true in ~user/.dtprofile

[Michael D. Zorn]

OK, that seems to work. The database needs a few environment variables, and in the old days I just put them in /etc/profile so all the users could get at them.

(The old system (10.02) doesn't have a .dtprofile, and reads /etc/profile)

Am I going to have to source /etc/profile to get user-wide environment variables?

[Bill Hassell]

The behavior you are seeing is absolutely normal and extremely annoying for system administrators. A 'normal' login using telnet (and a normal shell like POSIX sh or ksh) will run /etc/profile followed by .profile but Xwindows is not a normal login at all. Instead, your local PC is 'stealing' a copy of dtterm (or xterm or hpterm) from your rp3410 and telling it to display the results on your PC, hence the name "display server" in reference to your PC screen.

In the old days of X11 (Xwindows), there were strange environment variables that could get in the way of Xwindows code when running terminal emulators. Note that the designers of Xwindows had no design goal to take a graphical environment and reduce it down to a simple character interface (ie, the *term programs). So CDE (and VUE and other desktop managers) would eliminate the problem by not logging in normally, that is, bypass /etc/profile and .profile. Later revisions of CDE added the DTSOURCEPROFILE variable but this is only a 50% solution (as you have already seen).

So the only way to msake Xwindow emulators work correctly is to override the no-login behavior with an Xwindow resource variable called *loginShell. The * is a special character that will match the various terminal emulator program names. So the fix is to do this in every user's $HOME directory:

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

Now, you will see a 'normal' login.

...which begs the question: why not run a local telnet session from the PC and dump all that Xwindow junk (and overhead on the LAN and large RAM usage in the PC, etc?...

[Michael D. Zorn]

Quick reply to "why not dump all that junk": well, I suppose "because it's there". I do use telnet most all the time (it's faster and more straightforward), but using Exceed makes it look like it did in the even older days when our 700/RX workstations were running. Evidently HP has abandoned the notion of workstations running GUIs. Then there's the attraction of multiple, colorful GUI windows. And the users who see PCs running windows and want the same thing here.