how to set environment vars at GNOME terminal startup ?
 

Hi,

I have the default shell for my user /bin/ksh and would also like the ~/.profile get executed when I start a new terminal but can not figure out how to achieve this. I created a new profile and tried some versions with 'Run command as a login shell' and 'Run a custom command instead of my shell' without success. Could somebody give me specific info on how to do this?

Janis

I don't believe this! Nobody has this working? Please!

It's possibly quite simple, but I am a novice in things OpSys, so please help ...

As far as I am aware, ksh behaves the same as Bourne shell and bash
and the user's ~/.profile is sourced if the shell is a login shell.

Make sure you have the magic line like

#! /bin/ksh

or

#! /usr/bin/ksh

depending on the location of your ksh binary

at the top of your .profile, and that the profile is owned by the user
and that it is readable by the user.

Put a line after the magic first line with

echo "This is the profile of the user"
sleep 2

in the file, then fire up, as that user, an xterm, konsole, whatever with the option of a LOGIN shell and see if the message appears in the xterm, konsole, or whatever.

If that works okay, then you know that the .profile is being sourced for the xterm, konsole whatever LOGIN shell invocation and you can start adding your

ENVIRONMENTAL_VARIABLE="this is the value"
export ENVIRONMENTAL_VARIABLE

stuff to the .profile

Remember that the profile only get sourced for LOGIN shells, so if you want to do it for non login shells you have to put your settings in the .kshrc (check the man page for ksh).

Hope this helps.

Thanks for the feedback! I tried what you suggested. The tip with echo/sleep is nice ... The problem appears to be that my ~/.profile is not getting sourced, and .kshrc is not getting sourced either (with or without the magical line at the top)

To re-state the question: how does the environment get set up when I start a new console (interactive shell, that is) as a user 'kuser' whose (login ?) shell in /etc/passwd is /bin/ksh? Which files get sourced when I start this new console ?

I tried changing kuser's shell to /usr/local/bin/ksh (to which /bin/ksh has a symlink to), but this did not help either.

Help, please ?

When you did the test with the echo message; sleep 2
in your $HOME/.profile, did you see anything in your X terminal emulator?

Did you make sure that you started the X terminal emulator as
a login shell? xterm -ls



Which version of the Korn Shell are you using?

The commercial variant or the Public Domain ksh?

I only have access to documentation for the public domain version.

man ksh should provide you with all the information you need.

For the Public Domain version

a ksh will source /etc/profile and then ~/.profile
and then if the ENV variable is set (usually to something like ~/.kshrc)
it it sourced according to the following rules.

[I forgot that .kshrc only gets sourced if you have ENV set to point to it]


If the ENV parameter is set when the shell starts (or, in the case of login shells, after any profiles are pro-
cessed), its value is subjected to parameter, command, arithmetic and tilde substitution and the resulting file (if
any) is read and executed. If ENV parameter is not set (and not null) and pdksh was compiled with the DEFAULT_ENV
macro defined, the file named in that macro is included (after the above mentioned substitutions have been per-
formed).


However, one must also ask the question is the ksh which you are using
been set to restricted mode by the administrator?

A shell is restricted if the -r option is used or if either the basename of the name the shell is invoked with or the
SHELL parameter match the pattern *r*sh (e.g., rsh, rksh, rpdksh, etc.). The following restrictions come into effect
after the shell processes any profile and $ENV files:
· the cd command is disabled
· the SHELL, ENV and PATH parameters can't be changed
· command names can't be specified with absolute or relative paths
· the -p option of the command built-in can't be used
· redirections that create files can't be used (i.e., >, >|, >>, <>)

Ok, my confusion has slightly cleared up. The login shell (/bin/ksh -- public domain korn shell) for 'kuser' actually sources
1) /etc/profile
2) ~/.profile

and all the environment variables (including PS1 in ~/.profile) get set upon login. I checked this using runlevel 3.

Question(s): how to get the same environment variables into a Terminal that I open from GNOME graphical environment? As a secondary question -- who eats the environment variables between login and opening of the Terminal; why are the environments different?

I hope the question is understandable. Please do not tell me -- ". ~/.profile" in the Terminal. I want to have it working automagically!

Janis

I don't use ksh and I'm just trying out gnome now but for bash and flux and rxvt and Slack - a lot of differences) I have .bash_profile get sourced as a log in. So I start rxvt as 'rxvt -ls' to make it a log-in shell. If I want similar effects without it being a login shell, I can create a .bashrc and that, I think, gets sourced if I just run 'rxvt'. Like I say, it's all different stuff and I suspect I'm being monumentally dumb because if this is right someone would have said it by now. But maybe that'll help point you in a useful direction, anyway. It's got to be in the ksh man pages, anyway.

