I just install svn 1.3. But I'm getting some odd error messages from
bash all of a sudden.  It can't seem to find the right location for a
file, even though everything else seems to work ok:

test@linuxdev$ svn
bash: /usr/bin/svn: No such file or directory

test@linuxdev$ ls /usr/bin/svn
ls: /usr/bin/svn: No such file or directory

test@linuxdev$ which svn
/usr/local/bin/svn

test@linuxdev$ ls /usr/local/bin/svn
/usr/local/bin/svn

test@linuxdev$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11

test@linuxdev$ sv[TAB] (it expands to svn)


test@linuxdev$ /usr/local/bin/svn
Type 'svn help' for usage.


So the program's there, and it works, but for some reason bash seems to
go looking for it in the wrong place.  What's up with that?  And more
importantly, how to I beat some sense into it?

[ Post a follow-up to this message ]

Roka100@gmail.com wrote:
> I just install svn 1.3. But I'm getting some odd error messages from
> bash all of a sudden.  It can't seem to find the right location for a
> file, even though everything else seems to work ok:
>
> test@linuxdev$ svn
> bash: /usr/bin/svn: No such file or directory
>
> test@linuxdev$ ls /usr/bin/svn
> ls: /usr/bin/svn: No such file or directory
>
> test@linuxdev$ which svn
> /usr/local/bin/svn
>
> test@linuxdev$ ls /usr/local/bin/svn
> /usr/local/bin/svn
>
> test@linuxdev$ echo $PATH
> /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/bin/X11
>
> test@linuxdev$ sv[TAB] (it expands to svn)
>
>
> test@linuxdev$ /usr/local/bin/svn
> Type 'svn help' for usage.
>
>
> So the program's there, and it works, but for some reason bash seems to
> go looking for it in the wrong place.  What's up with that?  And more
> importantly, how to I beat some sense into it?

Interesting. Tried doing 'hash -r'?

--Toby

[ Post a follow-up to this message ]

toby =E5=86=99=E9=81=93=EF=BC=9A

> Interesting. Tried doing 'hash -r'?
Now it works all right after 'hash -r' .

Thanks a lot

[ Post a follow-up to this message ]

Roka100@gmail.com wrote:
> I just install svn 1.3. But I'm getting some odd error messages from
> bash all of a sudden.  It can't seem to find the right location for a
> file, even though everything else seems to work ok:
>
> test@linuxdev$ svn
> bash: /usr/bin/svn: No such file or directory
>
> test@linuxdev$ ls /usr/bin/svn
> ls: /usr/bin/svn: No such file or directory

One possible explanation for this is that /usr/bin/svn is a symbolic
link to a non-existent path.

> test@linuxdev$ which svn
> /usr/local/bin/svn

What the "which" command says is totally irrelevant and can even be
misleading.  I would avoid using it.  It's a csh script.  It will
tell you more about what the path would be if you were running csh
than it will about anything else.  If you are using bash, you'll get
accurate results from "type" (as in "type svn"), because "type" is
built into bash.

- Logan

[ Post a follow-up to this message ]

Logan Shaw <lshaw-usenet@austin.rr.com> writes:

> What the "which" command says is totally irrelevant and can even be
> misleading.
> I would avoid using it.  It's a csh script.  It will
> tell you more about what the path would be if you were running csh
> than it will about anything else.

This is completely untrue.

