Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd
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 '
("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
Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd
Бојан Ландекић 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 '
("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
Re: GNU bash, 3.00.15(1)-release, referenced cmd in cwd executes alternate cmd
Matthew Woehlke wrote: > Бојан Ландекић wrote: > >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. Actually as long as you include all of the libraries in the same bundle and call ldso with the path to the bundled libc then it is perfectly possible to build a complete set that will work on most distros, on the same architecture and across compatible kernel versions of course. On my system that would be libncurses.so.5, libdl.so.2, libc.so.6, ld-linux-x86-64.so.2 plus bash itself and a portable sh script wrapper to tie it all together. I do that with other tools frequently. Bob ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
