[-- Attachment #1: Type: text/plain, Size: 773 bytes --] New issue by beginner3456789 on void-packages repository https://github.com/void-linux/void-packages/issues/18777 Description: ### System Void 5.4.16_1 x86_64 GenuineIntel notuptodate rrFFFF ### Package base-files-0.140_12 Void Linux base system files ### Expected behavior PATH=/usr/bin ### Actual behavior PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin ### Steps to reproduce the behavior The /etc/profile seems to add the extra PATH directories. So if a file is not found in /usr/bin the shell also looks in /bin and /sbin and /usr/bin etc. That must be much slower. The /etc/profile is probably from a different Linux. I have PATH=/usr/bin for root and PATH=/usr/local/bin:/usr/bin for user except that is debatable. Thanks.
[-- Attachment #1: Type: text/plain, Size: 2883 bytes --] New comment by loreb on void-packages repository https://github.com/void-linux/void-packages/issues/18777#issuecomment-585884449 Comment: TLDR: imho the speedup is not worth the confusion, but worth adding a comment ("not having these in $PATH would confuse most people" or "these are not needed in void") either way just in case. A script that runs a command many times - successfully: ``` #! /bin/sh for i in 1 2 3 4 5 6 7 8 9 0 a b c d e f g h i j k l m n o p q r s t u v w x y z ; do cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null cat /dev/null; cat /dev/null; cat /dev/null; cat /dev/null done ``` To test non existing commands: ``` #! /bin/sh foo&&exit 123 # must NOT be in $PATH for i in 1 2 3 4 5 6 7 8 9 0 a b c d e f g h i j k l m n o p q r s t u v w x y z ; do foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo; foo done ``` On my computer the first is just as fast even if we replace the first few entries of path with something bogus - PATH=/usr/local/nibs:/usr/local/nib/...:/usr/bin The second script is indeed almost 3x slower when run with the full path instead of PATH=/usr/bin, but we are talking 0.05s vs 0.13s when we call a nonexisting command 3000 times. All of that on a cheap laptop from 2015 without an SSD btw - does anyone have different numbers?
[-- Attachment #1: Type: text/plain, Size: 743 bytes --] New comment by beginner3456789 on void-packages repository https://github.com/void-linux/void-packages/issues/18777#issuecomment-586059548 Comment: Thanks for the reply. I tried the following test on my old Intel Ironlake with 500Gb hard disk and there was very little difference so I am very surprised. Feel free to dispose of this issue as desired. ``` # echo $PATH /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin # ./test1000.sh real 0m1.035s user 0m0.390s sys 0m0.688s # PATH=/usr/bin # echo $PATH /usr/bin # ./test1000.sh real 0m0.999s user 0m0.400s sys 0m0.640s # cat ./test1000.sh #!/bin/bash time (i=0; while [[ i -lt 1000 ]]; do foo${i} 2>/dev/null; (( i++ )); done) # exit ```
[-- Attachment #1: Type: text/plain, Size: 899 bytes --] New comment by beginner3456789 on void-packages repository https://github.com/void-linux/void-packages/issues/18777#issuecomment-586625090 Comment: Just to be curious, I have new results using mksh instead of bash and there is a big difference. This is for 100,000 iterations on my laptop with SSD instead of the previous hard disk test: beginning test with PATH= /usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin 0m01.92s real 0m00.94s user 0m00.96s system beginning test with PATH= /usr/bin 0m01.07s real 0m00.72s user 0m00.34s system ``` #!/bin/ksh notfound() { echo echo "beginning test with PATH= $PATH" while [[ i -lt 100000 ]] do "foo${i}" 2>/dev/null (( i++ )) done } # first test PATH=/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin time (notfound) # second test PATH=/usr/bin time (notfound) ```
[-- Attachment #1: Type: text/plain, Size: 283 bytes --] New comment by loreb on void-packages repository https://github.com/void-linux/void-packages/issues/18777#issuecomment-591065710 Comment: @xtraeme I didn't notice at first, but /etc/profile does say it's for non-void chroots, so it was probably fixed before this bug was opened :D
[-- Attachment #1: Type: text/plain, Size: 267 bytes --] New comment by loreb on void-packages repository https://github.com/void-linux/void-packages/issues/18777#issuecomment-591066259 Comment: @beginner3456789 only you or people with write permission to this repo can close the issue, sorry I forgot to tell you sooner.
[-- Attachment #1: Type: text/plain, Size: 898 bytes --] New comment by beginner3456789 on void-packages repository https://github.com/void-linux/void-packages/issues/18777#issuecomment-591113548 Comment: The most recent /etc/profile from base-files 0.140_12 has the PATH appended for everybody just in case somebody wants to create a non-Void chroot. Maybe those creating the chroot could set their own PATH as needed instead of imposing a very wide search for everybody else. Maybe the current PATH settings are just useful during installation for new users? The final result seems to be very minimal when running bash or dash scripts. Maybe those shells keep a list in memory instead of looking in the file system every time? I set my own PATH for root and user so the default /etc/profile is sort of cosmetic apparently. @loreb Thanks for the added info. I should close this issue in about a day or so in case anybody else wants to comment.
[-- Attachment #1: Type: text/plain, Size: 776 bytes --] Closed issue by beginner3456789 on void-packages repository https://github.com/void-linux/void-packages/issues/18777 Description: ### System Void 5.4.16_1 x86_64 GenuineIntel notuptodate rrFFFF ### Package base-files-0.140_12 Void Linux base system files ### Expected behavior PATH=/usr/bin ### Actual behavior PATH=/usr/local/bin:/usr/local/sbin:/usr/bin:/usr/sbin:/bin:/sbin ### Steps to reproduce the behavior The /etc/profile seems to add the extra PATH directories. So if a file is not found in /usr/bin the shell also looks in /bin and /sbin and /usr/bin etc. That must be much slower. The /etc/profile is probably from a different Linux. I have PATH=/usr/bin for root and PATH=/usr/local/bin:/usr/bin for user except that is debatable. Thanks.
[-- Attachment #1: Type: text/plain, Size: 599 bytes --] New comment by eli-schwartz on void-packages repository https://github.com/void-linux/void-packages/issues/18777#issuecomment-591751929 Comment: Having non-existing directories in the PATH isn't such a problem, but having the same directory symlinked multiple times into the PATH can definitely be a problem. Some programs will try to find resources based on the pathname they were invoked as, IIRC cmake is a common offender and if it expects to be in /usr/bin but gets called as /bin/cmake then you'll constantly get configure errors that e.g. the literal directory `/include` doesn't exist.