-- Oh, and I mean just to put 'rxvt -ls' in whatever menu or launcher or whatever you start your xterm from - like you say, you don't want to have to type it every time.

Here's the solution:

1) Open a terminal
2) go to Edit / Profiles
3) click New
4) enter a name and click Create (keep Base on Default)
5) click on the new profile and then click Edit
6) go to the Title and Command tab and
6.1. select Run command as a login shell
6.2 select When command exits Exit the Terminal -- so you can leave the Terminal by typing 'exit'
7) click Close
8) select the new profile in Profile used when launching a new Terminal
9) click Close

Now open another Terminal and you will have the same environment in it as for a login shell.

There is an explanation of this here
http://www.linuxquestions.org/questi...erminal+prompt
(bash only, though)

How the /bin/ksh non-login shell works, I still don't understand.

I am happy with getting a real prompt now, though.

Janis

In order to get the X Terminal emulator shell to have the same environment variables, it must also source $HOME/.profile. The way to get it to source
$HOME/.profile is to make it a login shell with the appropriate command
line flags when it is invoked. If the terminal is being invoked from a menu,
then you have to edit the menu to add the command line flags.

Does that make sense?

Now if you have followed that, there is a trick we can play using the ENV
variable.

If you always want your $HOME/.kshrc to be sourced regardless of whether or not the shell be it in an X Terminal Emulator or not is login shell, then it can be done.

When the user logs in under the Graphical Display manager that is
a login shell by definition so /etc/profile and $HOME/.profile will
be read. Presumably because you are not EXPORTing all your
variables in your $HOME/.profile, these variable will not be seen
in children of the parent login process. Why you are not EXPORTing
these variables, I do not know, since if they were, then this whole
problem should not have arisen.

But regardless of that, if you put an entry in your $HOME/.profile

ENV=$HOME/.kshrc
export ENV

then the ENV variable will be seen in all child processes.

Going back to what I previously posted from the ksh man page

If the ENV parameter is set when the shell starts (or, in the case of login shells, after any profiles are processed), its value is subjected to parameter, command, arithmetic and tilde substitution and the resulting file (if any) is read and executed.

regardless of it being a login shell or not, the new shell will read
and execute the file pointed to by ENV.

Hence if you put your interactive non-login shell variables in your .kshrc they will be set, provided ENV is set and exported from $HOME/.profile.

BE careful never to put any terminal specific commands in your .kshrc
since this file will be executed regardless of whether the process is
attached to a terminal (eg process invocation by rsh or ssh.)

And if you do need to do then always do a test

tty -s
status=${?}

if [ ${status} -eq 0 ]
then
<tab> do tty specific commands here
fi

NOBODY EATS VARIABLES FOR BREAKFAST! :+)
Nobody prefers Cheerios (or subsitute favorite breakfast cereal here).

Here's how it works -- Unix is a land of processes.

There is a parent process in which variables are set, in the case of a ksh login in /etc/profile.

The parent spawns a new process. In fact it spawns lots and lots.
Every time you fire up an X terminal emulator, new processes
are started -- the X Terminal emulator itself and the shell contained
within it!

Child processes inherit the environment of their parents EXCEPT
that shell variables are only inherited if their parents EXPORT the
shell variable.

Here is a quick test.

Type

$ variable1="oranges"
$ export variable1
$ ksh

You are now in a new ksh within the parent ksh

now type

$ echo $variable1

You will see the value "oranges"

now type

$ variable2="apples"
$ ksh

You are now in a new ksh within the child ksh of the original ksh

$ echo $variabl1
oranges
$ echo $variable2
$

You see nothing. the variable does not exist. It was not exported.

Now before you forget where you are

$ exit

leaves the child of child shell

$ exit

leaves the child and back to the very original shell.

So does this illustrate why some variables are disappearing?

You expressed the question in clear and concise terms,
which is what was required. I just hope my explanation was clear enough
for you. For further help consult man ksh, or may I mention the O'Reilly
book "Learning the Korn Shell".

Only lazy, unthinking, unimaginative types come back with answers like that. The whole point of software is to make life easier not give you more work to do. There is nearly always a way to get such things to work, but you have to do some work to get them to work :+)

Oh and by the way I hate ksh; bash is okay, but I am a diehard tcsh person!

And to quote a friend of mine

"We are all children of init."

Do a ps -adef | less on any Unix SysV system (or ps -auwx | less on any
Unix BSD system) and you will see that the very first process with pid 1 is init. Every other process is a child of that.