Re: PATH revisited: one PATH to "rule the [Debian] World"
On Thu, Nov 02, 2023 at 04:34:42PM -0500, Tom Browder wrote: [...] > ANOTHER LESSON LEARNED > > While I was experimenting with the desktop settings, I stupidly and blindly > added an exit line to cut out some 20-year old cruft in the end of the > .profile file and all of a sudden I lost my xterms and couldn't find a way > to edit the broken file [...] There's always the Linux console, usually to be found at CTRL-F That tends to vary because the young-uns like to move it around. For me it's CTRL-F1, but others will chime in on what is fashionable these days. Cheers -- t signature.asc Description: PGP signature
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 09:27 Tom Browder wrote: > Every time I set up a new host, I have to jump through the hoops trying to On my main Debian 11 host I have found one formula that works for ssh logins as well as xterm login on a Mate desktop: I followed most of the formulas on the Debian wiki and suggestions made here plus some experimentation and did this: 1. Set my desired path for users in file /etc/environment $ cat /etc/environment PATH=/opt/rakudo/bin:/opt/rakudo/share/perl6/site/bin:/usr/local/bin:/usr/bin 2. I put the identical path in the usr PATH entry in file /etc/profile 3. I copied my .profile file to .xsessionrc. The result was, regardless of login method, as a normal user I had the same PATH (plus any changes from my ~/.profile file). 4. I modified the root PATH entry in file /etc/profile When I became root via "sudo -s" I got root's path from /etc/profile. When I became root via "sudo -i" I got the desired PATH change from root's ~/.profile. So far, I'm a happy camper! ANOTHER LESSON LEARNED While I was experimenting with the desktop settings, I stupidly and blindly added an exit line to cut out some 20-year old cruft in the end of the .profile file and all of a sudden I lost my xterms and couldn't find a way to edit the broken file. Fortunately, I had emacs as one of my menu items: I chose the GUI version and was able to repair the .profile file successfully. Maybe another editor would have worked, but I'm not going to experiment with that any time soon! -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sat 28 Oct 2023 at 06:29:19 (+0200), to...@tuxteam.de wrote: > On Fri, Oct 27, 2023 at 02:46:55PM -0400, Stefan Monnier wrote: > > >> > https://wiki.debian.org/EnvironmentVariables > > >> It needs some TLC: > > >> [quote] > > >> 1. At the end of booting, the mother of all processes -- init -- is > > >> started. > > >> 2. init runs services as described above. > > >> [/quote] > > >> > > >> Isn't this rather obsolete as long as systemd has been with us? > > > > > > Systemd is just an init by another name. It's process 1 and still > > > is the mother of all processes. > > > > I don't think there's a need to defend the status quo: the above page > > may not be fully incorrect, but it is misleading (especially since the > > `init` is given a monospace font, > > This is misleading indeed. A bit of more detail won't hurt, i.e. that > you can tell your kernel to use another init in the command line (that's > how systemd gets started: "init=/lib/systemd", AFAIK) I think more detail /does/ hurt, as does the edit of 2023-10-27 23:03:36 (though I'm not trying to criticise your best of intentions). The focus of the page should be . what environment variables are and how they're set/used, . the ones that are set by the system and/or are expected by any linux user, . where they can be, and are, set under different login regimes, . the su change. I think this wiki page should attempt (even if it can't necessarily succeed) to answer the FAQ expressed in the Subject line above, and not get filled with extraneous information. The Quick Start and Notes and Exceptions are reasonable, except for the latest addition, "SysV, Systemd and init". There's a "BootProcess" wiki page where this would be a better fit, and this page needs a lot of updating for modern times. Then there's an "Init" wiki page for describing the two flavours, systemd and sysv, and comparing and contrasting them. This should stick to inits that bring up a Debian system, about which there's plenty to say. After all, "Init's /job/ is to start other programs that are essential to the operation of your system." But telling the kernel to start an arbitrary process doesn't give it that /job/, so that option should be treated under either a boot or a system recovery (the typical use) page. > > to suggest it's an actual program name > > rather than just the name used to refer to the concept of the initial > > process). > > Agreed. > > > Even saying that "At the end of boot the mother of all processes init is > > started" is quite confusing, IMO: while it might be true that it happens > > when the *kernel* finishes the boot, I personally tend to consider this > > to be rather closer the beginning than the end of the overall > > boot process. > > The one person's boots are another person's socks, true. The range of > "boot" goes from the boot loader loading the kernel up to some desktop > environment up and ready. Yes, and there's a sequence of wiki pages (some a bit rusty) available for each step. Cheers, David.
Re: PATH revisited: one PATH to "rule the [Debian] World"
to...@tuxteam.de composed on 2023-10-28 06:36 (UTC+0200): > On Fri, Oct 27, 2023 at 02:52:37PM -0400, Greg Wooledge wrote: >> On Fri, Oct 27, 2023 at 02:46:55PM -0400, Stefan Monnier wrote: >>> I don't think there's a need to defend the status quo: the above page >>> may not be fully incorrect, but it is misleading (especially since the >>> `init` is given a monospace font, to suggest it's an actual program name >>> rather than just the name used to refer to the concept of the initial >>> process). >> unicorn:~$ ps -fp 1 >> UID PIDPPID C STIME TTY TIME CMD >> root 1 0 0 Oct07 ?00:01:58 /sbin/init >> unicorn:~$ ls -l /sbin/init >> lrwxrwxrwx 1 root root 20 Sep 20 08:15 /sbin/init -> /lib/systemd/systemd* # dpkg-query -S /lib/systemd/systemd systemd: /lib/systemd/systemd # >> /sbin/init is what gets executed by the kernel, regardless of what init >> system is installed. This seems backwards. The kernel may call /sbin/init, but what gets executed is surely /lib/systemd/systemd from package named systemd. # grep RETT /etc/os-release PRETTY_NAME="Debian GNU/Linux 12 (bookworm)" # apt purge systemd-sysv ... Suggested packages: bootlogd Recommended packages: orphan-sysvinit-scripts The following packages will be REMOVED: alsa-tools-gui* arandr* dbus-user-session* dconf-gsettings-backend* dconf-service* gir1.2-gtk-3.0* gtk3-tqt-engine-trinity* libgtk-3-0* libgtk-3-bin* libgtk-3-common* libpam-systemd* pkexec* polkitd* systemd-sysv* The following NEW packages will be installed: sysvinit-core ... Do you want to continue? [Y/n] n Abort. # > Unless you boot (heh) with an "init=" parameter. AFAIK, this link is > provided by the systemd-sysv [0] compatibility package, which, as it > seems, you don't /have/ to install. > This is what the systemd [1] package page says: > "Installing the systemd package will not switch your init >system unless you boot with init=/lib/systemd/systemd or >install systemd-sysv in addition." This would appear to be an anachronism since systemd became the default Debian init system. > so strictly speaking, Stefan is still right. No posts from Greg have arrived here in at least two days, or I would have replied to his directly. -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Fri, Oct 27, 2023 at 02:52:37PM -0400, Greg Wooledge wrote: > On Fri, Oct 27, 2023 at 02:46:55PM -0400, Stefan Monnier wrote: > > I don't think there's a need to defend the status quo: the above page > > may not be fully incorrect, but it is misleading (especially since the > > `init` is given a monospace font, to suggest it's an actual program name > > rather than just the name used to refer to the concept of the initial > > process). > > unicorn:~$ ps -fp 1 > UID PIDPPID C STIME TTY TIME CMD > root 1 0 0 Oct07 ?00:01:58 /sbin/init > > unicorn:~$ ls -l /sbin/init > lrwxrwxrwx 1 root root 20 Sep 20 08:15 /sbin/init -> /lib/systemd/systemd* > > /sbin/init is what gets executed by the kernel, regardless of what init > system is installed. Unless you boot (heh) with an "init=" parameter. AFAIK, this link is provided by the systemd-sysv [0] compatibility package, which, as it seems, you don't /have/ to install. This is what the systemd [1] package page says: "Installing the systemd package will not switch your init system unless you boot with init=/lib/systemd/systemd or install systemd-sysv in addition." so strictly speaking, Stefan is still right. Cheers [0] https://packages.debian.org/bookworm/systemd-sysv [1] https://packages.debian.org/bookworm/systemd -- tomás signature.asc Description: PGP signature
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Fri, Oct 27, 2023 at 02:46:55PM -0400, Stefan Monnier wrote: > >> > https://wiki.debian.org/EnvironmentVariables > >> It needs some TLC: > >> [quote] > >> 1. At the end of booting, the mother of all processes -- init -- is > >> started. > >> 2. init runs services as described above. > >> [/quote] > >> > >> Isn't this rather obsolete as long as systemd has been with us? > > > > Systemd is just an init by another name. It's process 1 and still > > is the mother of all processes. > > I don't think there's a need to defend the status quo: the above page > may not be fully incorrect, but it is misleading (especially since the > `init` is given a monospace font, This is misleading indeed. A bit of more detail won't hurt, i.e. that you can tell your kernel to use another init in the command line (that's how systemd gets started: "init=/lib/systemd", AFAIK) > to suggest it's an actual program name > rather than just the name used to refer to the concept of the initial > process). Agreed. > Even saying that "At the end of boot the mother of all processes init is > started" is quite confusing, IMO: while it might be true that it happens > when the *kernel* finishes the boot, I personally tend to consider this > to be rather closer the beginning than the end of the overall > boot process. The one person's boots are another person's socks, true. The range of "boot" goes from the boot loader loading the kernel up to some desktop environment up and ready. The only recipe I've got to mitigate this is to take part in a local free software user's group and talk to people :-) Cheers -- t signature.asc Description: PGP signature
Re: PATH revisited: one PATH to "rule the [Debian] World"
On 27 Oct 2023 14:52 -0400, from g...@wooledge.org (Greg Wooledge): > /sbin/init is what gets executed by the kernel, regardless of what init > system is installed. Unless, of course, one passes the kernel parameter `init=` pointing to some other executable file, such as /bin/sh. Not saying either is necessarily right or wrong, but the concept of something being "init" is rather deeply entrenched in the *nix world, and probably has been ever since the humble beginnings on that DEC PDP in the late 1960s... -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Fri, Oct 27, 2023 at 02:46:55PM -0400, Stefan Monnier wrote: > I don't think there's a need to defend the status quo: the above page > may not be fully incorrect, but it is misleading (especially since the > `init` is given a monospace font, to suggest it's an actual program name > rather than just the name used to refer to the concept of the initial > process). unicorn:~$ ps -fp 1 UID PIDPPID C STIME TTY TIME CMD root 1 0 0 Oct07 ?00:01:58 /sbin/init unicorn:~$ ls -l /sbin/init lrwxrwxrwx 1 root root 20 Sep 20 08:15 /sbin/init -> /lib/systemd/systemd* /sbin/init is what gets executed by the kernel, regardless of what init system is installed.
Re: PATH revisited: one PATH to "rule the [Debian] World"
>> > https://wiki.debian.org/EnvironmentVariables >> It needs some TLC: >> [quote] >> 1. At the end of booting, the mother of all processes -- init -- is started. >> 2. init runs services as described above. >> [/quote] >> >> Isn't this rather obsolete as long as systemd has been with us? > > Systemd is just an init by another name. It's process 1 and still > is the mother of all processes. I don't think there's a need to defend the status quo: the above page may not be fully incorrect, but it is misleading (especially since the `init` is given a monospace font, to suggest it's an actual program name rather than just the name used to refer to the concept of the initial process). Even saying that "At the end of boot the mother of all processes init is started" is quite confusing, IMO: while it might be true that it happens when the *kernel* finishes the boot, I personally tend to consider this to be rather closer the beginning than the end of the overall boot process. Stefan
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Fri, Oct 27, 2023 at 12:54:34PM -0400, Felix Miata wrote: > Tom Browder composed on 2023-10-27 09:52 (UTC-0500): > > > Tom Browder wrote: > > >> Every time I set up a new host, I have to jump through the hoops trying to > >> get the same PATH for > >> ordinary users as well as root... > > > This Debian wiki doc pretty much details the information Greg has been > > giving us: > > > https://wiki.debian.org/EnvironmentVariables > > It needs some TLC: > > [quote] > 1. At the end of booting, the mother of all processes -- init -- is started. > > 2. init runs services as described above. > [/quote] > > Isn't this rather obsolete as long as systemd has been with us? Systemd is just an init by another name. It's process 1 and still is the mother of all processes. Besides, (SysV) init is still alive and well, too. Cheers -- t signature.asc Description: PGP signature
Re: PATH revisited: one PATH to "rule the [Debian] World"
Tom Browder composed on 2023-10-27 09:52 (UTC-0500): > Tom Browder wrote: >> Every time I set up a new host, I have to jump through the hoops trying to >> get the same PATH for >> ordinary users as well as root... > This Debian wiki doc pretty much details the information Greg has been > giving us: > https://wiki.debian.org/EnvironmentVariables It needs some TLC: [quote] 1. At the end of booting, the mother of all processes -- init -- is started. 2. init runs services as described above. [/quote] Isn't this rather obsolete as long as systemd has been with us? -- Evolution as taught in public schools is, like religion, based on faith, not based on science. Team OS/2 ** Reg. Linux User #211409 ** a11y rocks! Felix Miata
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 9:27 AM Tom Browder wrote: > > Every time I set up a new host, I have to jump through the hoops trying to > get the same PATH for > ordinary users as well as root... This Debian wiki doc pretty much details the information Greg has been giving us: https://wiki.debian.org/EnvironmentVariables Thanks, all! -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Tue, Sep 26, 2023 at 18:32 Tom Browder wrote: > On Tue, Sep 26, 2023 at 18:11 Tom Browder wrote: > >> On Tue, Sep 26, 2023 at 16:15 Andy Smith wrote: >> > ... > >> Well, I wanted to do it all in one program, but I guess I could break it >> up into two separate programs. I'll have to think about what I'm really >> trying to do. >> > > Another issue is precompilation. I need to find out how to work around > that somehow. Otherwise I would need two separate modules instead of the > single one I'm currently using. > One of our experts says that is not a problem, so I'm heading in that direction. -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Tue, Sep 26, 2023 at 18:11 Tom Browder wrote: > On Tue, Sep 26, 2023 at 16:15 Andy Smith wrote: > ... > Well, I wanted to do it all in one program, but I guess I could break it > up into two separate programs. I'll have to think about what I'm really > trying to do. > Another issue is precompilation. I need to find out how to work around that somehow. Otherwise I would need two separate modules instead of the single one I'm currently using.
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Tue, Sep 26, 2023 at 16:15 Andy Smith wrote: > Hello, ... Why does any of that stop you from only using the dev Raku once > you've used the packaged Raku to install it? Well, I wanted to do it all in one program, but I guess I could break it up into two separate programs. I'll have to think about what I'm really trying to do. Thanks for your input, Andy. -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Tue, Sep 26, 2023 at 03:37:44PM -0500, Tom Browder wrote: > On Mon, Sep 25, 2023 at 10:03 Greg Wooledge wrote: > ... > > Greg, one more file I don't think we've discussed: '~/.bash_aliases'. > > How should I handle that in this variable login climate? That's not a standard file. Debian does not create it, and bash does not read it. It only gets read if you source it from some other file, like ~/.bashrc. The /etc/skel/.bashrc provided by Debian will source it if it exists. As far as management goes, since it's sourced by .bashrc it should be treated like it's part of .bashrc. If you're asking "Should I create it? Should I put things in it, if I find it?" I would say no to both. If an individual user wants to use it, that's their choice, but you shouldn't assume it exists, or that it *should* exist, or that it will be read if it does exist. But that's just me. If you're asking "Should I modify .bashrc (or one of its sourced files)?" that's a much more complicated question. The normal reasons people put environmental configuration into .bashrc are: 1) Because they only care about the environment in their terminals, not in their GUI apps. 2) Because they want the simplest choice, not the most efficient choice, and they don't care how often the environment configuration commands are re-executed. 3) Because they're using a desktop which overrides the X or Wayland session environment, and disabling that is either impossible, or too hard for them to discover. 4) Because they're using a desktop where the terminal environment is NOT inherited from the X or Wayland environment, so duplicating environment configuration commands in .bashrc is needed to get their effects in terminals.
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Mon, Sep 25, 2023 at 10:03 Greg Wooledge wrote: ... Greg, one more file I don't think we've discussed: '~/.bash_aliases'. How should I handle that in this variable login climate? Thanks. -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
Hello, On Tue, Sep 26, 2023 at 09:05:51AM -0500, Tom Browder wrote: > On Mon, Sep 25, 2023 at 17:45 Andy Smith wrote: > ... > > I'd make it all run with one raku from one place, or else I'd > > specify the full path to the special raku that is needed. […] > You do not understand the problem, Andy: Debian's package version of > raku is over two years old, and it is NOT installed by default. My > script uses that raku as a bootstrap to update to the latest release > provided as a Debian package format similar to the manner in which > PostgreSQL can be maintained in its latest state with an out-of-Debian > package location. Why does any of that stop you from only using the dev Raku once you've used the packaged Raku to install it? You're right, I don't understand. Your use case sounds the same as any I've had to accomplish with development versions of Perl, Python, Ruby, Go, Rust etc for multiple decades now. I do not understand why your situation, with Raku, is special in any way. Perhaps it's some aspect of Raku that I don't understand, not being familiar with that, so I should leave it to others who maybe do understand that. Best of luck! Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Mon, Sep 25, 2023 at 17:45 Andy Smith wrote: ... > I'd make it all run with one raku from one place, or else I'd > specify the full path to the special raku that is needed. > > Anything else sounds like a great foot-gun left lying around for > others or myself a week from now. > > Perl and Python virtual environments typically have a script which > sets the path to the interpreter once you enter them, and then > everything is self-contained from there. ... You do not understand the problem, Andy: Debian's package version of raku is over two years old, and it is NOT installed by default. My script uses that raku as a bootstrap to update to the latest release provided as a Debian package format similar to the manner in which PostgreSQL can be maintained in its latest state with an out-of-Debian package location. Perl, on the other hand, is very current, installed as a default Debian package, and not changing as fast as raku (improved releases almost every month). Python is its own weird thing which I ignore as much as possible. Cheers! -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
Hello, On Mon, Sep 25, 2023 at 08:50:52AM -0500, Tom Browder wrote: > I failed to say my program is a bit more > complicated: > > 0. It's executed by 'root'. > 1. It uses 'raku'. > 2. During its operation, the location of the 'raku' version to be used > after it completes changes from '/usr/local/bin' to '/opt/rakudo-pkg/bin'. > 3. Due to requirement 2, I don't think it's safe to attempt to overwrite > current executables with a symlink to new executables of the same basename. If you have a program that REQUIRES to call raku at /usr/local/bin/raku by invoking "raku" with no path and then REQUIRES to call raku at /opt/rakudo-pkg/bin/raku by calling "raku" with no path, then I think that is an insane set of requirements up with which I would not put. I'd make it all run with one raku from one place, or else I'd specify the full path to the special raku that is needed. Anything else sounds like a great foot-gun left lying around for others or myself a week from now. Perl and Python virtual environments typically have a script which sets the path to the interpreter once you enter them, and then everything is self-contained from there. Cheers, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 6:04 PM Greg Wooledge wrote: > > On Sun, Sep 24, 2023 at 04:45:11PM -0500, Tom Browder wrote: > > I'm sure I was too casual in my comments. I want all users, including root, > > to have the Raku executables in their PATH, nothing else would be changed > > from current use. > > Ah, good old X-Y. > > Create symlinks from /usr/local/bin/ to wherever the programs are > physically installed. Then don't touch PATH at all. ++ But I would use a shell script and set LD_IBRARY_PATH accordingly. Maybe something similar to this: $ cat /usr/bin/fop #!/usr/bin/env bash if [[ -z "$JAVA_HOME" ]]; then JAVA_HOME=$(readlink -f $(command -v java) | sed "s|/bin/java$||") export JAVA_HOME fi CLASSPATH=/opt/local/bin/fop-2.9:/opt/local/bin/fop-2.9/lib export CLASSPATH /opt/local/bin/fop-2.9/fop/fop $* I use the script for DocBook and fop manually installed in /opt/local. Since fop is Java, the script needs to set CLASSPATH rather than LD_LIBRARY_PATH. Jeff
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Mon, Sep 25, 2023 at 09:40:27AM -0500, Tom Browder wrote: > On Mon, Sep 25, 2023 at 08:50 Tom Browder wrote: > ... > > > I think I need to have the program change all the path-affecting files > > specified by Greg and others so that PATH includes both locations with the > > new location coming before the original location. > > > ... > > And that all got me looking at 'adduser' and '/etc/skel' where I do not see > an '.xsessionrc' file. Does it cause harm if one logs into a remote host > regardless of its lack or presence of various graphics features? /etc/skel contains a *very* minimal set of dot files. It doesn't include any for customizing X sessions. Presumably most users just use their desktop environment control panels, and never actually manage to change environment variables like PATH. The .xsessionrc file (as opposed to .xsession) is a Debian invention, and is sourced at the start of any Debian X session, whether it's started by startx, or a display manager. It's a great place to set variables that need to be set for the duration of an X session. Of course, it does nothing for console/ssh sessions. I offer these caveats for dealing with .xsessionrc: 1) It's Debian-specific, so it does not help if your HOME directory is shared by FreeBSD, Arch Linux, etc. 2) It may or may not do anything with Wayland. I simply don't know. 3) Its settings may be overridden by a desktop environment or WM. 4) Some desktop environments (GNOME being one) launch their terminals via a convoluted mechanism which does NOT inherit its environment from the X session. So, in these setups, variables set in .xsessionrc might work in GUI apps, but not in terminals.
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Mon, Sep 25, 2023 at 08:50 Tom Browder wrote: ... > I think I need to have the program change all the path-affecting files > specified by Greg and others so that PATH includes both locations with the > new location coming before the original location. > ... And that all got me looking at 'adduser' and '/etc/skel' where I do not see an '.xsessionrc' file. Does it cause harm if one logs into a remote host regardless of its lack or presence of various graphics features? -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Mon, Sep 25, 2023 at 06:08 Tom Browder wrote: > On Sun, Sep 24, 2023 at 17:23 Tom Browder wrote: > >> On Sun, Sep 24, 2023 at 17:04 Greg Wooledge wrote: >> >>> On Sun, Sep 24, 2023 at 04:45:11PM -0500, Tom Browder wrote: >>> > I'm sure I was too casual in my comments. I want all users, including >>> root, >>> > to have the Raku executables in their PATH, nothing else would be >>> changed >>> > from current use >> >> ... > >> Ah, good old X-Y. >> >> Create symlinks from /usr/local/bin/ to wherever the programs are >>> physically installed. Then don't touch PATH at all. >> >> My brain isn't clicking on all eight, but I think you suggested that >> before--I'll try that, thanks, Greg! >> > Well, that's not going to work. I failed to say my program is a bit more complicated: 0. It's executed by 'root'. 1. It uses 'raku'. 2. During its operation, the location of the 'raku' version to be used after it completes changes from '/usr/local/bin' to '/opt/rakudo-pkg/bin'. 3. Due to requirement 2, I don't think it's safe to attempt to overwrite current executables with a symlink to new executables of the same basename. I think I need to have the program change all the path-affecting files specified by Greg and others so that PATH includes both locations with the new location coming before the original location. Then the script can safely remove the original version. -Tom
Re: Message IDs, was Re: PATH revisited: one PATH to "rule the [Debian] World"
David Wright wrote: > On Sun 24 Sep 2023 at 13:05:32 (-0400), Dan Ritter wrote: > > Set it in /etc/profile, which probably has this in it: > > Dan, could you check the configuration of your (?new since early > August) MUA, because you seem to have been able to post your reply > dated Sun, 24 Sep 2023 13:05:32 -0400 using a Message-ID ?? identical > to your post dated Thu, 14 Sep 2023 11:00:17 -0400 entitled "Re: > usrmerge on root NFS will not be run automatically". Thank you! This should be solved now. -dsr-
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 17:23 Tom Browder wrote: > On Sun, Sep 24, 2023 at 17:04 Greg Wooledge wrote: > >> On Sun, Sep 24, 2023 at 04:45:11PM -0500, Tom Browder wrote: >> > I'm sure I was too casual in my comments. I want all users, including >> root, >> > to have the Raku executables in their PATH, nothing else would be >> changed >> > from current use > > ... > Ah, good old X-Y. > > Create symlinks from /usr/local/bin/ to wherever the programs are >> physically installed. Then don't touch PATH at all. > > My brain isn't clicking on all eight, but I think you suggested that > before--I'll try that, thanks, Greg! > And the reason was it requires linking a bunch of executables and I didn't have time to do that. Now I'm scripting the job. -Tom
When a random string is not random (was Re: PATH revisited: one PATH to "rule the [Debian] World")
On 25/09/2023 00:27, Greg Wooledge wrote: On Sun, Sep 24, 2023 at 01:05:32PM -0400, Dan Ritter wrote: Tom Browder wrote: Every time I set up a new host, I have to jump through the hoops trying to get the same PATH for ordinary users as well as root, regardless of how they log in. Reading the man pages doesn't help my old brain with all the caveats. I see the message from Dan Ritter neither on lists.debian.org nor on news.gmane.io. It seems, the person sends messages with fixed Message-ID: <3a6b048e-84db-4a47-969c-b62c826e0...@randomstring.org>. At first I thought it is a mailer bug, but the host name is quite specific. Look at https://lists.debian.org/debian-user/2023/09/threads.html#00175 It is a real mess of unrelated subjects merged into single thread. I suspected that it is Gene who may start a discussion unrelated to original thread, but this case the cause is different. The message from Greg: https://lists.debian.org/debian-user/2023/09/msg00491.html Notice References: Re: usrmerge on root NFS will not be run automatically From: Dan Ritter Due to the In-Reply-To header. Certainly Greg replied to another message, but it was dropped by archivers. So if you see that somebody posted a message to a wrong thread, it is not necessary their fault.
Message IDs, was Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun 24 Sep 2023 at 13:05:32 (-0400), Dan Ritter wrote: > Tom Browder wrote: > > Every time I set up a new host, I have to jump through the hoops trying to > > get the same PATH for ordinary users as well as root, regardless of how > > they log in. Reading the man pages doesn't help my old brain with all the > > caveats. > > > Set it in /etc/profile, which probably has this in it: [ … etc … ] Dan, could you check the configuration of your (?new since early August) MUA, because you seem to have been able to post your reply dated Sun, 24 Sep 2023 13:05:32 -0400 using a Message-ID ¹ identical to your post dated Thu, 14 Sep 2023 11:00:17 -0400 entitled "Re: usrmerge on root NFS will not be run automatically". A word of explanation to people who read debian-user from the web rather than being subscribed: it would appear that Dan's message will not appear on https://lists.debian.org/debian-user/2023/09/ because of its duplicate Message-ID. Looking back at some other threads, I notice that your first post to gene in the thread "raid10 access problem" has a Message-ID ² that appears to have been used subsequently (check the References at https://lists.debian.org/debian-user/2023/09/msg00179.html in gene's reply). And if you look at the References in Marco's post at https://lists.debian.org/debian-user/2023/09/msg00310.html it appears that there has been a conversation between you and Marco (on-list or off-list?) during 14–15th Sep, in which the Message-ID shown at ¹ has been used to identify four different posts of yours. ¹ <3a6b048e-84db-4a47-969c-b62c826e0...@randomstring.org> ² <34dbc5be-529a-4f47-9a51-3b0904019...@randomstring.org> Cheers, David.
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 17:04 Greg Wooledge wrote: > On Sun, Sep 24, 2023 at 04:45:11PM -0500, Tom Browder wrote: > > I'm sure I was too casual in my comments. I want all users, including > root, > > to have the Raku executables in their PATH, nothing else would be changed > > from current use. > > Ah, good old X-Y. > > Create symlinks from /usr/local/bin/ to wherever the programs are > physically installed. Then don't touch PATH at all. My brain isn't clicking on all eight, but I think you suggested that before--I'll try that, thanks, Greg! -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 04:45:11PM -0500, Tom Browder wrote: > I'm sure I was too casual in my comments. I want all users, including root, > to have the Raku executables in their PATH, nothing else would be changed > from current use. Ah, good old X-Y. Create symlinks from /usr/local/bin/ to wherever the programs are physically installed. Then don't touch PATH at all.
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 16:27 wrote: > Tom Browder wrote: > > Every time I set up a new host, I have to jump through the hoops > > trying to get the same PATH for ordinary users as well as root, ... > Setting the same path for ordinary users as for root sounds like > something only a fool would do, so I don't think there's a foolproof > way to do it. I'm trying not to be a fool--that's why I'm checking with the Debian community. I'm sure I was too casual in my comments. I want all users, including root, to have the Raku executables in their PATH, nothing else would be changed from current use. When I get the path-setting portion of my program ready, I will show the pertinent parts here along with a link to the complete code. Note I will ensure any file modified will have its current state backed up prior to changing it. Cheers! -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
Tom Browder wrote: > Every time I set up a new host, I have to jump through the hoops > trying to get the same PATH for ordinary users as well as root, > regardless of how they log in. Reading the man pages doesn't help my > old brain with all the caveats. > > Can anyone offer a foolproof, programmatic solution to my conumdrum? Setting the same path for ordinary users as for root sounds like something only a fool would do, so I don't think there's a foolproof way to do it. Perhaps if you explained exactly what you want to achive somebody could help. > Thanks. > > -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 15:55 Michael Kjörling <2695bd53d...@ewoof.net> wrote: > On 24 Sep 2023 15:45 -0500, from tom.brow...@gmail.com (Tom Browder): > > Bummer, unfortunately, that's the answer I expected. Now if I can find a > > clean way to do that consistently. > > Well, I still think the gist of my suggestion stands: make a script to > set up $PATH the way you want it (for both root and non-root users > respectively); put that script somewhere, anywhere really; and invoke > it from where you need $PATH set up. > > That way, if you miss some path (no pun intended), all you need is to > figure out how to execute or source a script through there in such a > way that it affects the resultant environment; and if you want to make > adjustments later, you can do that in _one_ location. In effect, I will doing that. I'm in the process of automating non-package installation of Raku on modern Debian hosts. That was the genesis of my question, and I will be inserting the required PATH info at the approriate place for any login type as pointed out by Greg and the Debian docs. Thanks, Michael and Greg. -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
On 24 Sep 2023 15:45 -0500, from tom.brow...@gmail.com (Tom Browder): > Bummer, unfortunately, that's the answer I expected. Now if I can find a > clean way to do that consistently. Well, I still think the gist of my suggestion stands: make a script to set up $PATH the way you want it (for both root and non-root users respectively); put that script somewhere, anywhere really; and invoke it from where you need $PATH set up. That way, if you miss some path (no pun intended), all you need is to figure out how to execute or source a script through there in such a way that it affects the resultant environment; and if you want to make adjustments later, you can do that in _one_ location. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 14:52 Greg Wooledge wrote: ... > All you can do is put your desired configuration changes in ALL of > the applicable places for all of the login types that are possible on > your system. That's it. There is no other way. ... Bummer, unfortunately, that's the answer I expected. Now if I can find a clean way to do that consistently. Thanks, Greg. -Tom
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 07:42:32PM +, Michael Kjörling wrote: > On 24 Sep 2023 13:05 -0400, from d...@randomstring.org (Dan Ritter): > > Set it in /etc/profile, which probably has this in it: > > I would rather suggest a separate script in /etc/profile.d to either > add to or replace the contents of $PATH. If I'm reading /etc/profile > right, *.sh in that directory are executed in lexicographic order > right at the end. All of which is a red herring, because /etc/profile and the things dotted in from it are only applicable to login mechanisms that involve a shell. In the case of an X session consisting of a window manager, executed directly from a display manager, there is no login shell at any time, and therefore nothing reads /etc/profile. One may configure such an X session by editing ~/.xsession or other files of that nature, and that will indeed configure your environment as desired -- for X sessions. But you'll have a different environment if you login on a text console and don't do "startx", or if you login by ssh. There is NO configuration mechanism that works for all logins. None. I've been up and down this road for 30 years. It doesn't exist. I would have found it by now. All you can do is put your desired configuration changes in ALL of the applicable places for all of the login types that are possible on your system. That's it. There is no other way.
Re: PATH revisited: one PATH to "rule the [Debian] World"
On 24 Sep 2023 13:05 -0400, from d...@randomstring.org (Dan Ritter): > Set it in /etc/profile, which probably has this in it: I would rather suggest a separate script in /etc/profile.d to either add to or replace the contents of $PATH. If I'm reading /etc/profile right, *.sh in that directory are executed in lexicographic order right at the end. -- Michael Kjörling https://michael.kjorling.se “Remember when, on the Internet, nobody cared that you were a dog?”
Re: PATH revisited: one PATH to "rule the [Debian] World"
Michel Verdier (12023-09-24): > This one is easy : bash read /etc/bash.bashrc and ~/.bashrc. Only for interactive shells. There are no interactive shells in the ancestry of your desktop environment if you log from a display manager. If it was so easy, the OP would have found it. -- Nicolas George signature.asc Description: PGP signature
Re: PATH revisited: one PATH to "rule the [Debian] World"
On 2023-09-24, Tom Browder wrote: > For bash users only, please. This one is easy : bash read /etc/bash.bashrc and ~/.bashrc. Add export PATH in ~/.bashrc to set it per user, or in /etc/bash.bashrc for system wide
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 01:05:32PM -0400, Dan Ritter wrote: > Tom Browder wrote: > > Every time I set up a new host, I have to jump through the hoops trying to > > get the same PATH for ordinary users as well as root, regardless of how > > they log in. Reading the man pages doesn't help my old brain with all the > > caveats. > > > Set it in /etc/profile, which probably has this in it: > > if [ "$(id -u)" -eq 0 ]; then > PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" > else > PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games" > fi > export PATH This file is only read by certain login methods. The whole point of Tom's request was to find something that works for *all* login methods. Sadly, no such thing exists.
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 09:27:36AM -0500, Tom Browder wrote: > Every time I set up a new host, I have to jump through the hoops trying to > get the same PATH for ordinary users as well as root, regardless of how > they log in. Reading the man pages doesn't help my old brain with all the > caveats. > > Can anyone offer a foolproof, programmatic solution to my conumdrum? Nope. There is no simple, foolproof, login-method-agnostic solution. The only login-method-agnostic tool available to you is pam_env and this triggers too early. You can set a PATH that way, but then the login shell, or the desktop environment, takes over and overwrites the PATH. systemd offers nothing which addresses this either. It only has things that LOOK like they might work, but then they turn out to do nothing (they are not used by logins). That's a dead end. So, at the end of the day, you're right back where you started. All environment customizations are unique to the login method and the shell and the desktop environment of the individual system and user.
Re: PATH revisited: one PATH to "rule the [Debian] World"
On Sun, Sep 24, 2023 at 09:27 Tom Browder wrote: For bash users only, please. -Tom
PATH revisited: one PATH to "rule the [Debian] World"
Every time I set up a new host, I have to jump through the hoops trying to get the same PATH for ordinary users as well as root, regardless of how they log in. Reading the man pages doesn't help my old brain with all the caveats. Can anyone offer a foolproof, programmatic solution to my conumdrum? Thanks. -Tom
