where is the executable file supposed to be located?

[Skaperen]

Ubuntu has merged /bin with /usr/bin and /sbin with /usr/sbin. what i would like to know is, for some given command name, which directory its executable file would be in, had the merge not taken place. when i make a script that has commands that need be written as full path, i want to know which path to be used. what i used to do was check which it was in, such as by doing:

ls {/usr,}/bin/foo

now it lists the file in both locations. either will work fine on this version (and flavor) of Ubuntu, but what if the script is run somewhere else, such as an older Ubuntu, some other distro, or BSD? how can i get the correct path if my Xubuntu system has these paths merged?

[philhughes]

You can use "which" or "command -v". See the following for a discussion:

https://www.shellcheck.net/wiki/SC2230

[The Cog]

In terms of knowing where a file should go, you need to query the package database. e.g.:

dpkg-query -S /bin/foo && FOO=/bin/foo
dpkg-query -S /usr/bin/foo && FOO=/usr/bin/foo
$FOO

If you just want to reliably run it in your scripts, maybe:

$(ls {/usr,}/bin/foo | head -1)

If you just want to re-use the found location:

FOO=$(ls {/usr,}/bin/foo | head -1)
$FOO

[grahammechanical]

In Files>Other Locations>Ubuntu there is a bin folder that is just a link to usr/bin. The icon has an arrow pointing away from the top right corner. Other folders are likewise links to the actual location of the folder.

In my install of 24.04.1 there are these folders bin.usr-is-merged; lib.usr-is-merged & sbin.usr-is-merged. The three folders are empty.

Regards

[Skaperen]

You can use "which" or "command -v". See the following for a discussion:

https://www.shellcheck.net/wiki/SC2230

neither works. "which" just searches PATH and could find a like named command in an earlier directory. if i have PATH='/usr/bin:/bin' then "which" will report "/usr/bin/..." in all cases where everything is in both.

"command -v" produces the same thing. it tells me "/usr/bin/mkdir" because "/usr/bin" is ahead of "/bin" in my PATH variable. its documentation (around line 3000 of "man bash") is rather vague and ambiguous. but it is definitely giving me incorrect results in test cases.

my question is more about what is the traditional or intended location of certain commands. critical sysadmin commands are in "/bin" so that repairs can be made to bring the whole system up. examples include "ls" and "mkdir".

my fallback plan is to install an older system in a VM and record what it has in "/bin". then make a script that mimics "which" and looks in that list and if it's'n there and exists in "/bin" (regardless where else it exists) then result it as being in "/bin". i have a script, now, named "wh" that outputs all locations of a command (i have many directories with some override scripts).

[Skaperen]

In terms of knowing where a file should go, you need to query the package database. e.g.:

dpkg-query -S /bin/foo && FOO=/bin/foo
dpkg-query -S /usr/bin/foo && FOO=/usr/bin/foo
$FOO

If you just want to reliably run it in your scripts, maybe:

$(ls {/usr,}/bin/foo | head -1)

If you just want to re-use the found location:

FOO=$(ls {/usr,}/bin/foo | head -1)
$FOO

that seems to be getting correct answers. i'd like to know where it knows this.

[Skaperen]

In Files>Other Locations>Ubuntu there is a bin folder that is just a link to usr/bin. The icon has an arrow pointing away from the top right corner. Other folders are likewise links to the actual location of the folder.

In my install of 24.04.1 there are these folders bin.usr-is-merged; lib.usr-is-merged & sbin.usr-is-merged. The three folders are empty.

Regards

i don' have "Files" so i cannot see "Files>Other Locations >Ubuntu". that could be because i am still on 20.04.

[The Cog]

that seems to be getting correct answers. i'd like to know where it knows this.

dpkg-query -S /bin/foo asks dpkg what package provides /bin/foo. It either succeeds and prints the package name (in which case the following && FOO=/bin/foo runs) or it fails because it "should be" somewhere else, and FOO is not set.

ls {/usr,}/bin/foo | head -1 tries to list foo in both locations. It might list more than one if dirs are symlinked. head -1 takes only the first item listed. This approach will use the first location listed whether or not it's just a symlink.

In both cases, putting the command inside $(...) runs the command and then uses its captured output as a command-line input.

[davetheoldcoder]

i don' have "Files" so i cannot see "Files>Other Locations >Ubuntu". that could be because i am still on 20.04.

"Files" is the "friendly name" for Nautilus, the default file manager in 24.04. It may have a different "friendly name" in 20.04. And "Other Locations" might also be different in 20.04, but should be there in some form.

[Skaperen]

dpkg-query -S /bin/foo asks dpkg what package provides /bin/foo. It wither succeeds and prints the package name (in which case the following && FOO=/bin/foo runs) or it fails because it "should be" somewhere else, and FOO is not set.

ls {/usr,}/bin/foo | head -1 tries to list foo in both locations. It might list more than one if dirs are symlinked. head -1 takes only the first item listed. This approach will use the first location listed whether or not it's just a symlink.

In both cases, putting the command inside $(...) runs the command and then uses its captured output as a command-line input.

i ran it outside of $(...) and just looked at what it output. it sounds like this should work, but the output was the command without the path.

i'm not trying to make a script to answer this. i'm just wanting to know this about a new command i'm putting in a script that might be run without a PATH environment set right. i had a command name in mind when started the thread but i knew i would just have to ask again for the next, so i decide to ask how to find out. i vaguely recall some web site that had such a list but in my old age i am bad at remembering URLs and other like details. i've learned to keep notes, now. but i didn't have one for this.