NetBSD Problem Report #54851
From www@netbsd.org Fri Jan 10 22:10:42 2020
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
by mollari.NetBSD.org (Postfix) with ESMTPS id 5E93B7A19B
for <gnats-bugs@gnats.NetBSD.org>; Fri, 10 Jan 2020 22:10:42 +0000 (UTC)
Message-Id: <20200110221041.916B37A1C8@mollari.NetBSD.org>
Date: Fri, 10 Jan 2020 22:10:41 +0000 (UTC)
From: coypu@sdf.org
Reply-To: coypu@sdf.org
To: gnats-bugs@NetBSD.org
Subject: .profile is not read by sh when using xdm or other login managers
X-Send-Pr-Version: www-1.0
>Number: 54851
>Category: xsrc
>Synopsis: .profile is not read by sh when using xdm or other login managers
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: xsrc-manager
>State: needs-pullups
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri Jan 10 22:15:00 +0000 2020
>Closed-Date:
>Last-Modified: Mon Aug 29 16:25:01 +0000 2022
>Originator: coypu
>Release: netbsd 9.0 rc1
>Organization:
>Environment:
>Description:
Result: ifconfig and ping not in PATH, no tab completion...
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851: .profile is not read by sh when using xdm or other login managers
Date: Sat, 11 Jan 2020 09:02:06 +0700
Date: Fri, 10 Jan 2020 22:15:00 +0000 (UTC)
From: coypu@sdf.org
Message-ID: <20200110221500.D64567A153@mollari.NetBSD.org>
| Result: ifconfig and ping not in PATH, no tab completion...
shells (all shells, not just /bin/sh) read .profile (or their equivalent)
only when started as a login shell.
Whatever starts the shell needs to make that happen, if the shell you're
getting is in an xterm, then starting the xterm with the -ls option
will cause it to start a login shell, rather than a normal one.
I don't use xdm, but I believe it uses a .xsession file to decide what
to start when you log in (or something like that), if you're starting
xterms and want them to contain login shells, then add the -ls option
to each xterm started.
Alternatively, if all you care about is the PATH setting, then simply
set PATH (and export it) in your .xsession.
If you want command line editing, the best place to enable that is
usually in your $ENV file, as that needs to be set for each shell
started, login shell or not, just do it only for interactive shells:
case "$-" in
*i*)
set -V -o tabcomplete; # or whatever you want
;;
esac
and export ENV (from either .profile, or .xsession, or both).
There are many many different approaches to getting all this right,
as what is "right" depends heavily upon the preferences of the user
concerned. No "one size fits all" is going to work for everyone,
or for that matter, most likely more than a small subset of users.
kre
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851: .profile is not read by sh when using xdm or other
login managers
Date: Sat, 11 Jan 2020 07:13:38 +0000
On Fri, Jan 10, 2020 at 10:15:00PM +0000, coypu@sdf.org wrote:
> Result: ifconfig and ping not in PATH, no tab completion...
This is a property of your .xsession file, or if you don't have one
the default one.
It looks like nowadays the default xsession file is
xrdb -load $HOME/.Xresources
exec xsm
and I don't know enough about how xsm works to find its default
config, but my guess would be that it isn't opening login shells and
perhaps it should be.
--
David A. Holland
dholland@netbsd.org
From: "John D. Baker" <jdbaker@consolidated.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: xsrc/54851: .profile is not read by sh when using xdm or other
login managers
Date: Sat, 11 Jan 2020 07:43:52 -0600 (CST)
As noted by others, only login shells read ".profile".
When 'xdm' starts the session, it is just another fork/chown/exec sequence
and "/bin/sh" interpreting the master Xsession script
("/etc/X11/xdm/Xsession") is not a login shell. The same is true for any
display manager program that starts its session script with "/bin/sh".
Since the various penguin-OS flavors typically have "bash" and it has the
"-l" option to force it to be a login shell, such installations typically
use:
#!/bin/bash -l
at the top of their master Xsession script. Since the process is run as
the local user, it reads their ".profile" (".bash_profile) the same as a
terminal login.
Some twenty-odd years ago I figured this out after tracing the "chain of
custody" of the xdm session process and crafted a "~/.xsession" script
to handle the situation by explicitly sourcing my ".profile" at the start
of the script.
----------
#!/bin/sh
#
# .xsession -- user-specific GUI session initialization
# This script is the next-to-last thing that runs in the process started
# by the display manager.
# As it functions as a login shell, the script should read the system
# and user-specific startup files to set up the user's environment.
# This is often dependent on the shell interpreter used.
# If we were executed by 'xinit' or included by 'startx', arrange for
# output/error logging just like Xsession would.
hostname=$(hostname)
hostname=${hostname%%.*}
case $0 in
*.xinitrc|*/startx)
exec > ~/.xsession-errors.${hostname} 2>&1
echo "Executed as: "${0##*/}
;;
*.xsession)
# If we were executed as ".xsession", check which interpreter is in use.
# If it is 'bash', assume we are a login shell already.
# Otherwise, if it is not 'bash', source .profile to set environment.
[ -z "$BASH_VERSION" ] && [ -s ~/.profile ] && . ~/.profile
;;
esac
[...]
--
|/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X
|\ / jdbaker[snail]consolidated[flyspeck]net OpenBSD FreeBSD
| X No HTML/proprietary data in email. BSD just sits there and works!
|/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
From: Rhialto <rhialto@falu.nl>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851: .profile is not read by sh when using xdm or other
login managers
Date: Sat, 11 Jan 2020 22:11:21 +0100
Having something special in .Xsession (or other session startup script)
to make a login shell may not propagate properly to xterms you then
start later (depending on how you set up various shell initialization
files). Personally I think it makes sense that xterms are all login
shells in their own right, just like grabbing the next ADM-3a next to
you and logging in gives you a new login shell.
My method to get this result is this in my .Xresources:
xterm.vt100.LoginShell: on
-Olaf.
State-Changed-From-To: open->closed
State-Changed-By: nia@NetBSD.org
State-Changed-When: Mon, 02 May 2022 15:14:12 +0000
State-Changed-Why:
I fixed this in my commit to
external/mit/xdm/dist/config/Xsession.in
on 25 December 2021
State-Changed-From-To: closed->needs-pullups
State-Changed-By: maya@NetBSD.org
State-Changed-When: Mon, 15 Aug 2022 19:23:47 +0000
State-Changed-Why:
might want to include this in a release (oops)
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Tue, 16 Aug 2022 15:02:40 +0300
On Mon, May 02, 2022 at 15:14:12 +0000, nia@NetBSD.org wrote:
> State-Changed-Why:
> I fixed this in my commit to
> external/mit/xdm/dist/config/Xsession.in
> on 25 December 2021
That fix (sourcing ~/.profile from Xsession) seems pretty suspicious
to me, if not outright wrong. I haven't used xdm in a small eternity,
but xdm provides the resources to customize this and we set the
defaults for them in src/external/mit/xorg/bin/xdm/Makefile The PATH
is set in userEnv in xsrc/external/mit/xdm/dist/greeter/verify.c
So the real problem is that we have xdm defaults that miss the
directories that the system default path (sysctl user.cs_path /
getconf PATH) actually does have.
xdm comes from the era when NFS-shared home in a heterogenous
environment were quite common, so the same ~/.profile would be
interpreted on SunOS, Ultrix, SVR3 and what not. And these systems
had their own path quirks: X's own bin location (X11R[45], I don't
remember if I had anything with R3; cf. X11R[67] we had in NetBSD),
/usr/ucb, /usr/xpg4, /usr/gnu was quite common, etc. That machine's
xdm would take care to set up system's idea of the default path for
you that included those systems-specific things.
So the machinery for this is all in place and working around our own
wrong xdm defaults by sourcing a random user's script that in the big
scheme of things should not hardcode system-specific PATH pecularities
- is not the right thing to do.
-uwe
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Tue, 16 Aug 2022 14:16:34 +0200
This change is pretty dangerous for users of other shells:
- it changes the behaviour of the system wide Xsession file
(not a new users template ~/.xsession)
- it sources the per user ~/.shrc instead of the system wide /etc/sh.shrc
(that could be adapted for this to just provide reasonable defaults)
- users of other shells will often have outdated (and usually unused)
~/.shrc files that may set arbitrary (bad/broken) things in their
environment (with a bit of luck just old versions of PATH,
whatever used to be the default for .shrc when that account
was created)
Martin
(using tcsh and xdm, so I would be affected)
From: nia <nia@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Wed, 17 Aug 2022 21:59:44 +0000
On Tue, Aug 16, 2022 at 12:20:02PM +0000, Martin Husemann wrote:
> This change is pretty dangerous for users of other shells:
>
> - it changes the behaviour of the system wide Xsession file
> (not a new users template ~/.xsession)
AFAIK, there isn't such thing - only a system-wide default.
>
> - it sources the per user ~/.shrc instead of the system wide /etc/sh.shrc
> (that could be adapted for this to just provide reasonable defaults)
Maybe, but it's really unclear what colour we want the bikeshed
painted.
Judging by the lengthy discussion on developers@, and strong
objections by some developers to things like certain editing modes,
I'm extremely reluctant to modify any defaults.
> - users of other shells will often have outdated (and usually unused)
> ~/.shrc files that may set arbitrary (bad/broken) things in their
> environment (with a bit of luck just old versions of PATH,
> whatever used to be the default for .shrc when that account
> was created)
>
> Martin
> (using tcsh and xdm, so I would be affected)
>
My understanding when making the change was that ~/.profile
is only for sh(1) type shells, and the Xsession file is executed
in sh(1) through the shebang, and any alternative shell will be
spawned later.
I'm not sure about tcsh -
csh(1) seems to use these files rather than .profile:
FILES
~/.cshrc Read at beginning of execution by each shell.
~/.login Read by login shell, after `.cshrc' at login.
~/.logout Read by login shell, at logout.
The default ~/.cshrc on NetBSD will specify a path, so you'll
get the right thing regardless of xdm or login shell.
From: nia <nia@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Wed, 17 Aug 2022 22:01:40 +0000
On Tue, Aug 16, 2022 at 12:05:02PM +0000, Valery Ushakov wrote:
> That fix (sourcing ~/.profile from Xsession) seems pretty suspicious
> to me, if not outright wrong. I haven't used xdm in a small eternity,
> but xdm provides the resources to customize this and we set the
> defaults for them in src/external/mit/xorg/bin/xdm/Makefile The PATH
> is set in userEnv in xsrc/external/mit/xdm/dist/greeter/verify.c
>
> So the real problem is that we have xdm defaults that miss the
> directories that the system default path (sysctl user.cs_path /
> getconf PATH) actually does have.
>
> xdm comes from the era when NFS-shared home in a heterogenous
> environment were quite common, so the same ~/.profile would be
> interpreted on SunOS, Ultrix, SVR3 and what not. And these systems
> had their own path quirks: X's own bin location (X11R[45], I don't
> remember if I had anything with R3; cf. X11R[67] we had in NetBSD),
> /usr/ucb, /usr/xpg4, /usr/gnu was quite common, etc. That machine's
> xdm would take care to set up system's idea of the default path for
> you that included those systems-specific things.
>
> So the machinery for this is all in place and working around our own
> wrong xdm defaults by sourcing a random user's script that in the big
> scheme of things should not hardcode system-specific PATH pecularities
> - is not the right thing to do.
Reducing the problem down to just the PATH seems to be Missing The
Point slightly. It's also about locales, editing modes, etc.
Without ~/.profile read on startup, the default shell is pretty
unusable regardless of PATH settings.
I'm not sure what you mean by random user - it sources the ~/.profile
from the user who has just logged in. Nothing is read before login.
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Thu, 18 Aug 2022 00:27:09 +0000
On Wed, Aug 17, 2022 at 10:00:04PM +0000, nia wrote:
> > - it changes the behaviour of the system wide Xsession file
> > (not a new users template ~/.xsession)
>
> AFAIK, there isn't such thing - only a system-wide default.
It also only changes the behavior when there's no ~/.xsession.
Which means it affects nobody who has their own setup.
> I'm not sure about tcsh -
> csh(1) seems to use these files rather than .profile:
>
> FILES
> ~/.cshrc Read at beginning of execution by each shell.
> ~/.login Read by login shell, after `.cshrc' at login.
> ~/.logout Read by login shell, at logout.
>
> The default ~/.cshrc on NetBSD will specify a path, so you'll
> get the right thing regardless of xdm or login shell.
tcsh is the same except that it uses .tcshrc instead of .cshrc if
present, and that will also normally set up the path unless the user's
doing something strange.
--
David A. Holland
dholland@netbsd.org
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Thu, 18 Aug 2022 04:13:50 +0300
On Wed, Aug 17, 2022 at 22:05:01 +0000, nia wrote:
> I'm not sure what you mean by random user - it sources the ~/.profile
> from the user who has just logged in. Nothing is read before login.
Sorry, it ended up ambiguous. I meant "random (user's script)" not
"(random user)'s script".
The suggested solution to this problem cannot rely on every user to
have an up-to-date ~/.profile that sets these things up - even when
their shell is not sh(1).
Also note that login sh(1) reads /etc/profile automatically and then
reads ~/.profile (which doesn't have to source /etc/profile) so any
system-wide customization made by an administrator to /etc/profile
will not be picked up by your change.
> Reducing the problem down to just the PATH seems to be Missing The
> Point slightly. It's also about locales, editing modes, etc.
The editing mode is not relevant here.
I don't know what is the official way for users to set up their locale
in a way that it's picked up by any which way a user may "log in" to
the system. But system-wide default PATH is system-wide, and locale
is per-user, so you cannot lump these two problems together.
Actually, the very fact that you bring them up in the same context is
a sign that you might be missing the point here. Host-wide PATH,
user-specific locale and sh(1)'s interactive experience are three
quite separate issues and have to be considered separately. Even the
last two don't belong together, b/c locale is something you want to
set up in your .profile or .login once for all child processes to
inherit and things like functions/aliases, editing preferences, etc
need to be set up in the sh's $ENV file, or .bashrc, or .cshrc for
each interactive shell to pick up.
> Without ~/.profile read on startup, the default shell is pretty
> unusable regardless of PATH settings.
Do you mean by "unusable" the fact that line editiing is not on by
default? Again, this is not relevant. A process chain of, say xdm ->
user's X session -> window manager menu -> emacs - is supposed to
start emacs with the right PATH in its environment. Whether sh(1) is
"usable" (in your opinion) as an interactive shell is not pertinent
even if your interactive shell happens to be sh(1) - which might not
be the case.
-uwe
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Thu, 18 Aug 2022 04:34:17 +0000
On Thu, Aug 18, 2022 at 01:15:01AM +0000, Valery Ushakov wrote:
> The suggested solution to this problem cannot rely on every user to
> have an up-to-date ~/.profile that sets these things up - even when
> their shell is not sh(1).
There are several different user cases here as well:
(1) Someone who knows what they're doing and makes a quick and dirty
spare account with no dotfiles. This should still have a useful
default path, regardless of what shell they stuff in the password
entry. Reading ~/.profile won't help here, because there isn't one;
xdm should be producing the correct default path.
(2) Someone who doesn't know what they're doing and accidentally makes
an account without dotfiles. This should behave usefully, especially
since I've gathered from the recent bikeshedding that it's easy to do
this. Here the issues also extend to the default shell configuration,
but that's irrelevant to xdm.
(3) Someone who more or less does know what they're doing, but doesn't
know how to wrangle xdm, and didn't get given a starter .xsession file
in their account. (Why don't we have a .xsession in /etc/skel?) These
people expect that when they log in via xdm they'll get their path and
locale settings. (Plus anything else they might have wanted to set in
the environment, like say HACKOPTIONS.) If they use sh by default,
reading ~/.profile in the default session takes care of their issues.
(Though as you point out, probably it should also read /etc/profile.)
If they use a different shell, it won't necessarily work, but if they
understand different shells they are likely willing to update their
~/.profile as well.
(4) Someone who's writing their own .xsession. They only need to be
told to set the path and locale (and other such stuff) in it. The
change we're arguing about doesn't make any difference for them,
because it only affects the default session. Having a starter
.xsession file would make everyone's lives easier, though.
(5) Someone who already has a config they've been carrying around for
decades. The whole issue is irrelevant because they already sorted out
the issues on variously broken vendor unixes in the 80s or 90s.
Most netbsd users are in category (5), I think, except for the ones
who go straight to category (4), and the occasional occurrences of
(1).
The thing is, though, that without a starter .xsession file most newer
users end up in category (3). So I think this change was a good idea
and the fact that it doesn't work perfectly for everyone isn't a
problem.
--
David A. Holland
dholland@netbsd.org
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc: "David A. Holland" <dholland@netbsd.org>
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Thu, 18 Aug 2022 16:04:32 +0300
On Thu, Aug 18, 2022 at 04:35:02 +0000, David Holland wrote:
> The thing is, though, that without a starter .xsession file most newer
> users end up in category (3). So I think this change was a good idea
> and the fact that it doesn't work perfectly for everyone isn't a
> problem.
You do relaize that "most newer users" will probably just immediately
install gnome or mate or whatever and will never be studying that
Xsession script as an example, don't you? ;)
As for the pedagocial value of that script - I'm already not very
happy about e.g. the default xrdb with a here-document that it does.
The same here-document is copy-pasted in xinitrc - instead of setting
the default resources in a file that already gets automatically
loaded.
Speaking of which, when can we have tradcpp in base, so that there's a
preprocessor for x resources even withour comp.tgz set installed? :)
Testing a bit further with a scratch account I also notice that xdm
doesn't propagate PATH set in login.conf. It does call
setusercontext(3) with LOGIN_SETALL but probably overrides the PATH
later with the values from its resources.
In short, the problem is more complex than it seems at first glance.
The original fix happen to work by accident and not in all cases. The
login.conf(5) bug I've just noticed needs to be investigated in this
context too - googling for 'xdm "login.conf"' comes up with a few
relevant hits.
I understand that working on this is to a large degree thanksless and
tedious job that requires some knowledge of historical and current
practices and at least an overview of a nontrivial matrix of options
and choices that sysadmins and their users have at their disposal. So
I don't think that dismissing as "bikeshed" any feedback that poitns
out this fact is a fair characterization.
<humor>If you want bikeshedding, consider the case of having two X
installations, say base and pkgsrc and you want xdm to ensure the
right path to the rest of the X takes precedence and you can switch
from one X installation to another and back by just switching which
xdm the rc script runs - after that you would get you xterm &c from
the the right X install, etc.<humor> Please, don't reply to that.
I'll probably gonna regret bringing this up, but the temptation is too
strong. :)
To summarize
1) the DEF_USER_PAH we set in xmd reach-over makefile is wrong (netbsd bug)
2) path setting in login.conf(5) is ignored (xdm bug)
3) the current fix that sources .profile works around 1 and 2 by accident
I think that short term we should revert 3, fix 1, and then
investigate 2 separately.
-uwe
From: RVP <rvp@SDF.ORG>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Thu, 18 Aug 2022 20:18:38 +0000 (UTC)
On Thu, 18 Aug 2022, Valery Ushakov wrote:
> Testing a bit further with a scratch account I also notice that xdm
> doesn't propagate PATH set in login.conf. It does call
> setusercontext(3) with LOGIN_SETALL but probably overrides the PATH
> later with the values from its resources.
>
It does the same thing for the env. vars. too. It doesn't pass on
what setusercontext(LOGIN_SETALL) set to the execve().
-RVP
From: nia <nia@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Fri, 19 Aug 2022 13:39:50 +0000
On Thu, Aug 18, 2022 at 01:15:01AM +0000, Valery Ushakov wrote:
> > Reducing the problem down to just the PATH seems to be Missing The
> > Point slightly. It's also about locales, editing modes, etc.
>
> The editing mode is not relevant here.
I don't see how it isn't relevant, since if I revert this change as you
ask, we go back to non-functioning line editing in xterms spawned after
xdm.
Is there another temporary solution I can deploy that you'd find
acceptable before I can figure out how to make everyone happy?
I could make xterm create login shells. Obviously it doesn't
make anything better for other terminal emulators, but it's a start.
From: nia <nia@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Fri, 19 Aug 2022 14:05:45 +0000
On Thu, Aug 18, 2022 at 01:05:02PM +0000, Valery Ushakov wrote:
> 1) the DEF_USER_PAH we set in xmd reach-over makefile is wrong (netbsd bug)
I do agree with this - NetBSD's the only OS that doesn't include the
sbin directories in DEF_USER_PAH by default. Are you happy with
it being modified to include the sbin directories for harmonization?
IMO if we want to teach xdm about sysctl user.cs_path it should be
done upstream.
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Fri, 19 Aug 2022 18:37:38 +0300
On Fri, Aug 19, 2022 at 14:10:02 +0000, nia wrote:
> I do agree with this - NetBSD's the only OS that doesn't include the
> sbin directories in DEF_USER_PAH by default. Are you happy with
> it being modified to include the sbin directories for harmonization?
Yes. IIRC, that was my very first comment on the PATH issue. I'd
just set DEF_USER_PATH to the value of _PATH_STDPATH with $(X11BINDIR)
appended.
> IMO if we want to teach xdm about sysctl user.cs_path it should be
> done upstream.
Yes.
-uwe
From: "Nia Alarie" <nia@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54851 CVS commit: src/external/mit/xorg/bin/xdm
Date: Fri, 19 Aug 2022 15:55:37 +0000
Module Name: src
Committed By: nia
Date: Fri Aug 19 15:55:37 UTC 2022
Modified Files:
src/external/mit/xorg/bin/xdm: Makefile
Log Message:
xdm: Include "sbin" directories (and games) in DEF_USER_PATH.
Upstream's configure.ac picks a DEF_USER_PATH on a per-OS basis.
Most of these include the "sbin" directories, with NetBSD being the
(only?) exception.
However, this is inconsistent with the way a typical login shell is
initialized (when using the default skeleton files). To avoid user
confusion, harmonize DEF_USER_PATH with our other defaults and with
other OSes.
PR xsrc/54851
To generate a diff of this commit:
cvs rdiff -u -r1.18 -r1.19 src/external/mit/xorg/bin/xdm/Makefile
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
From: nia <nia@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Sat, 20 Aug 2022 11:19:55 +0000
On Fri, Aug 19, 2022 at 03:40:02PM +0000, Valery Ushakov wrote:
> On Fri, Aug 19, 2022 at 14:10:02 +0000, nia wrote:
>
> > I do agree with this - NetBSD's the only OS that doesn't include the
> > sbin directories in DEF_USER_PAH by default. Are you happy with
> > it being modified to include the sbin directories for harmonization?
>
> Yes. IIRC, that was my very first comment on the PATH issue. I'd
> just set DEF_USER_PATH to the value of _PATH_STDPATH with $(X11BINDIR)
> appended.
>
>
> > IMO if we want to teach xdm about sysctl user.cs_path it should be
> > done upstream.
>
> Yes.
Are you OK with my proposal to:
(a) revert reading of ~/.profile from the xsession shell script,
as you requested
(b) run all xterms with login shells by defualt
?
From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Sat, 20 Aug 2022 16:18:01 +0200
On Sat, Aug 20, 2022 at 11:20:02AM +0000, nia wrote:
> (b) run all xterms with login shells by defualt
How would you do that? Explicit -ls command line arg in the xsession?
Forcing it via xterm resources would probably be more controversial.
Martin
From: nia <nia@NetBSD.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Sun, 21 Aug 2022 08:39:39 +0000
On Sat, Aug 20, 2022 at 02:20:02PM +0000, Martin Husemann wrote:
> The following reply was made to PR xsrc/54851; it has been noted by GNATS.
>
> From: Martin Husemann <martin@duskware.de>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
> login managers)
> Date: Sat, 20 Aug 2022 16:18:01 +0200
>
> On Sat, Aug 20, 2022 at 11:20:02AM +0000, nia wrote:
> > (b) run all xterms with login shells by defualt
>
> How would you do that? Explicit -ls command line arg in the xsession?
> Forcing it via xterm resources would probably be more controversial.
>
> Martin
>
Set the resource in the xsession.
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Sun, 21 Aug 2022 13:13:20 +0300
On Sat, Aug 20, 2022 at 11:20:02 +0000, nia wrote:
> Are you OK with my proposal to:
>
> (a) revert reading of ~/.profile from the xsession shell script,
> as you requested
> (b) run all xterms with login shells by defualt
Are you still trying to work around the fact that shell doesn't enable
command line editing by default? Can we just fix that so that it
doesn't distract from the discussion of xdm bugs?
-uwe
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Sun, 21 Aug 2022 23:07:33 +0300
On Thu, Aug 18, 2022 at 04:13:50 +0300, Valery Ushakov wrote:
> Also note that login sh(1) reads /etc/profile automatically and then
> reads ~/.profile (which doesn't have to source /etc/profile) so any
> system-wide customization made by an administrator to /etc/profile
> will not be picked up by your change.
[...]
> Actually, the very fact that you bring them up in the same context is
> a sign that you might be missing the point here. Host-wide PATH,
> user-specific locale and sh(1)'s interactive experience are three
> quite separate issues and have to be considered separately. Even the
> last two don't belong together, b/c locale is something you want to
> set up in your .profile or .login once for all child processes to
> inherit and things like functions/aliases, editing preferences, etc
> need to be set up in the sh's $ENV file, or .bashrc, or .cshrc for
> each interactive shell to pick up.
So I did a bit more poking around about the "loginness" of Xsession,
and it's all a mess :)
Even the xdm(1) man page itself has an csh example that exhibit that
confusion, b/c it emphasizes that the the #!csh line doesn't have `-f`
flag ("fast", i.e. skip reading .cshrc) "so .cshrc gets run to set
$PATH", i.e. it supposes that PATH is set in in .cshrc, while normally
you'd want to do that once in .login
Also consider this question from 1994:
http://www.verycomputer.com/179_42a1457859bf1456_1.htm
| SHORT DESCRIPTION:
|
| XDM starts up DEC's session manager (dxsession) in its Xsession
| script. The default XDM setup in OSF/1 does not start dxsession as a
| login shell and, therefore, login scripts such at .login, .profile,
| and /etc/profile are not executed.
and the eventual kludge he ended up with was to inerpose a program
that inserts login shell before the session:
| execl(pwd->pw_shell, "-", "-c", DXSESSION, 0);
which I also thought of, but one problem there is that it doesn't work
with csh. csh's test for "am I a login shell" is argv[0] starts with
'-' and there are no arguments or, otherwise, there's single `-l`
argument. I.e. you cannot run -csh -c command that executes a command
as a login shell, after reading csh login files. (ksh, bash and zsh
don't have that limitation and grok -l -c; tmux accepts -l, dunno if
it passes it along with -c emulation).
The answer to the above question from a DEC guy was (quoting it here
in case that site goes away):
| The .xsession script is the X analog of the .login file. I quote
| from the X Window System Administrator's Guide (published by
| O'Reilly and Assoc. and included in the DEC OSF/1 doc set) -- "you
| might want to start thinking of the .login file as the startup file
| for ASCII-based user serssions only." (Read more about this in
| section 2.3.3.3 page 33.)
|
| I suggest that you not modify the /usr/lib/X11/xdm/Xsession script
| in this way but rather suggest that each user create a ~/.xsession
| script to configure his X environment. A typical .xsession script
| might define various environment variables and then run dxsession.
| One trick I use is to define a script of environment variable
| definitions which is sourced from both my .login and my .xsession.
Which forces everyone to either have an .xsession file or make their
.cshrc, or .bashrc, or whatever check if the environment was
customized and source their login script if not.
So we may instead go the other way and make Xsession read /etc/profile
too to simulate login behaviour of shell at least for sh users (the
default). People that use some other shell probably either already
have .xsession or run terminals with login shells or worked around
this ancient xdm problem in some other way.
All that shouldn't change the fact that we should fix sh to enable
line editing by default.
Probably make sh grow -l option too, like ksh, bash, zsh and (albeit
limited) csh.
-uwe
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Sun, 21 Aug 2022 23:04:50 +0000
On Sun, Aug 21, 2022 at 08:10:02PM +0000, Valery Ushakov wrote:
> So I did a bit more poking around about the "loginness" of Xsession,
> and it's all a mess :)
Everything about xdm is a mess; it's not an accident that every
desktop provides its own replacement for it.
If we want it to behave itself we're going to have to fix it.
> Even the xdm(1) man page itself has an csh example that exhibit that
> confusion, b/c it emphasizes that the the #!csh line doesn't have `-f`
> flag ("fast", i.e. skip reading .cshrc) "so .cshrc gets run to set
> $PATH", i.e. it supposes that PATH is set in in .cshrc, while normally
> you'd want to do that once in .login
As I posted or said somewhere a couple days ago (can't remember which
of the many related threads or discussions) it is/was standard
practice with csh to set the path in .cshrc. You'll notice that our
skeleton .cshrc file does exactly that.
> | execl(pwd->pw_shell, "-", "-c", DXSESSION, 0);
>
> which I also thought of, but one problem there is that it doesn't work
> with csh. csh's test for "am I a login shell" is argv[0] starts with
> '-' and there are no arguments or, otherwise, there's single `-l`
> argument. I.e. you cannot run -csh -c command that executes a command
> as a login shell, after reading csh login files. (ksh, bash and zsh
> don't have that limitation and grok -l -c; tmux accepts -l, dunno if
> it passes it along with -c emulation).
This could be construed as a bug, so we could always just fix csh.
It's not like the default session embedded in xdm needs to work with
anyone else's csh.
However, I think it's reasonable to assume that at this point all csh
users are oldtimers and know what they're doing and probably already
have their own .xsession arrangements, and not worry about it.
> | I suggest that you not modify the /usr/lib/X11/xdm/Xsession script
> | in this way but rather suggest that each user create a ~/.xsession
> | script to configure his X environment. A typical .xsession script
> | might define various environment variables and then run dxsession.
> | One trick I use is to define a script of environment variable
> | definitions which is sourced from both my .login and my .xsession.
>
> Which forces everyone to either have an .xsession file or make their
> .cshrc, or .bashrc, or whatever check if the environment was
> customized and source their login script if not.
Really, everybody, or at least everybody who ever uses xdm, should
have an .xsession file. Can we please add one to /etc/skel already?
This is really the best solution unless we plan on making large-scale
improvements to xdm.
> All that shouldn't change the fact that we should fix sh to enable
> line editing by default.
Right.
--
David A. Holland
dholland@netbsd.org
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other login managers)
Date: Mon, 22 Aug 2022 19:48:50 +0700
Date: Sun, 21 Aug 2022 23:05:02 +0000 (UTC)
From: David Holland <dholland-bugs@netbsd.org>
Message-ID: <20220821230502.AEDD61A923A@mollari.NetBSD.org>
| As I posted or said somewhere a couple days ago (can't remember which
| of the many related threads or discussions) it is/was standard
| practice with csh to set the path in .cshrc. You'll notice that our
| skeleton .cshrc file does exactly that.
Do remember that csh originated in 6th edition unix (it was on the
(original) 2BSD tape from CSRG). The environment, as a concept
didn't exist until version 7.
There was no other way to have every csh get a desired path setting,
other than doing it in .cshrc.
Once it starts out that way, it is hard to overcome inertia, and get
people to change.
| > I.e. you cannot run -csh -c command that executes a command
| > as a login shell, after reading csh login files. (ksh, bash and zsh
| > don't have that limitation and grok -l -c; tmux accepts -l, dunno if
| > it passes it along with -c emulation).
|
| This could be construed as a bug, so we could always just fix csh.
Since people seem to want it (and also it would occasionally make
testing of the shell early startup sequences easier), I have just
added -l to /bin/sh (not committed yet, not even tested beyond compile
time yet).
My inclination (and what I have implemented now) is to force +l
if either -c or a script name is given. That's even if argv[0]
starts with a '-' (giving either -l or +l will make that test
redundant, it is still used to set or clear -l when when neither
of those is given). The setting of -l (at shell invocation time)
is now what is used to control sourcing of the profile files at
startup time.
This is actually a (minor) change in behaviour - previously a login
shell (one whose argv[0] starts with '-' - which is the method of
indicating login shells dating back to the dark ages, options to
do it are post reformation inventions) would run the profile files
regardless of what it was going to do after that.
If people feel that we should continue to allow shells running scripts
or shells invoked with -c to be considered login shells (either with
the -l or **argv=='-' methods) now would be a good time to say - making
that change (for either or both of those cases) means deleting one
(new) line of code for each (ie: the decision doesn't need to be the
same for both).
My inclination would be to not request a pullup of this change to -9,
I consider it more than just a bug fix or minor enhancement.
| It's not like the default session embedded in xdm needs to work with
| anyone else's csh.
It probably wants to work for tcsh though.
| > All that shouldn't change the fact that we should fix sh to enable
| > line editing by default.
|
| Right.
I am considering a suitable way to do that, without having the shell
endorse emacs ("never!") or vi editing modes (I'd probably be lynched)
and I might have a way to do that. A subsequent change.
kre
ps: the commit to update the shell to include -l will not reference
this PR, the original subject had nothing to do with login shells.
From: Hisashi T Fujinaka <htodd@twofifty.com>
To: gnats-bugs@netbsd.org
Cc: xsrc-manager@netbsd.org, gnats-admin@netbsd.org, netbsd-bugs@netbsd.org,
coypu@sdf.org
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Mon, 22 Aug 2022 18:54:40 -0700 (PDT)
On Fri, 19 Aug 2022, nia wrote:
> The following reply was made to PR xsrc/54851; it has been noted by GNATS.
>
> From: nia <nia@NetBSD.org>
> To: gnats-bugs@netbsd.org
> Cc:
> Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
> login managers)
> Date: Fri, 19 Aug 2022 14:05:45 +0000
>
> On Thu, Aug 18, 2022 at 01:05:02PM +0000, Valery Ushakov wrote:
> > 1) the DEF_USER_PAH we set in xmd reach-over makefile is wrong (netbsd bug)
>
> I do agree with this - NetBSD's the only OS that doesn't include the
> sbin directories in DEF_USER_PAH by default. Are you happy with
> it being modified to include the sbin directories for harmonization?
>
> IMO if we want to teach xdm about sysctl user.cs_path it should be
> done upstream.
Untrue. I'm pretty sure SUSE doesn't include sbin.
--
Hisashi T Fujinaka - htodd@twofifty.com
BSEE + BSChem + BAEnglish + MSCS + $2.50 = coffee
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Tue, 23 Aug 2022 21:12:47 +0300
On Mon, Aug 22, 2022 at 12:50:02 +0000, Robert Elz wrote:
> If people feel that we should continue to allow shells running scripts
> or shells invoked with -c to be considered login shells (either with
> the -l or **argv=='-' methods) now would be a good time to say - making
> that change (for either or both of those cases) means deleting one
> (new) line of code for each (ie: the decision doesn't need to be the
> same for both).
ksh, bash and zsh seems to allow mixing login and -c. I'd prefer we
follow suit.
E.g. (with my ~/.bash_profile moved out of the way)
$ cat ~/.profile
export LOGIN_SHELL=42
$ ksh -l -c 'echo $-; env | grep LOGIN_SHELL'
clh
LOGIN_SHELL=42
$ bash -l -c 'echo $-; env | grep LOGIN_SHELL'
hBc
LOGIN_SHELL=42
Don't have zsh handy at the moment, but I checked the above on a mac
with zsh too.
-uwe
From: Robert Elz <kre@munnari.OZ.AU>
To: Valery Ushakov <uwe@stderr.spb.ru>
Cc: gnats-bugs@netbsd.org
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other login managers)
Date: Wed, 24 Aug 2022 02:01:03 +0700
Date: Tue, 23 Aug 2022 21:12:47 +0300
From: Valery Ushakov <uwe@stderr.spb.ru>
Message-ID: <YwUYn9VsfhWxOs+W@pony.stderr.spb.ru>
Finally, a comment, thanks - I was beginning to wonder if
anyone was left paying attention to this PR/thread, and was
considering sending a message to tech-userlevel (which I
probably should do anyway).
| ksh, bash and zsh seems to allow mixing login and -c. I'd prefer we
| follow suit.
I don't have strong feelings either way, it just seems kind of
weird (even perverted) to abuse the concept of being a login
shell that way (thanks for the examples, but I had tested various
shells already, and I know some behave like that).
While I am here, a few other minor things I forgot to mention.
The long name (to use with -o) will be "login" which it is in all
other shells that have a long name version (bash is one which doesn't)
except for ksh93, where the long name is "login_shell", but it still
allows -o login (ie: abbreviated form) to work on the command line (which
is the only place ksh93 allows this option to be set).
Second, the 'l' flag will appear in $- (not in all shells which have
the option) and can be used with the "set" command (but doing so is
pointless, as the only place it is used is deciding whether or not to
run the profile files - that decision is made before any external code
is executed, so while it will be possible to "set +l" in a login shell,
or "set -l" in an ordinary shell, the only thing that will alter is
what appears in $-. Not all shells allow -l to work with the "set"
command (neither that nor the -o form) - even some shells that show its
value in the output of "set -o" don't allow it to be altered by the
set command. This is a very peculiarly implemented option overall.
Third, I haven't bothered to check how many (if any) other shells
allow +l to prevent a shell which would otherwise be a login shell
from being one, nor do I care .. to me that symmetry is important.
(I haven't tested, as actually making a shell be a login shell, other
than by use of -l is annoying to do (possible, just annoying) other
than actually making it be a login shell for some user, and logging in,
which is a very tedious way to test, and provides no mechanism for
passing +l as an option anyway).
kre
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc: Robert Elz <kre@munnari.OZ.AU>
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Wed, 24 Aug 2022 01:02:28 +0300
On Wed, Aug 24, 2022 at 02:01:03 +0700, Robert Elz wrote:
> | ksh, bash and zsh seems to allow mixing login and -c. I'd prefer we
> | follow suit.
>
> I don't have strong feelings either way, it just seems kind of
> weird (even perverted) to abuse the concept of being a login
> shell that way.
I guess it provides a convenient way to get .profile &c read
automagically. E.g. I saw people doing something like
ssh -l user host bash -l -c "start_some $job"
where the user@host role account has some extensive setup in .profile
Or ~/.xsession can be made '#!/bin/sh -l' to save up on typing.
-uwe
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Sat, 27 Aug 2022 21:58:13 +0000
On Thu, Aug 18, 2022 at 01:05:02PM +0000, Valery Ushakov wrote:
> Speaking of which, when can we have tradcpp in base, so that there's a
> preprocessor for x resources even withour comp.tgz set installed? :)
Added finally, sorry that took so long.
--
David A. Holland
dholland@netbsd.org
From: David Holland <dholland-bugs@netbsd.org>
To: gnats-bugs@netbsd.org
Cc:
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other
login managers)
Date: Sat, 27 Aug 2022 22:11:40 +0000
On Mon, Aug 22, 2022 at 12:50:02PM +0000, Robert Elz wrote:
> | As I posted or said somewhere a couple days ago (can't remember which
> | of the many related threads or discussions) it is/was standard
> | practice with csh to set the path in .cshrc. You'll notice that our
> | skeleton .cshrc file does exactly that.
>
> Do remember that csh originated in 6th edition unix (it was on the
> (original) 2BSD tape from CSRG). The environment, as a concept
> didn't exist until version 7.
>
> There was no other way to have every csh get a desired path setting,
> other than doing it in .cshrc.
>
> Once it starts out that way, it is hard to overcome inertia, and get
> people to change.
Indeed. That's probably why, yes, and I'm sure there are extant .cshrc
files whose ancestry is that old, too.
> If people feel that we should continue to allow shells running scripts
> or shells invoked with -c to be considered login shells (either with
> the -l or **argv=='-' methods) now would be a good time to say -
It seems like a convenient thing to support, given that sh doesn't
have any equivalent of .cshrc that's adequate for the purpose of
setting things up. And it seems like there's no downside and no
particular reason it should be illegal, other than being semantically
untidy from some points of view. It's not like there's a path that
will invoke it when not desired and thereby create unexpected behavior.
--
David A. Holland
dholland@netbsd.org
From: Robert Elz <kre@munnari.OZ.AU>
To: gnats-bugs@netbsd.org
Cc: tech-userlevel@netbsd.org
Subject: Re: xsrc/54851 (.profile is not read by sh when using xdm or other login managers)
Date: Sun, 28 Aug 2022 14:31:38 +0700
Date: Sat, 27 Aug 2022 22:15:02 +0000 (UTC)
From: David Holland <dholland-bugs@netbsd.org>
Message-ID: <20220827221502.ACB101A923B@mollari.NetBSD.org>
| > If people feel that we should continue to allow shells running scripts
| > or shells invoked with -c to be considered login shells (either with
| > the -l or **argv=='-' methods) now would be a good time to say -
|
| It seems like a convenient thing to support, given that sh doesn't
| have any equivalent of .cshrc that's adequate for the purpose of
| setting things up.
It has $ENV - but something has to have set ENV first.
But everyone seems to agree that allowing it (login shells with
scripts or -c) will be OK, so that's what I will do (I'm a little
preoccupied at the minute with non computer issues, so it is taking
longer than I had expected to actually finish this - and with this
I'll need to revise the man page changes a bit (the code change
required is trivial).
| And it seems like there's no downside and no
| particular reason it should be illegal, other than being semantically
| untidy from some points of view. It's not like there's a path that
| will invoke it when not desired and thereby create unexpected behavior.
What I have been slightly concerned about is the possibility of
people starting scripts with
#!/bin/sh -l
or similar, and people's .profile being run (undoing env settings
that they may have made for this script to use this time, and perhaps
running things like stty or tset, and mesg, which .profile files often contain).
But based upon something Mouse said in an off list reply, I will add
a sh variable, which will be initialised with info that will allow the
profile script to tell (if it needs to) why it is being run (that is,
how the shell was invoked) so it can decide what it should do (much
the same way that in $ENV one can use $- to determine whether the
shell is interactive or not). ($- (alone) isn't up to the task
required here).
If the profile wants, it will be able to unset (or alter) the variable,
after it has finished testing it, so it can also detect when something (like
the user most often) explicitly does ". ~/.profile" to process it again.
Of course, if a user wants, they will be able to set the var to anything
they like (unless the profile makes it read only, which it could do, even
if the var is unset). This will just be an ordinary shell variable,
just one init'd by the shell at startup, but unlike most similar sh vars
init'd after the environment is read, not before, so when the profile
files start executing (as part of sh startup), it will be guaranteed the
var correctly indicates what kind of sh invocation this is.
No specifics on this yet, as in var name, or contents, as it isn't
implemented, but this will appear at the same time as -l appears.
Anyone who wants to make suggestions, then by all means, go ahead.
kre
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/54851 CVS commit: [netbsd-9] src/external/mit/xorg/bin/xdm
Date: Mon, 29 Aug 2022 16:20:45 +0000
Module Name: src
Committed By: martin
Date: Mon Aug 29 16:20:45 UTC 2022
Modified Files:
src/external/mit/xorg/bin/xdm [netbsd-9]: Makefile Makefile.xdm
Log Message:
Pull up following revision(s) (requested by nia in ticket #1510):
external/mit/xorg/bin/xdm/Makefile.xdm: revision 1.11
external/mit/xorg/bin/xdm/Makefile: revision 1.18
external/mit/xorg/bin/xdm/Makefile: revision 1.19
fix the man page generation, noted by uwe@
xdm: Include "sbin" directories (and games) in DEF_USER_PATH.
Upstream's configure.ac picks a DEF_USER_PATH on a per-OS basis.
Most of these include the "sbin" directories, with NetBSD being the
(only?) exception.
However, this is inconsistent with the way a typical login shell is
initialized (when using the default skeleton files). To avoid user
confusion, harmonize DEF_USER_PATH with our other defaults and with
other OSes.
PR xsrc/54851
To generate a diff of this commit:
cvs rdiff -u -r1.17 -r1.17.2.1 src/external/mit/xorg/bin/xdm/Makefile
cvs rdiff -u -r1.10 -r1.10.2.1 src/external/mit/xorg/bin/xdm/Makefile.xdm
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.46 2020/01/03 16:35:01 leot Exp $
$NetBSD: gnats_config.sh,v 1.9 2014/08/02 14:16:04 spz Exp $
Copyright © 1994-2020
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.