Bob Proulx wrote:
Matthew Woehlke wrote:
Apparently selectively shadowing libc is non-trivial... any
suggestions/hints?
Not so much non-trivial as perhaps non-obvious. The dynamic loader is
part of libc and so by the time the program tries to use
LD_LIBRARY_PATH it is already too late because
Matthew Woehlke wrote:
> Apparently selectively shadowing libc is non-trivial... any
> suggestions/hints?
Not so much non-trivial as perhaps non-obvious. The dynamic loader is
part of libc and so by the time the program tries to use
LD_LIBRARY_PATH it is already too late because it has already l
Bob Proulx wrote:
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 gi
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 libr
Бојан Ландекић 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 sh
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 fu
Eric beat me to this. :-) Odd that 'reply all' didn't work for you...
ah, but now I understand why (see below). Anyway, last time I
intentionally did not redirect to the list. I make it policy to
indicate that you should do that, otherwise I am publicly re-posting a
private correspondence witho
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Bojan Land on 1/5/2007 10:00 PM:
> The first response I received from you did not have a To: line nor did
> it have any reference to bug-bash@gnu.org in the headers, though it had
> a newsgroup link to gmane.comp.shells.bash.bugs so I thou
On Fri, 2007-01-05 at 11:05 -0800, Matthew Woehlke wrote:
> (Next time, reply to the list, please! Which means send any replies to
> this message to bug-bash...)
I clicked on reply to all, seems you didn't include the list in your
response previously nor this time! I've included the list now but
On Thu, 2007-01-04 at 11:31 -0700, Bob Proulx wrote:
> Bojan Land wrote:
> > Bob Proulx wrote:
> > > This is possible when it has been cached by bash and then the
> > > executable is either moved from its original location or a new
> > > executable appears earlier in PATH.
> >
> > I did not move t
Bojan Land wrote:
If I just use 'type mycmd' the result is similar in that it simply
prepends the query before the result with " is " inbetween; -p prevents
this additional processing and output?
No. According to 'help type', "If the -p flag is used, `type' either
returns the name of the disk
Bojan Land wrote:
> Bob Proulx wrote:
> > This is possible when it has been cached by bash and then the
> > executable is either moved from its original location or a new
> > executable appears earlier in PATH.
>
> I did not move the executable.
Right. "or a new executable appears earlier in PAT
On Wed, 2007-01-03 at 22:55 -0700, Bob Proulx wrote:
> > I have learned a lot from your reply, and yes some of what you wrote
> > explains this as not being a bug; after a reboot I cannot reproduce
> > these results.
>
> You should not need to reboot to clear a single shell process hash
> cache.
Bob Proulx wrote:
Matthew Woehlke wrote:
$ which --version
GNU which v2.16, Copyright (C) 1999 - 2003 Carlo Wood.
Wonderful. Yet another 'which' implementation!
But a consistent (when available) one. :-) I like GNU programs because
they are usually portable; for example I have built GNU 'w
Matthew Woehlke wrote:
> Bob Proulx wrote:
> > Traditional Unix machines used a csh script /usr/bin/which to search a
> > defined set of system paths. Newer ksh used 'whence'. Bash uses 'type'.
> > XSI extensions to POSIX require 'command -v'. Debian implemented
> > 'which' as a bash shell scrip
Bob Proulx wrote:
Bojan Land wrote:
Do you know which shells do not have type and thus rely on which?
I wouldn't guess that *any* shell "relies" on 'which'... probably all
shells have built-in $PATH lookup, but may not expose it to the user in
the way bash's 'type' does.
As far as I know
Bojan Land wrote:
Under what circumstances does the gnu-bash path hash differ from that of
the $PATH variable? Why is it even possible for this difference to
occur?
Because bash uses a hash to speed look-up of frequently used commands.
The only way to (almost) always get the right command eve
> I have learned a lot from your reply, and yes some of what you wrote
> explains this as not being a bug; after a reboot I cannot reproduce
> these results.
You should not need to reboot to clear a single shell process hash
cache. Simply starting a fresh shell, such as opening a new window,
woul
I have learned a lot from your reply, and yes some of what you wrote
explains this as not being a bug; after a reboot I cannot reproduce
these results.
On Tue, 2007-01-02 at 10:50 -0700, Bob Proulx wrote:
> Did you previously reference the file and have that path cached?
mycmd was created using
Bojan Land wrote:
> Is what I am describing a bug, or lack of understanding?
I am not sure. I read through your posting very carefully but was not
quite sure what you were asking. Could we on the mailing list have
more information?
> There are three examples here. If executable file is in cwd
20 matches
Mail list logo
