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:

NetBSD Home
NetBSD PR Database Search

(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.