Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #261853 > unrolled thread

PATH revisited: one PATH to "rule the [Debian] World"

Back to article view | Back to linux.debian.user

Contents

  PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-24 16:30 +0200
    Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-24 16:50 +0200
      Re: PATH revisited: one PATH to "rule the [Debian] World" Nicolas George <george@nsup.org> - 2023-09-24 20:40 +0200
      Re: PATH revisited: one PATH to "rule the [Debian] World" Michel Verdier <mv524@free.fr> - 2023-09-24 20:40 +0200
    Re: PATH revisited: one PATH to "rule the [Debian] World" Greg Wooledge <greg@wooledge.org> - 2023-09-24 19:30 +0200
    Re: PATH revisited: one PATH to "rule the [Debian] World" debian-user@howorth.org.uk - 2023-09-24 23:30 +0200
      Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-24 23:50 +0200
        Re: PATH revisited: one PATH to "rule the [Debian] World" Greg Wooledge <greg@wooledge.org> - 2023-09-25 00:10 +0200
          Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-25 00:30 +0200
            Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-25 13:10 +0200
              Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-25 16:00 +0200
                Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-25 16:50 +0200
                  Re: PATH revisited: one PATH to "rule the [Debian] World" Greg Wooledge <greg@wooledge.org> - 2023-09-25 17:10 +0200
                    Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-26 22:40 +0200
                      Re: PATH revisited: one PATH to "rule the [Debian] World" Greg Wooledge <greg@wooledge.org> - 2023-09-26 23:10 +0200
                Re: PATH revisited: one PATH to "rule the [Debian] World" Andy Smith <andy@strugglers.net> - 2023-09-25 18:20 +0200
                  Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-26 16:10 +0200
                    Re: PATH revisited: one PATH to "rule the [Debian] World" Andy Smith <andy@strugglers.net> - 2023-09-26 16:30 +0200
                      Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-27 01:20 +0200
                        Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-27 01:40 +0200
                          Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-09-27 03:20 +0200
          Re: PATH revisited: one PATH to "rule the [Debian] World" Jeffrey Walton <noloader@gmail.com> - 2023-09-25 17:30 +0200
    Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-10-27 17:00 +0200
      Re: PATH revisited: one PATH to "rule the [Debian] World" Felix Miata <mrmazda@earthlink.net> - 2023-10-27 19:00 +0200
        Re: PATH revisited: one PATH to "rule the [Debian] World" <tomas@tuxteam.de> - 2023-10-27 19:00 +0200
          Re: PATH revisited: one PATH to "rule the [Debian] World" Stefan Monnier <monnier@iro.umontreal.ca> - 2023-10-27 20:50 +0200
            Re: PATH revisited: one PATH to "rule the [Debian] World" Greg Wooledge <greg@wooledge.org> - 2023-10-27 21:00 +0200
              Re: PATH revisited: one PATH to "rule the [Debian] World" Michael Kjörling <2695bd53d63c@ewoof.net> - 2023-10-27 23:00 +0200
              Re: PATH revisited: one PATH to "rule the [Debian] World" <tomas@tuxteam.de> - 2023-10-28 06:40 +0200
                Re: PATH revisited: one PATH to "rule the [Debian] World" Felix Miata <mrmazda@earthlink.net> - 2023-10-28 07:10 +0200
            Re: PATH revisited: one PATH to "rule the [Debian] World" <tomas@tuxteam.de> - 2023-10-28 06:30 +0200
              Re: PATH revisited: one PATH to "rule the [Debian] World" David Wright <deblis@lionunicorn.co.uk> - 2023-10-29 15:30 +0100
    Re: PATH revisited: one PATH to "rule the [Debian] World" Tom Browder <tom.browder@gmail.com> - 2023-11-02 22:40 +0100
      Re: PATH revisited: one PATH to "rule the [Debian] World" <tomas@tuxteam.de> - 2023-11-03 06:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

#261945

[Multipart message — attachments visible in raw view] — view raw

On Tue, Sep 26, 2023 at 18:32 Tom Browder <tom.browder@gmail.com> wrote:

> On Tue, Sep 26, 2023 at 18:11 Tom Browder <tom.browder@gmail.com> wrote:
>
>> On Tue, Sep 26, 2023 at 16:15 Andy Smith <andy@strugglers.net> 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

[toc] | [prev] | [next] | [standalone]

#261904

On Sun, Sep 24, 2023 at 6:04 PM Greg Wooledge <greg@wooledge.org> 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

[toc] | [prev] | [next] | [standalone]

#262788

On Sun, Sep 24, 2023 at 9:27 AM Tom Browder <tom.browder@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#262804

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

[toc] | [prev] | [next] | [standalone]

#262805

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#262816

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

[toc] | [prev] | [next] | [standalone]

#262818

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          PID    PPID  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.

[toc] | [prev] | [next] | [standalone]

#262826

On 27 Oct 2023 14:52 -0400, from greg@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?”

[toc] | [prev] | [next] | [standalone]

#262831

[Multipart message — attachments visible in raw view] — view raw

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          PID    PPID  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

[toc] | [prev] | [next] | [standalone]

#262833

tomas@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          PID    PPID  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

[toc] | [prev] | [next] | [standalone]

#262829

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#262863

On Sat 28 Oct 2023 at 06:29:19 (+0200), tomas@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.

[toc] | [prev] | [next] | [standalone]

#263061

[Multipart message — attachments visible in raw view] — view raw

On Sun, Sep 24, 2023 at 09:27 Tom Browder <tom.browder@gmail.com> 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

[toc] | [prev] | [next] | [standalone]

#263069

[Multipart message — attachments visible in raw view] — view raw

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<something>

That <something> 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

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.debian.user

csiph-web