4 ms·

If you link /bin to /usr/bin then all binaries will be available under /bin, and developers will hardcode paths like /bin/python3. This will make programs non-p

If you link /bin to /usr/bin then all binaries will be available under /bin, and developers will hardcode paths like /bin/python3. This will make programs non-portable to other distributiobns with separate /bin and /usr/bin. The link farm doesn't have this problem.

dTP90pN 5y ago
Did that end up becoming a problem in all the other distros using aliased directories, for example Fedora which has 10 years of experience with this scheme? An quick look on Fedora 35 with $ grep -rP "(?!(?=(?'a'[\s\S]*))(?'b'\/usr(?=\k'a'\z)|(?<=(?=x^|(?&b))[\s\S])))\/bin\/(?!(sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat))" /usr/bin doesn't really show any objectionable binaries being referred to via /bin (I count those I excluded in the negative lookahead as certainly non-objectionable). (I used the variable-length negative lookbehind [1] because I wanted to reduce false positives, but just scrolling through the results ended up being easier) [1] http://www.drregex.com/2019/02/variable-length-lookbehinds-actually.html http://www.drregex.com/2019/02/variable-length-lookbehinds-a... Alternatively, a simple grep --binary-files=text -rP '(?<!/usr)/bin/(?!sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat)' /usr/bin to also include binary files does the job as well.
rollcat 5y ago
I wish two things happened... All OS's around the world implementing "#!python3" (or similar) as a shorthand to "#!/usr/bin/env python3", and in the meantime using #!/usr/bin/env to transition.
- __david__ 5y ago
  The reason that hasn't happened is because `#!` is a kernel level thing, but the `PATH` env is a userspace thing. I suspect even adding env parsing to the kernel would not be viewed as a favorable change…
  - rollcat 5y ago
    It could literally be a shorthand for /usr/bin/env, actually delegating the PATH handling to user space. The path to /usr/bin/env could be a boot arg or runtime variable (sysctl). It could probably be implemented in Linux (without touching kernel code) via binfmt_misc. It's mostly a matter of people agreeing to do this.
Zardoz84 5y ago
Ubuntu uses dpkg and have the merged /usr using the directory-symlink without any issues. Also, I don't see how a folder filled with symlinks would prevent the problem that are you talking.
roelschroeven 5y ago
I must be missing something, because I don't see how a link farm doesn't have the exact same problem. In the case of symlinked directories we have: - the binary lives in /usr/bin/python3 - /bin is a symlink to /usr/bin - /bin/python3 therefore refers to /usr/bin/python3 We can use either /usr/bin/python3 or /bin/python3. In the case of a link farm we have: - the binary lives in /usr/bin/python3 - /bin/python3 is a symlink to /usr/bin/python3 Again we can use either /usr/bin/python3 or /bin/python3. As far as I can see, both methods allow insufficiently careful developers to hardcode the wrong paths. What am I missing?
- caylus 5y ago
  > - /bin/python3 is a symlink to /usr/bin/python3 You don't symlink everything in /usr/bin to /bin, just "all regular files that have traditionally been in /bin" (per the article). python3 has not traditionally been in /bin, so /bin/python3 would not be linked.
  - roelschroeven 5y ago
    Ah, yes, thanks, that clears up things.

dTP90pN 5y ago

Did that end up becoming a problem in all the other distros using aliased directories, for example Fedora which has 10 years of experience with this scheme? An quick look on Fedora 35 with $ grep -rP "(?!(?=(?'a'[\s\S]*))(?'b'\/usr(?=\k'a'\z)|(?<=(?=x^|(?&b))[\s\S])))\/bin\/(?!(sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat))" /usr/bin doesn't really show any objectionable binaries being referred to via /bin (I count those I excluded in the negative lookahead as certainly non-objectionable). (I used the variable-length negative lookbehind [1] because I wanted to reduce false positives, but just scrolling through the results ended up being easier) [1] http://www.drregex.com/2019/02/variable-length-lookbehinds-actually.html http://www.drregex.com/2019/02/variable-length-lookbehinds-a... Alternatively, a simple grep --binary-files=text -rP '(?<!/usr)/bin/(?!sh|ksh|zsh|bsh|bash|dash|mount|umount|echo|true|false|ls|rm|mv|ln|cat)' /usr/bin to also include binary files does the job as well.

rollcat 5y ago

I wish two things happened... All OS's around the world implementing "#!python3" (or similar) as a shorthand to "#!/usr/bin/env python3", and in the meantime using #!/usr/bin/env to transition.

__david__ 5y ago
The reason that hasn't happened is because `#!` is a kernel level thing, but the `PATH` env is a userspace thing. I suspect even adding env parsing to the kernel would not be viewed as a favorable change…
- rollcat 5y ago
  It could literally be a shorthand for /usr/bin/env, actually delegating the PATH handling to user space. The path to /usr/bin/env could be a boot arg or runtime variable (sysctl). It could probably be implemented in Linux (without touching kernel code) via binfmt_misc. It's mostly a matter of people agreeing to do this.

Zardoz84 5y ago

Ubuntu uses dpkg and have the merged /usr using the directory-symlink without any issues. Also, I don't see how a folder filled with symlinks would prevent the problem that are you talking.

roelschroeven 5y ago

I must be missing something, because I don't see how a link farm doesn't have the exact same problem. In the case of symlinked directories we have: - the binary lives in /usr/bin/python3 - /bin is a symlink to /usr/bin - /bin/python3 therefore refers to /usr/bin/python3 We can use either /usr/bin/python3 or /bin/python3. In the case of a link farm we have: - the binary lives in /usr/bin/python3 - /bin/python3 is a symlink to /usr/bin/python3 Again we can use either /usr/bin/python3 or /bin/python3. As far as I can see, both methods allow insufficiently careful developers to hardcode the wrong paths. What am I missing?

caylus 5y ago
> - /bin/python3 is a symlink to /usr/bin/python3 You don't symlink everything in /usr/bin to /bin, just "all regular files that have traditionally been in /bin" (per the article). python3 has not traditionally been in /bin, so /bin/python3 would not be linked.
- roelschroeven 5y ago
  Ah, yes, thanks, that clears up things.