On 20Mar2006 13:40, mikhael goikhman <[EMAIL PROTECTED]> wrote:
| On 18 Mar 2006 00:21:32 +0100, Michelle Konzack wrote:
| > This is a realy weired problem and I do not know, WHO to contact!
| > OK, I think, now, its not a fvwm error, but do you have an idea
| > how to trackdown this issue?
|
| I don't know. Before my previous answer, I actually tested it, and fvwm
| preserves TMPDIR just fine.
|
| Try to put "Echo $[TMPDIR]" as the first line of your fvwm config.
Another thing worth doing is making an Action line like this:
Exec env xterm ...
which will recite the env just before starting the xterm.
Another (unlikely) possibility: Action lines are passed to the shell,
/bin/sh by default (NB not $SHELL unless you adjust things with
ExecUseShell). What is /bin/sh on your system? I'd expect it to be
bash. because of this, the "env" above will run _after_ /bin/sh has had
a chance to do stuff. Most shells will not interfere, but ksh honours
a $ENV var and bash a $BASH_ENV var to specify shell file to run even in
non-interactive shell startups. However, I see neither in your env dump,
so that should not be happening.
So: if $TMPDIR is good in the fvwm "Echo $[TMPDIR]" and bad in the env
output above, the suspect is the shell, not the xterm.
If $TMPDIR is good in fvwm and in the env output, then things are
even stranger; I would suspect the shell startups (eg /etc/bashrc or
something), except that you say your plain "xterm -e mutt" lines shows
$TMPDIR damage, and the shell is not involved there once xterm starts.
| If we suppose something in the middle removes TMPDIR, you may set TMPDIR0
| in .xinitrc (or whatever file you use to start fvwm) and then put this:
|
| SerEnv TMPDIR $[TMPDIR0]
It would still be better to figure out what's causing the damage:-)
--
Cameron Simpson <[EMAIL PROTECTED]> DoD#743
http://www.cskk.ezoshosting.com/cs/
Sometimes the only solution is to find a new problem.
