Trying to find out where the .
(current directory) entry in PATH
originates, I've run bash as follows:
$ env -i /bin/bash --norc -c 'echo $PATH'
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
Surprisingly, current directory is still listed there. I've then tried using strace
to find out what files bash reads, but found nothing relevant:
$ env -i strace -fefile /bin/bash --norc -c 'echo $PATH' |& grep -v ' ENOENT '
execve("/bin/bash", ["/bin/bash", "--norc", "-c", "echo $PATH"], 0x7fff02c40550 /* 0 vars */) = 0
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libtinfo.so.5", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libdl.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/dev/tty", O_RDWR|O_NONBLOCK) = 3
getcwd("/home/ruslan", 4096) = 13
openat(AT_FDCWD, "/etc/nsswitch.conf", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_compat.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_nis.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnsl.so.1", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnss_files.so.2", O_RDONLY|O_CLOEXEC) = 3
openat(AT_FDCWD, "/etc/passwd", O_RDONLY|O_CLOEXEC) = 3
/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin:.
+++ exited with 0 +++
So, where does bash take this default value for PATH
?
/etc/environment
(which is one candidate, since PATH isn't set in bashrc in Ubuntu by default anyway - so norc is mostly irrelevant), and another suggests it's hardcored in the binary, like you do. – muru Oct 22 '18 at 11:30/etc/environment
is irrelevant becausestrace
here doesn't mention it. And OK, I do now see that answer which supposes that the value is hard-coded, although doesn't show direct evidence of this (which could be done either viastrings
or by source code inspection). Point of this question was to know for sure where the value comes from. – Ruslan Oct 22 '18 at 12:29strings
. And no,/etc/environment
is only irrelevant in this specific invocation. Bash never reads it itself. Other applications do, and then start bash with that environment, that's why you'll never see PATH being set in any file bash sources in Ubuntu (they all merely add to it). – muru Oct 22 '18 at 13:30env -i
I used to startstrace
. No one here had any chance of reading/etc/environment
(unlessstrace
did, but that would be strange). As forstrings
— well, yes, I've been too inattentive when reading, sorry. – Ruslan Oct 22 '18 at 14:18