Бојан Ландекић wrote:
On 27-Feb-07, at 2:26 PM, Matthew Woehlke wrote:
IIRC we were talking about why e.g. 'ls' would not run 'which ls',
right? In that case "correct" could be said to mean that 'which <foo>'
("which" is assumed to execute in a new environment, that is it is not
implemented as a shell alias or shell function) and 'type foo' agree.
This does not happen if (as I just experienced) you start bash, run
the command, then install a new version of that command in a
different, but also-in-PATH location.
That is sort of what I reported as a bug when i started this email
thread. Do you consider this a bug, incorrect behavior, a feature
result or something else? It's not expected behavior from my miniscule
bash experience.
It (bash's hashing) is a "feature" :-). I forget if you can turn it off
or not, though.
No, but I maintain a small login script and a much larger toolchain of
(mostly-) GNU software that achieves approximately the same effect.
:-) But it doesn't really help with "true portability", since you then
depend on that particular toolchain being present. It's great for
personal use and build systems, though, where you can enforce its
availability.
Is bash truly portable (self-contained)? Is it possible to put bash on
some portable media and use it on a system that is bash-less without
worrying about dependencies?
Not unless you build it statically, it isn't. :-) Although I think if
you build bash it gives you all the libraries you need except for libc
(or your OS's equivalent). IOW if you have an entire bash install on
your 'portable media', you should be able to run that bash on any system
the same as, or newer than, your build system.
--
Matthew
"There's nothing in the universe so permanent as a temporary government
agency." -- Phil Geusz
_______________________________________________
Bug-bash mailing list
Bug-bash@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-bash
