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 1 of 2  [1] 2  Next page →

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

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

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

[toc] | [next] | [standalone]

#261854

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

On Sun, Sep 24, 2023 at 09:27 Tom Browder <tom.browder@gmail.com> wrote:

For bash users only, please.

-Tom

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

#261857

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

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

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

#261858

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

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

#261856

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.

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

#261870

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

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

#261872

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

On Sun, Sep 24, 2023 at 16:27 <debian-user@howorth.org.uk> wrote:

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

...

> 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

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

#261873

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.

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

#261875

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

On Sun, Sep 24, 2023 at 17:04 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.


My brain isn't clicking on all eight, but I think you suggested that
before--I'll try that, thanks, Greg!

-Tom

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

#261894

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

On Sun, Sep 24, 2023 at 17:23 Tom Browder <tom.browder@gmail.com> wrote:

> On Sun, Sep 24, 2023 at 17:04 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.
>
> 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

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

#261898

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

On Mon, Sep 25, 2023 at 06:08 Tom Browder <tom.browder@gmail.com> wrote:

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

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

#261900

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

On Mon, Sep 25, 2023 at 08:50 Tom Browder <tom.browder@gmail.com> 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

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

#261901

On Mon, Sep 25, 2023 at 09:40:27AM -0500, Tom Browder wrote:
> On Mon, Sep 25, 2023 at 08:50 Tom Browder <tom.browder@gmail.com> 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.

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

#261940

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

On Mon, Sep 25, 2023 at 10:03 Greg Wooledge <greg@wooledge.org> 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

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

#261942

On Tue, Sep 26, 2023 at 03:37:44PM -0500, Tom Browder wrote:
> On Mon, Sep 25, 2023 at 10:03 Greg Wooledge <greg@wooledge.org> 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.

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

#261906

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

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

#261936

On Mon, Sep 25, 2023 at 17:45 Andy Smith <andy@strugglers.net> 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

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

#261937

Hello,

On Tue, Sep 26, 2023 at 09:05:51AM -0500, Tom Browder wrote:
> On Mon, Sep 25, 2023 at 17:45 Andy Smith <andy@strugglers.net> 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

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

#261943

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

On Tue, Sep 26, 2023 at 16:15 Andy Smith <andy@strugglers.net> 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

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

#261944

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

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.

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web