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.
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?
_______________________________________________ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
