zlacker

[return to "Understanding the bin, sbin, usr/bin, usr/sbin split (2010)"]
1. EdScho+Oa[view] [source] 2022-05-11 07:57:55
>>taubek+(OP)
I once sent out a proposal on the FreeBSD lists to merge /sbin with /bin, and /usr/sbin with /usr/bin. People were concerned that this would slow down the system, due to PATH lookups taking longer. Even when I demonstrated the opposite was true (it being faster due to fewer directories needing to be scanned), I wasn't able to get consensus. What a shame.
◧◩
2. mekste+fv[view] [source] 2022-05-11 11:24:44
>>EdScho+Oa
What ancient system makes a speed difference in command lookup in PATH?
◧◩◪
3. EdScho+tz[view] [source] 2022-05-11 11:57:27
>>mekste+fv
Calls like execvp() do little more than splitting PATH on ':', followed by repeatedly invoking execve() on ${dir}/${filename}. The fewer elements you have in PATH, the fewer execve() calls need to be performed in the worst case.
◧◩◪◨
4. mekste+nA[view] [source] 2022-05-11 12:02:55
>>EdScho+tz
Sounds like they need fixed for inefficient handling of simple operation.
◧◩◪◨⬒
5. noname+v51[view] [source] 2022-05-11 14:37:19
>>mekste+nA
It's not really an accurate description anyway. Most shells will only perform the PATH lookup one time per command, then store the found fully-qualified file path in an in-memory hash table for quicker lookup each subsequent invocation. This is why you need to blast the cache if you delete or move an executable. Plus, many common utilities are replaced by shell built-ins anyway and they never require directory traversal at all.
[go to top]