|
Home > Archive > Unix Programming > February 2006 > Shell looking in mysterious places for the svn execute file
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Shell looking in mysterious places for the svn execute file
|
|
| Roka100@gmail.com 2006-02-23, 2:54 am |
| 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?
| |
|
|
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
| |
| Roka100@gmail.com 2006-02-23, 2:54 am |
|
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
| |
| Logan Shaw 2006-02-26, 10:16 am |
| 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
| |
| Micah Cowan 2006-02-26, 10:16 am |
| 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
| |
| Chris F.A. Johnson 2006-02-26, 10:16 am |
| 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
| |
|
| 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
| |
| Micah Cowan 2006-02-26, 10:16 am |
| "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.
| |
| Chris F.A. Johnson 2006-02-26, 10:16 am |
| 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
| |
| Micah Cowan 2006-02-26, 10:16 am |
| "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.
| |
| Barry Margolin 2006-02-26, 10:16 am |
| In article <87lkw0l3ms.fsf@mcowan.barracudanetworks.com>,
Micah Cowan <micah@cowan.name> wrote:
> "Chris F.A. Johnson" <cfajohnson@gmail.com> writes:
>
>
> 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...
I've never heard of the problem of it leaving you in an interactive csh.
The real problem is that the way it works will generally only work if
you use csh interactively. For instance, if you have aliases or
functions in your shell they won't be visible to a csh script -- there's
simply no way for a csh script to detect this.
--
Barry Margolin, barmar@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
| |
| Henry Townsend 2006-02-26, 10:16 am |
| Barry Margolin wrote:
> I've never heard of the problem of it leaving you in an interactive csh.
> The real problem is that the way it works will generally only work if
> you use csh interactively. For instance, if you have aliases or
> functions in your shell they won't be visible to a csh script -- there's
> simply no way for a csh script to detect this.
Also, older versions of which were specifically written to emulate an
interactive C shell (by either not using the -f flag or explicitly
sourcing ~/.cshrc, I don't remember which) with the result that they
would show you only (as someone said above) the executable you'd find
*iff* you were running an interactive C shell. Newer versions do not
source .cshrc and, as noted, some have been rewritten as a binary but
these then lose some value to csh users because of the alias problem.
Bottom line, "where am I going to find command foo if I run it" is a
question that can be answered only by your current shell and thus the
capability, whether it be called "which" or "type" or "whence" (ksh)
must be provided by a shell builtin. And in the case of shells other
than csh, it is.
Parenthetically, this is an area with an irritating lack of convergence.
Leaving csh - which is basically as dead as Latin - aside, even the
POSIX-like shells can't agree on the name or format of the output. I
really don't understand why bash doesn't offer a "whence", which would
simply be the same as "type" without the prepended "foo is" verbosity.
It's a trivial feature, and one way to reduce the "finger gap" between
the viable modern POSIX-like shells.
| |
| Sven Mascheck 2006-02-26, 11:25 am |
| Henry Townsend wrote:
> I really don't understand why bash doesn't offer a "whence", which would
> simply be the same as "type" without the prepended "foo is" verbosity.
it does: type -p cmd
> It's a trivial feature, and one way to reduce the "finger gap" between
> the viable modern POSIX-like shells.
s/modern POSIX-like shells/modern korn-like shells/
POSIX doesn't handle type or whence and later almquist shells
come with type.
[fup2: comp.unix.shell]
|
|
|
|
|