[solved] what should a $PATH variable in fresh install 2018

lebec · 2018-01-23 02:26:51

I've screwed up my $PATH by club-handed editing.

Would someone be kind enough to share with me what $PATH looks like on fresh install for 2017/18?

Here's mine:

/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/lib/jvm/default/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

The edit I was trying to accomplish was simply to add ":" at the head of the $PATH, so as to execute simple scripts from any directory, independent of where the script is located and what the PWD is; but I can't find the location of $PATH ...
I've tried: ~/.profile (which doesn't exist); ~/.bashrc (which doesn't have $PATH); and I've tried the search for similar threads on LinuxQuestions.org

Thanks kindly in anticipation.

Last edited by lebec (2018-01-23 10:23:51)

Trilby · 2018-01-23 02:37:13

Defaults are set from /etc/login.defs, /etc/profile, and /etc/profile.d/*. If you've editted any of these you can extract the originals from their respective package.

EDIT: I don't, however, see anything wrong with your PATH variable.

Last edited by Trilby (2018-01-23 02:53:17)

Scimmia · 2018-01-23 02:41:01

I could also be set by a display manager independent of the files Trilby mentioned.

ayekat · 2018-01-23 09:00:59

It's a bit strange that there is /bin in there, since in the default filesystem layout on Arch Linux, /bin is set up as a symbolic link to /usr/bin (and thus at least the files Trilby mentioned do not add it to PATH by default). Also having /usr/local/sbin after /usr/local/bin and /usr/bin is a bit odd (although certainly not wrong).

lebec wrote:

The edit I was trying to accomplish was simply to add ":" at the head of the $PATH, so as to execute simple scripts from any directory, independent of where the script is located and what the PWD is;

That is not how PATH works. When you type a command, your shell searches each directory listed in PATH for an executable file named after that command and executes that file. ~~So prepending a colon to the PATH variable has no effect (I believe it's the same as prepending an "empty path", and I believe most shells ignore that).~~ wrong, corrected below, thanks to Trilby for pointing out

Given how the executable is chosen, what you are trying is not possible: Where does the shell search for your script? On the entire system? And what happens if there are multiple scripts with the same name? Which one is chosen and executed?

Last edited by ayekat (2018-01-23 12:50:35)

lebec · 2018-01-23 10:15:01

Thanks kindly: Trilby, Scimmia and ayekat.

Trilby · 2018-01-23 11:47:03

ayekat wrote:

That is not how PATH works... So prepending a colon to the PATH variable has no effect.
Given how the executable is chosen, what you are trying is not possible.

Incorrect. Prepending a colon to PATH will in fact do exactly what the OP wants.

ayekat · 2018-01-23 12:27:24

Oh, should've looked the bit about the leading colon up. Sorry for that (TIL).

Then again, on my machine (in both bash and zsh), it appears to do the same thing as simply adding . to the PATH...—but maybe OP just meant that (I occasionally tend to read written texts too literally, my mistake).

I'm tempted to say that that's an exceptionally bad idea, but whatever, this particular problem is solved. Again, sorry for the noise.

Last edited by ayekat (2018-01-23 12:27:50)

eschwartz · 2018-01-23 18:13:01

ayekat wrote:

It's a bit strange that there is /bin in there, since in the default filesystem layout on Arch Linux, /bin is set up as a symbolic link to /usr/bin (and thus at least the files Trilby mentioned do not add it to PATH by default). Also having /usr/local/sbin after /usr/local/bin and /usr/bin is a bit odd (although certainly not wrong).

Not really strange. Random tools can do whatever they want, and many of those tools (like systemd) can have defaults that are set for the generic state of Linux distros (so as to work everywhere). Of course, a reasonable case can be made to have Arch configure them to match our filesystem standards... and in fact, login.defs had to do just that after we stopped overriding it in /etc/profile.

ayekat wrote:

Oh, should've looked the bit about the leading colon up. Sorry for that (TIL).
Then again, on my machine (in both bash and zsh), it appears to do the same thing as simply adding . to the PATH...—but maybe OP just meant that (I occasionally tend to read written texts too literally, my mistake).
I'm tempted to say that that's an exceptionally bad idea, but whatever, this particular problem is solved. Again, sorry for the noise.

Yes, either zeroed PATH component or a dot will represent "current working directory"

lebec · 2018-01-25 03:42:49

Trilby wrote:

ayekat wrote:
That is not how PATH works... So prepending a colon to the PATH variable has no effect.
Given how the executable is chosen, what you are trying is not possible.
Incorrect. Prepending a colon to PATH will in fact do exactly what the OP wants.

Thanks. I thought I had that right, from a reliable source, and in fact it does work.

Arch Linux

#1 2018-01-23 02:26:51

[solved] what should a $PATH variable in fresh install 2018

#2 2018-01-23 02:37:13

Re: [solved] what should a $PATH variable in fresh install 2018

#3 2018-01-23 02:41:01

Re: [solved] what should a $PATH variable in fresh install 2018

#4 2018-01-23 09:00:59

Re: [solved] what should a $PATH variable in fresh install 2018

#5 2018-01-23 10:15:01

Re: [solved] what should a $PATH variable in fresh install 2018

#6 2018-01-23 11:47:03

Re: [solved] what should a $PATH variable in fresh install 2018

#7 2018-01-23 12:27:24

Re: [solved] what should a $PATH variable in fresh install 2018

#8 2018-01-23 18:13:01

Re: [solved] what should a $PATH variable in fresh install 2018

#9 2018-01-25 03:42:49

Re: [solved] what should a $PATH variable in fresh install 2018

Board footer