I may be a little crazy, but I'm upset that we still have to dink with $PATH.
Doesn't it make sense to have a little database, even if it's just a flat file that contains the name of an executable, the available places it can be found, and the default?
This would save so much time. Think about it. Whenever you install a program, you automatically call `linpath link /usr/opt/program/bin/executable`
Then the "linpath" binary links the executable to the PATH. Or if you pass a directory, then it would add all entries in the directory to the database.
I'm not an expert at C and have never compiled linux. But this has got to be the easiest thing in the world to make for somebody who's smart. I just can't understand, how in the world has this not been done. I just think it's crazy we are still recursing through directories to find binaries. It's just so annoying every time I install anything, even if through homebrew, trying to get stuff on the PATH, cause I never know where it is!
I think we should do this for LD_LIBRARY_PATH and other cool stuff like this too.
So if I want to make this, here was my idea. I will make a flat file like this:
binary_name, path1:path2:path3
Then in order to add something to it, the program will call
``` linpath add /path/to/executable or /path/to/dir ```
then linpath will do 2 things. First, it will read the config file and add any to the path (at the end by default). if you do it in interactive mode, it may prompt you if there are conflicts to see what is default. The first one in the list would be the default one.
To make this simple, linpath will symlink the default ones to /usr/bin/linpath/ or something like that, and when linpath runs, it symlinks or hard links or whatever to that dir.
This might cause a little problem since the binaries may need to talk to their neighbors, so instead of symlinking to /usr/bin/linpath, it does `cd /path/to/executable/dir` and then runs it.
This is a incomplete solution, but this, in my opinion, would make life much better for all. What are your thoughts?
Please be kind, I'm a noob at C++ sometimes, and just don't understand linux that great, cause I haven't really worked on the source code. I've done a lot of frontend stuff, but never had a chance to dive into C++ for some reason. So if you are an expert, take it from a n00b that this stuff is complicated for us and we would like to help, I just don't know where to start. SO if you have ideas, please tell me, and I might be able to build it. Then we would have to integrate it into homebrew if it worked or something.
Then you can create symlinks in ~/bin to whatever executables you want using whatever names you prefer.
If you have programs that need to run from a given location, you could create little launcher scripts that cd to the location and run the executable.
The PATH environment variable has worked the way it does since the 1970s and everything expects it to work that way. Since it is all text, it should not be too difficult to find or build tools to manage it or other environment variables.
>binary_name, path1:path2:path3
Holy path, Batman!
Now you have to manage for each and every possible executable ALL the places it might exist?
Let's say you have 100 executables in /bin
You now need (just to reference those 100 commands) a 100-line 'flat file' that looks like:
#######
ls, /bin ln, /bin mkdir, /bin
#######
OR you could just do what has been done for 50+ years, and use $PATH which looks like this:
`export PATH = /bin:/usr/bin...`
One easy-to-update line ... or HUNDREDS of hard-to-update lines?
I've dealt with systems where you need to update a file with a list of executables and their location. Having the shell handle that automatically is better.
Except ... we are not
$PATH does not "recurse" - it gives a set of prefixes the system will attempt before a command before failing (unless, of course, you just give the whole path, like `./my-cmd` or `/path/to/my-cmd`)
Oh hell no. Think about what happens if you run "ls".