12 ms·
This is a fun read. Curious how this works for large systems: > This shell instance is special because it only contains sufficient information just to make GNU
by koolba 7y ago
This is a fun read. Curious how this works for large systems:
> This shell instance is special because it only contains sufficient information just to make GNU Hello, available. We can even inspect the value of $PATH, here:
> (list of 20 or so paths to binaries)
Do binary path lookups slow to a crawl when you’ve got 100s or 1000s of separate directory paths to look through? IIUC, there’s a separate directory added to PATH for each binary right? Which presumably would be a disk I/O to read the file list for PATH matching for each command.
- xyzzy_plugh 7y agoGood question, you can of course test this yourself with `time`. In the case of Bash, non-built-in commands are stored in a lookup table, exposed via the hash built-in (`help hash`). So, there should only be a one-time performance hit per shell instance. Generally speaking, stat'ing hundreds of directories is surprisingly quick, most binaries do it all the time, when loading libraries for example. You can `strace` to see the numerous file tree crawls.
- singron 7y agoIt usually doesnt get that bad because transitive dependencies don't get added to the path. I.e. you actually need to have a list of 1000 direct dependencies to get 1000 path entries. If for some reason you have a crazy amount of paths like that and path lookups were a problem, you could use buildEnv to create a single bin directory that had symlinks to all the binaries in it.