1. On my system, which is certainly no csh script (it's a binary).

2. Which doesn't tell you anything about what the path /would/ be in
any situation. It tells you where the binary you are looking for
is using what the value of PATH currently is _right_now_. It uses
the same searching mechanism that any shell, or any exec[vl]p(),
would use.

-Micah

[ Post a follow-up to this message ]

On 2006-02-24, Micah Cowan wrote:
> Logan Shaw <lshaw-usenet@austin.rr.com> writes:
> 
>
> This is completely untrue.

No, not completely.

>   1. On my system, which is certainly no csh script (it's a binary).

On some (many?) systems, 'which' _is_ a csh script, and it does not
work in a Bourne-type shell.

>   2. Which doesn't tell you anything about what the path /would/ be in
>      any situation. It tells you where the binary you are looking for
>      is using what the value of PATH currently is _right_now_. It uses
>      the same searching mechanism that any shell, or any exec[vl]p(),
>      would use.

That depends on which version.

--
Chris F.A. Johnson, author   |    <http://cfaj.freeshell.org>
Shell Scripting Recipes:     |  My code in this post, if any,
A Problem-Solution Approach  |          is released under the
2005, Apress                 |     GNU General Public Licence

[ Post a follow-up to this message ]

Logan Shaw wrote:
> Roka100@gmail.com wrote: 
>
> One possible explanation for this is that /usr/bin/svn is a symbolic
> link to a non-existent path.
> 
>
> What the "which" command says is totally irrelevant and can even be
> misleading.

In this case it is 100% correct.

The problem lay not with 'which', but in shell's stale 'hash' of
command locations, which pre-empted the true location. 'which' surely
gave the most relevant answer, in terms of troubleshooting. Perhaps
this same effect has led you to wrongly conclude that 'which' is
unreliable. If you still don't trust it, any issue would be evident
from its source code.

> I would avoid using it.  It's a csh script.  It will
> tell you more about what the path would be if you were running csh
> than it will about anything else.  If you are using bash, you'll get
> accurate results from "type" (as in "type svn"), because "type" is
> built into bash.

As Micah points out, this isn't true.

$ file `which which`
/usr/bin/which: ELF 32-bit LSB shared object, Intel 80386, version
1 (SYSV), stripped

In fact, 'type' will only show the shell's hashed path* (even if not
valid, as the OP observed), while 'which' (being outside the shell)
cannot be confused in this way, and as in the case above, will show the
actual path:

$ svn
-bash: /usr/bin/svn: No such file or directory
$ which svn
/usr/local/bin/svn
$ type svn
svn is hashed (/usr/bin/svn)
$ hash -r
$ type svn
svn is /usr/local/bin/svn
$ svn
Type 'svn help' for usage.

[*] see 'info bash'

>
>    - Logan

[ Post a follow-up to this message ]

"Chris F.A. Johnson" <cfajohnson@gmail.com> writes:

> On 2006-02-24, Micah Cowan wrote: 
>
>    No, not completely.
> 
>
>    On some (many?) systems, 'which' _is_ a csh script, and it does not
>    work in a Bourne-type shell.

The fact that it may be implemented as a csh script, does not mean it
can't be invoked and relied upon by a Bourne shell.

> 
>
>    That depends on which version.

Please explain. How is which going to fail, regardless of version? It
will search each element of PATH until it finds what it's looking for,
yes?

I do agree, however, that "type" is a bit more useful. Especially
since, in this particular case, it would have informed the user that
its location was hashed, which no which (other than a builtin, which I
haven't encountered) can determine.

[ Post a follow-up to this message ]

On 2006-02-24, Micah Cowan wrote:
> "Chris F.A. Johnson" <cfajohnson@gmail.com> writes:
> 
>
> The fact that it may be implemented as a csh script, does not mean it
> can't be invoked and relied upon by a Bourne shell.

Have you ever tried it? I have, and the versions I have used on
various systems don't work in a Bourne-type shell. I don't know why
(csh is not good for scripting, so I haven't bothered with it), but
it is a fact. Somehow, you remain in csh with an interactive
prompt.
 
>
> Please explain. How is which going to fail, regardless of version? It
> will search each element of PATH until it finds what it's looking for,
> yes?
>
> I do agree, however, that "type" is a bit more useful. Especially
> since, in this particular case, it would have informed the user that
> its location was hashed, which no which (other than a builtin, which I
> haven't encountered) can determine.


--
Chris F.A. Johnson, author   |    <http://cfaj.freeshell.org>
Shell Scripting Recipes:     |  My code in this post, if any,
A Problem-Solution Approach  |          is released under the
2005, Apress                 |     GNU General Public Licence

[ Post a follow-up to this message ]

"Chris F.A. Johnson" <cfajohnson@gmail.com> writes:

> On 2006-02-24, Micah Cowan wrote: 
>
>    Have you ever tried it? I have, and the versions I have used on
>    various systems don't work in a Bourne-type shell. I don't know why
>    (csh is not good for scripting, so I haven't bothered with it), but
>    it is a fact. Somehow, you remain in csh with an interactive
>    prompt.

That strikes me as /extremely/ broken, even if your shell is csh,
since it implies that it opens up a new shell, and leaves you
there.

Still, that in itself doesn't imply that it doesn't work, only that it
fails to exit the shell. But it sounds like a bug in either your which
or your csh...

However, if this is the only way it was broken, then it's not really
related to the original discussion: "which" was clearly displaying a
result, and exiting back to the invoking shell, so a claim that it
doesn't work from Bourne-style shells seems a little silly in that
context.

BTW, if you happen to have the CSH handy for which you've been
referring to, I'd enjoy seeing it (e-mail's probably better): my
curiosity is now quite piqued. Also, I'm curious as to which operating
systems (exhaustive list unnecessary) ship with this script. I checked
on a few systems I have handy, but GNU and OpenBSD use compiled
executables, and the one on my FreeBSD system is in Perl.

[ Post a follow-up to this message ]