Where are BASH commands stored? Not scripts but what bash exe uses.

theKbStockpiler · 02-21-2011, 09:09 PM

I'm reading an article here http://linux.about.com/od/itl_guide/a/gdeitl29t00.htm (insert link not working) that lists a path for the ls command. So my questions are;

Where are the other BASH commands/exe stored? If the commands are part of the exe of BASH than ls would not be in a path, correct?

Thanks in advance!

corp769 · 02-21-2011, 09:20 PM

What do you mean by exe?

And as far as locating the path to a command/program, you can use the whereis command.

theKbStockpiler · 02-21-2011, 10:03 PM

Quote:

[kbs@localhost ~]$ whereis ls
ls: /bin/ls /usr/share/man/man1/ls.1.gz /usr/share/man/man1p/ls.1p.gz
[kbs@localhost ~]$

ls also has a executable file in bin. Part of my thinking is that these BASH commands are actually bash scripts that bash runs its self for the use of what looks like a single command. So ls for instance runs a script that has more commands in it than just ls. The bin directory has only 109 items in it and there is about 670 bash commands so what is going on there? The files in /usr/share/man/man1/ls.1.g are all tarballs which makes sense sort of for the initial installation but really don't expect them in system files.I would think that they would be unpacked. Digging through the tarballs will keep me out of trouble. Does anyone know how or why bash has exe versions of a command? Why does bash have to search for it's own commands?

Thanks for your help!

paulsm4 · 02-21-2011, 10:12 PM

Quote:

ls also has a executable file in bin

Yup. "ls" is a standard *nix executable. So is "sh", "cat", "rm" and many, many others.

Quote:

Part of my thinking is that these BASH commands are actually bash scripts that bash runs its self

Nope. Bash is a "shell". A major function of a "shell" is to run "commands".

The "commands" themselves may be executable programs, or other scripts. They can come with the system; they can be executables that you create yourself. "Scripts", in turn, can be "shell scripts" that are executed by the "bash interpreter". Or "perl scripts" interpreted by the "Perl" interpreter. And so on.

There's a whole ecosystem of "stuff" out there that you can "run".

PS:
Where did you come up with the number "670"?

PPS:
Many "commands" are actually built-in to bash. For example, "echo", "read" and "test".

Here's a complete list:
http://www.gnu.org/software/bash/man...#Bash-Builtins

PPS:
Congrats on the magazine subscription

It really does look like a good publication - I hope you enjoy it!

ntubski · 02-21-2011, 10:28 PM

Quote:

Originally Posted by theKbStockpiler

I'm reading an article here http://linux.about.com/od/itl_guide/a/gdeitl29t00.htm (insert link not working) that lists a path for the ls command. So my questions are;

Where are the other BASH commands/exe stored?

Like the article says, if you echo $PATH it will show you which directories are searched for commands.

Quote:

The files in /usr/share/man/man1/ls.1.g[z] are all tarballs which makes sense sort of for the initial installation but really don't expect them in system files.

No, a tarball would be .tar.gz or .tgz, those are single files compressed with gzip.

gnashley · 02-22-2011, 02:06 AM

Bash has some internals -like ls and cd, which are also found as separate executables.
whereis is a terrible way to locate things. Better to use 'which', which will tell you the first location where something is found in your PATH.
But, bash will always use any internal first, before usinf some program from the PATH. A good example is '['. This command is a sort of alias to the 'test' command. Now, you probably have this program at /usr/bin/[, but when you use braces in a command or script this program is not the one used. The one used is the internal one. Now, to find out about the internal commands, instead of using which, use 'type' and it will tell you if the command is an internal one.
To see what I mean, do this:
'which ['
should show /usr/bin/[
Now run this:
'type ['
which should return this:
[ is a shell builtin
As you can see, the internal one gets recognized (and used unless you specifically write /usr/bin/[

Other examples are 'test', 'echo' and 'cd'. Using type first is a good idea to be able to have a more accurate idea of which program is really being used.

theKbStockpiler · 02-22-2011, 02:27 AM

The 670 comes form ORielly.http://www.oreillynet.com/linux/cmd/ Maybe I took it out of context but I doubt it matters with the info they give out. Their link always comes up first on a search like that.Are they wrong about that too? Built ins is the search term for this topic so I will research this before I post again. This link is informative with the type command.http://unix.stackexchange.com/questi...ilt-in-command. Built in commands are in the bin directory stored as a executables. I would have assumed that this would be the opposite.

Thanks for all the help!

TobiSGD · 02-22-2011, 03:17 AM

I think you are confusing Linux commands (named so in the list you have given) with Bash commands. Most commands given in that list are in no way Bash-commands, they are the Gnu utilities and will work from every shell, not just Bash.

gnashley · 02-22-2011, 08:22 AM

That's what I wanted to emphasize -if you use 'type' instead of 'which', it will tell you if the command is a builtin, something in the PATH, or a function.

colucix · 02-22-2011, 08:45 AM

Quote:

Originally Posted by gnashley

Bash has some internals -like ls and cd

For the sake of clarity, ls is not a shell built-in.

Quote:

Originally Posted by gnashley

That's what I wanted to emphasize -if you use 'type' instead of 'which', it will tell you if the command is a builtin, something in the PATH, or a function.

Furthermore, type -a will list all the alternatives, the first one being that one actually used by default. E.g.

Code:

type -a echo
echo is a shell builtin
echo is /bin/echo

theKbStockpiler · 02-23-2011, 01:48 PM

Internal commands are run in the same (Process) as the bash shell and External commands are not. Some commands are both Internal and External. I assumed it had something to do with where the command was stored as in the BASH binary or not. This was silly on my part I guess because Linux is modular in nature. It appears that all BASH commands are stored outside of the binary but if anyone wants to add to the (process) end of it it would be beneficial. The reasoning is apparent but not all that clear. http://unix.stackexchange.com/questi...ilt-in-command http://stackoverflow.com/questions/5...mmands-in-java

Edit: I just read the post on Linux commands so I will look into that. Thanks to TobiSDG for pointing that out.

theNbomr · 02-23-2011, 03:06 PM

Quote:

Some commands are both Internal and External. I assumed it had something to do with where the command was stored as in the BASH binary or not.

I don't think bash goes to the filesystem to load internal commands. Otherwise, what would be the point? Moreover, how would that actually work or be distinct from an external command?

Some commands can only work as built-ins. For instance, 'cd', which if run as a separate process would never affect the present shell, since the concept of 'present working directory' is process-specific. Changing the pwd of a child process cannot ever affect the parent process, ergo, the cd command can only ever be a built-in. Other such cases would be any command that is used to modify the environment, such as set, unset or env.

Thanks to colucix for pointing out 'type -a'

--- rod.