Xdm var/log/xdm.log

[Per Hedeland]

On 2020-05-02 09:51, Polytropon wrote:
> On Sat, 2 May 2020 09:09:35 +0200, Per Hedeland wrote:
>> On 2020-05-01 15:17, Polytropon wrote:
>>> On Fri, 1 May 2020 07:56:27 -0400, Robert Huff wrote:
>>>>
>>>> Polytropon writes:
>>>>
>>>>>  > >  > Ok, I will add xsession.
>>>>>  > >
>>>>>  > >  NB: .xsession (the dot is significant).
>>>>>  > >
>>>>>  > >  Or you can do the following, as you said you already have
>>>>>  > >  a .xinitrc (which xdm will ignore, as mentioned):
>>>>>  > >
>>>>>  > >  	% cp .xinitrc .xsession
>>>>>  >
>>>>>  > 	From my home directory:
>>>>>  >
>>>>>  > lrwxrwxr-x   1 huff  huff         8 May  1 01:19 .xsession -> .xinitrc
>>>>>  >
>>>>>  > 	This implies you want the same environment from both.
>>>>>
>>>>>  Will usually work, but doesn't keep C shell initialization
>>>>>  (environmental variables, aliases, settings), which might
>>>>>  not be a problem if you're not using the C shell for dialog
>>>>>  sessions or if you concentrate on GUI entirely. :-)
>>>>
>>>> 	Once	I start X, I do pretty much everything within it.  For the
>>>> rest I console-switch.
>>>> 	(And the first line of the file is "#! /bin/sh".  :-) )
>>>> 	What is there that one might wish to do that can't be handled out
>>>> of an xterm?
>>>
>>> If I remember correctly, if you use xdm, and start an X terminal
>>> inside the X session, your settings from .cshrc will not be in
>>> effect due to the fact that the invoked shell is not a login shell.
>>
>> I believe you are confusing .cshrc with .login - .cshrc is read by
>> *every* instance of [t]csh unless the -f option is used, while .login
>> is indeed only read by login shells (and thus pretty much useless).
>
> Yes, that's what "man csh" says... but decades ago it didn't
> work.

Well, "it" as in "every instance reads .cshrc" has definitely worked
at least since the csh version shipped with 4.1BSD (1981) when I
started using it, and continued to do so across the tcsh that was a
set of source patches to csh, and the "merged" open-source version in
FreeBSD. But you may of course have things *in* your .cshrc that
e.g. makes most of it be skipped if it has already been read.

> I remember that when using xdm with .xsession to launch
> the user components of X, whenever I opened a terminal, my
> C shell settings from .cshrc (!) weren't included, that's why
> I invented the "cascading approach" for .xsession and .xinitrc.

As I already wrote, "shell settings" can't be inherited across an
exec, as you reported having in your .xsession:

	#!/bin/csh
	source ~/.cshrc
	exec ~/.xinitrc

> That was a long time ago, but it still works.

Or, whatever it was that you did that *actually* fixed your problem
still works.:-) Sourcing .cshrc in a csh script also works of course,
but the csh instance running the script has already sourced it (unless
it was started with -f), so it isn't likely to be useful.

> I don't know how other display managers handle things. I did
> not need that for slim, and I got rid of gdm quite quickly
> because it didn't care for _any_ user configuration file (no
> .xsession, no .xinitrc, no nothing).

I've only ever "actively" used xdm, haven't seen a need for anything
else.

>> FWIW, while I use tcsh as my interactive shell, both my .xsession and
>> .xinitrc have #!/bin/sh (as all scripts should:-), [...]
>
> I think the #!/bin/sh in .xinitrc is just for the reader, because
> the manual of startx says that it will use /bin/sh for execution
> if .xinitrc regardless. However, it's not wrong and it doesn't
> do any harm. Similarly, there is no mention that this file has
> to be executable (+x attribute set), but again, it's probably
> not wronger than the #!/bin/sh line... :-)

The execute permissions are certainly required (and shebang strongly
recommended) if you want to 'exec' .xinitrc from .xsession, though.

--Per