topic title: cwd in $PATH, really ?
Posts: 69
Ninho
Joined: 28 Oct 2016
#1
Linux quasi-noobie question : I'm seeing my $PATH in antiX (regular user account) starts in dot (current working directory). Even twice fwiw ! I thought it was not good practice, what is the consensus ? How would I most easily remove/repair the double occurrence of dot in PATH, and would the removing possibly break some built-in script, functionality or program ?

Code: Select all

$ echo $PATH
.:.:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games:/sbin:/usr/sbin
[/size]
Posts: 1,445
skidoo
Joined: 09 Feb 2012
#2
If you check echo $PATH from console (Ctrl+Alt+F1--F6) you'll see a different result.
When you see that ( .:.: ) in terminal emulator,"how to get rid of it" could vary, depending on:
-- how the emulator is/was launched (affects whether $ENV is preserved)
-- directives within the emulator's config file
-- which shell (presumably bash) is running in the emulator
-- ^--> the content of your ~/.bashrc (or other rc file for other shell, as applicable)
-- the content of your ~/.profile
-- (certain situations) the content of /etc/bash.bashrc (hmm, or izzit /etc/profile ?)

You're probably seeing double dots because your chosen terminal emulator is naively stacking/concatenating the path stanzas read from those various configs. AFAIK, the status quo of double dots has never caused a problem for me. As for"best practice", shrug. If you would prefer incessantly typing full filepaths, knock yerself out. On my systems, I welcome the presence of leading dot (cwd) in the path envvar.
Posts: 69
Ninho
Joined: 28 Oct 2016
#3
As for"best practice", shrug. If you would prefer incessantly typing full filepaths, knock yerself out. On my systems, I welcome the presence of leading dot (cwd) in the path envvar.
OK, that's the micro$oft way, too __{{emoticon}}__ The issue with cwd in path is somthing (malware...) could easily induce one to execute a malicious replacement for a legitimate command. Well, I guess malware is less a problem on antiX than in Windows (and I've never been"infected" running Windows, either). Thanks for the hint, Skidoo - I am going to leave the dot where it belongs and to ignore the double (triple, even, in a rxvt I'ne just opened now) occurrence.
Posts: 64
reverseDog
Joined: 13 Jul 2016
#4
Ninho wrote:How would I most easily remove/repair the double occurrence of dot in PATH [...],
Open the file /usr/local/lib/desktop-session/lib-desktop-session.sh in an editor and comment the line"PATH=.:$PATH" out.
Ninho wrote:[...] and would the removing possibly break some built-in script, functionality or program ?
Well, I don't feel authorized to answer the second half of your question. But I have removed the double (in my case: triple) dots some hours ago and haven't observed any problems since.
Posts: 69
Ninho
Joined: 28 Oct 2016
#5
reverseDog wrote: comment the line"PATH=.:$PATH" out.
... I have removed the double (in my case: triple) dots some hours ago and haven't observed any problems since.
Thanks, rD ! I'll follow your lead, not expecting problems either.
Posts: 1,445
skidoo
Joined: 09 Feb 2012
#6
The issue with cwd in path is something (malware...)
could easily induce one to execute a malicious replacement for a legitimate command.
You've raised an excellent point. Considering all the other hoops I jump through trying to be safe, I realize that I really shouldn't"shrug".

The user environment isn't preserved by default for sudo user (and leading dot is absent from sudo/root $PATH), and I'm not inclined to
download and run stuff from untrusted sources. I suppose that's my rationalization for not adopting this particular"best practice".
Posts: 1,445
skidoo
Joined: 09 Feb 2012
#7
Back in November, we didn't definitively resolve this, eh?
I'm seeing my $PATH in antiX (regular user account) starts in dot (current working directory). Even twice...
I encountered this (.:.:.:.:.:.:.:.:.:.:.:/usr/bin...) recently while using lxterminal.
Checking roxterm, I found the $PATH was not similarly affected.
Comparing prefs set for the 2 emulators, I noticed that"treat shell as login shell" was checkmarked in my roxterm prefs.
Same wasn't marked in lxterminal prefs, and when I did so, that resolved lxterminal's"weird" pathstring.

========= SCRAPER REMOVED AN EMBEDDED LINK HERE ===========
url was:"http://www.tldp.org/HOWTO/text/Path"
linktext was:"http://www.tldp.org/HOWTO/text/Path"
====================================


sudo command has again a different approach to path handling.
It modifies the search path so that the current directory is always the last one.
However, it does not modify PATH environment variable.
That quoted linuxDocumentationProject page mentions about 8 or 9 places along the way
(between booting... and the context of using an xterm terminal emulator app)
where a configuration file may (re)set the default pathstring declaration for a user (or all users).

That bit I've quoted here, it overlaps with the configured behavior of gksu (and gexec).
IIRC, antiX default gksu configuration instructs"preserve environment" but does not set"treat as login shell".
Can check by typing"gksu" at a terminal emulator prompt... then clicking"advanced" in the gksu dialogbox.
man gksu explains that we can override the preconfigured default(s) by passing optional runtime args.
I checked and found that none of the launchstrings within ControlCenter pass those args to gksu.
(I'm not suggesting that any of the launchstrings should be changed, I'm just documenting the status quo.)
One of the cc launchers (sysv-rc-conf?) does present a confusing inconsistency -- it requires root user's password

Code: Select all

--preserve-env, -k
        Preserve the current environments, does not set $HOME nor $PATH, for example.
--login, -l
       Make this a login shell.
[/color]
Posts: 64
reverseDog
Joined: 13 Jul 2016
#8
skidoo wrote:Checking roxterm, I found the $PATH was not similarly affected.
Comparing prefs set for the 2 emulators, I noticed that"treat shell as login shell" was checkmarked in my roxterm prefs.
Same wasn't marked in lxterminal prefs, and when I did so, that resolved lxterminal's"weird" pathstring.
Since /usr/local/lib/desktop-session/lib-desktop-session.sh is responsible for adding the current working directory (.) to $PATH but doesn't get sourced by login shell, your solution works.

Above I had suggested to comment out the line"PATH=.:$PATH" in /usr/local/lib/desktop-session/lib-desktop-session.sh. But I am not fond though of customizing system-wide files, so I found myself a better way to get rid of those weird cwds in $PATH. I simply added the line

Code: Select all

export PATH=${PATH##+(.:)}
to my ~/.bashrc. __{{emoticon}}__