2008/8/21 Joel Rees <[EMAIL PROTECTED]>:
> On 平成 20/08/21, at 12:12, Philip Guenther wrote:
>
>> 2008/8/20 Joel Rees <[EMAIL PROTECTED]>:
>>>
>>> export PROFMARKER=".profile"
>
> would you believe I put that in .profile, like the marker said?
...etc
Now that you've said it, yes, I do. If you think it unreasonable to
not assume that from your first message, then you haven't followed
enough Q&A exchanges on mailing lists. People do things that are
completely insane to others and then don't believe it when people say
"that was non-obvious".
Part of writing a good question is providing enough information for
the readers to both eliminate the weirder scenarios and to estimate
how likely you are to miss the vital clue. If you don't "set the
scene" sufficiently, then answers have to either
a) be excessively general (60 lines to describe what file might
control xterm's startup?)
b) ask for more detail, or
c) make assumptions, stated or not, and risk being completely wrong or
starting the
chase in the wrong direction.
> If you're wondering why the shotgun approach, I couldn't figure out, with my
> login shell set to sh, why the shell was behaving like csh. Still don't get
> it.
<sigh> What do you mean by "behaving like csh"? The only prominent
reference to csh behavior I see in your previous note is this:
>>> Except, csh picks up one marker, sh and ksh pick up none. So I'm
>>> still puzzled
But that seems to be saying that your shell is *not* behaving like
csh! If you *really* mean that your shell is behaving like csh, then
perhaps xterm is actually running csh. What's the output of $SHELL
from inside xterm? How about $XTERM_SHELL? What shows up in 'ps'?
Are you passing xterm arguments on its command line? Does your
~/.xsession or ~/.xinitrc set the SHELL environment variable to
/bin/csh? (You don't mention whether you use xdm or xinit, or
something completely different, so I can't guarantee that there aren't
other possible rcfiles that could be involved.) Is the involved
startup script written in csh?
...
> Well, I read it and I thought about it and it sounds like what you're saying
> is that fvwm x11 sessions are giving me interactive shells instead of login
> shells? That .profile is not the same as .bash_profile? That it's probably
> not a good idea to have x11 sessions attempt to process the same script that
> starts up your login session when you login at a character terminal?
Yes, yes, and maybe. The big no-no is putting stuff that requires a
terminal (stty, etc) in rcfiles that are parsed for non-interactive
shells (e.g., .bashrc or .cshrc).
> I'll have to think about that for a while. I mean it sort of makes sense.
> X11 is going to need parameters set that would be at best superfluous in a
> console shell and could well get in the way.
This all gets usage dependent really quickly. If you often run X
client programs from other machines using ssh, for example, then you
may very well want to have all your X-related environment variables
(e.g. XUSERFILESEARCHPATH) set in your remote terminal logins. If you
don't ever do that, then setting and exporting that in your .xsession
only is probably the simpler choice.
> But right now I'm having a bit of a hard time imagining why I would want
> environment settings in a console sh shell that I wouldn't want in an x11 sh
> session shell.
If the old days when people logged into the console as a terminal and
used 'xinit' to start X, there was no need for xterm to start a login
shell, as it would inherit environment variables from your console
login shell via xinit and .xinitrc. With xdm, you don't have that
initial login shell, so you either need to set and export them in your
.xsession or configure xterm to start login shells.
> Okay, it seems like I would want three separate places to specify startup
> parameters -- one file for login parameters that are independent of the
> shell, one set of files for parameters to X11, and one startup file for the
> specific shell.
The first doesn't exist: csh and sh do not support a common syntax for
setting environment variables. Most people just pick one shell and
make sure everything uses that. Do you *really* want to actively use
both csh and sh, or is that just a workaround for xterm starting
something that may be csh despite your shell being /bin/sh in the
passwd file? If the former, well, you'll need to duplicate stuff:
good luck. If the latter, then let's figure out why it's acting weird
so you can stick to the shell you prefer.
For the the second ("parameters to X11"), that depends on how you run
X. xinit, xdm, or something else? Remote sessions?
(One of UNIX's traps is that almost everything is configurable...which
means that almost nothing is guaranteed. Five ways to start X, with a
dozen possible config files, and others that can be indicated via
environment variables that might have been set in half a dozen
rcfiles... A completely general answer grows in size exponentially as
the moving parts increases. Thus the questions.)
Philip Guenther
