[Nottingham] TMPDIR weirdness with X logins

[Robert Postill]

Robert,
Sorry, I don't think I answered your question, the why is that the 
xterms run in subshells so that they never have the same priority as 
your original login shell becasue that could jepordise the system 
resources (see my comment about daemons in the last e-mail).  Certainly 
I had a user once who started up numerous shells that automatically sent 
e-mails (due to his human virus status :) which he picked up from 
outlook.  He did this with a book resting on the keyboard (over his 
eterm shortcut F7 key if I remember right) and ended up slowing the 
exchange server to a crawl.  So I can see why you would want a once-only 
type of environment and then a seperate environment for subshells.

I have been bitten before and ended up doing the following:
1. Stick the stuff I want all the time in .bashrc
2. Use source .bashrc in your .bash_profile to pull in the settings from 
c.bashrc.  They will be executued at the same level as those in your 
bash_profile and therefore not lost.
That should keep parity across your files.  It does actually have an 
upside in that if you take something like Oracle SIDs and paths for 
specific groups then you can source from any file and pop it in your 
.bashrc or .bash_profile.  An old colleague did that for oracle 
developers, he tested their group was dba then sourced the file 
containing their settings from /etc.

I don't have any references, I picked a lot of this up from others.  I 
can say that a quick Google did not turn up anything usefull but I'm 
sure you did before mailing the list.  The only other thing I can say is 
that for apps that depend on shell variables they should have something 
akin to oraenv, which helps a lot in some Oracle environments by 
organising the questions you need to answer and then prepping your 
environment afterward.

Hope that helps.
Robert.

Robert Davies wrote:

>On Thursday 11 Sep 2003 09:08, Robert Postill wrote:
>  
>
>>This is one of those peculiarities that sometimes come along almost with
>>the express job of making you look stupid :).  Basically it's a question
>>of login shell or not login shell.  When you login to a console, you're
>>in a login shell and therefore get the bash_profile settings.  When
>>you're using a window manager (and it should be true for all window
>>managers) and you kick off konsole or xterm or whatever, that's a
>>subshell.  The login shell is designed to be run once, subshells many
>>times per session with the machine.  For example your login shell may
>>contain a diary/alert daemon, that gets run once and stays resident for
>>your session.  You wouldn't want that run every time you kicked off an
>>xterm session, you'd just be plundering the machines resources. So you
>>get a subshell.
>>
>>Clear as mud now? :)
>>    
>>
>
>I know the bash_profile is getting run once (remember original reference to 
>debug log), even though login is via kdm.
>
>Because of the difference generally ENVIRONMENT should be set in .profile / 
>.login, and not .bashrc / .cshrc files, so programs can bequeath 
>modifications to sub-processes where needed.  There were options on DEC  
>Ultrix and Sun/BrokenWindows to select login shell for each terminal window, 
>though this is wrong for other reasons (where a user really wants something 
>run only on initial login and logout eg) find jobs clearing up files).
>
>What's happening, I think is that xterm and other emulators, have black 
>listing of some environmentals.  These programs need suid/sgid privileges to 
>write to utmp & wtmp.  It's right to alter the environment when you have 
>privileges to avoid security problems eg) LD_PRELOAD etc.  It would be though 
>a lot more right, for these GUI programs starting shells for users, to 
>restore the original settings, plus their essential modifications eg) 
>TERM=xterm, after they have permanently revoked their suid/sgid-ness, in the 
>child fork that's about to exec the non-login shell.
>
>Actually bash only runs .bashrc for interactive processes, which avoids the 
>csh problem where shell scripts have forgetten -f, and could have operation 
>interfered with by environment assignments in .cshrc (it's traditional to 
>test if shell is interactive there to avoid issues).  So that mitigates the 
>problem, though if I start a sub-shell like this :
>
>env TMPDIR=/var/tmp PATH=/bin:/usr/bin \
>LD_LIBRARY_PATH=/opt/broken_commercial_pkg/lib bash
>
>I really do not expect or want, LD_*, PATH and TMPDIR to get reset anyway, by 
>.bashrc.  Sometimes it's nice for a program system to just setup necessary 
>environment, when you need to use it and return you to an interactive shell, 
>rather than force, you to carry it's baggage set per-user in every single 
>shell they ever start.  Without that you can get conflict problems, where 3rd 
>party packages have command name clashes.
>
>I thought someone on the list, might happen to have been bitten by this stuff 
>and know, or have a reference on the web to some info, which explains what 
>get's modged, by what and why.
>
>Rob
>
>
>_______________________________________________
>Nottingham mailing list
>Nottingham@mailman.lug.org.uk
>http://mailman.lug.org.uk/mailman/listinfo/nottingham
>
>
>  
>