bash: which: command not found? + (E: Unable to locate package which? ...)

[Albretch Mueller]

Actually, I just noticed I couldn't run "cat" as regular user but I
could as root how could that form a "multiversing" be -technically-
happening (other than having forces actively messing with your work)?

export _GRAALVM_HOME=.../graalvm-ce-java17-22.1.0
export PATH=${PATH}:${_GRAALVM_HOME}/bin
which javac
which java
$

bash: which: command not found

# apt-get install which
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
E: Unable to locate package which
#



# cat /etc/apt/sources.list
# deb cdrom:[Official Debian GNU/Linux Live 11.2.0 lxde
2021-12-18T12:41]/ bullseye main
#deb cdrom:[Official Debian GNU/Linux Live 11.2.0 lxde
2021-12-18T12:41]/ bullseye main

deb http://security.debian.org/debian-security bullseye-security main
deb-src http://security.debian.org/debian-security bullseye-security main

# bullseye-updates, to get updates before a point release is made;
# see https://www.debian.org/doc/manuals/debian-reference/ch02.en.html#_updates_and_backports
# A network mirror was not selected during install. The following entries
# are provided as examples, but you should amend them as appropriate
# for your mirror of choice.
#
deb http://deb.debian.org/debian/ bullseye-updates main
deb-src http://deb.debian.org/debian/ bullseye-updates main

deb http://deb.debian.org/debian bullseye main contrib non-free
deb-src http://deb.debian.org/debian bullseye main contrib non-free

deb http://deb.debian.org/debian-security/ bullseye-security main
contrib non-free
deb-src http://deb.debian.org/debian-security/ bullseye-security main
contrib non-free

deb http://deb.debian.org/debian bullseye-updates main contrib non-free
deb-src http://deb.debian.org/debian bullseye-updates main contrib non-free

#This system was installed using small removable media
# (e.g. netinst, live or single CD). The matching "deb cdrom"
# entries were disabled at the end of the installation process.
# For information about how to configure apt package sources,
# see the sources.list(5) manual.

# which bash
/usr/bin/bash
#

[The Wanderer]

On 2022-07-08 at 06:02, Albretch Mueller wrote:

> Actually, I just noticed I couldn't run "cat" as regular user but I
> could as root how could that form a "multiversing" be -technically-
> happening (other than having forces actively messing with your work)?

I don't understand what this means, and I don't recognize this use of
"multiversing". (At a guess, I'd parse that verb as meaning something
like "splitting into multiple universes", which seems completely
unrelated to this context.)

I also don't see what that has to do with anything else that's in this
message.

> export _GRAALVM_HOME=.../graalvm-ce-java17-22.1.0
> export PATH=${PATH}:${_GRAALVM_HOME}/bin
> which javac
> which java
> $
>
> bash: which: command not found
>
> # apt-get install which
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: Unable to locate package which
> #

Currently, which is (still) provided by the 'debianutils' package.

There's a whole flap about that; the package maintainer doesn't think it
belongs there and doesn't want to keep maintaining it and apparently
wants to declare it deprecated in favor of the (not 100% comparable)
'command -v'. Other people dispute that, to some degree or another, and
there has been *far* more discussion of it than the whole thing would
seem to have deserved.

You can see reference to the bug reports involved in
/usr/share/doc/debianutils/changelog.Debian.gz, at least if you're
running the version that's in testing or newer.

I think the idea is that eventually there will (probably) be multiple
implementations of which provided by multiple packages, and you can
install and use whichever one you want via the Debian alternatives
system. But for the time being, the debianutils version seems to still
be the only one available, at least in testing.

--
The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw

[Thomas Schmitt]

Hi,

Albretch Mueller wrote:
> # apt-get install which

> E: Unable to locate package which

Try

apt-get install debianutils

I got the proposal from
$ apt-file search which | grep 'which$' | less
which still finds 18 lines which end by "which".
Number two looks like the program you look for:
debianutils: /usr/bin/which

Indeed my system says:
$ which which
/usr/bin/which

You may also use bash builtin command

$ type -p cat
/usr/bin/cat

> Actually, I just noticed I couldn't run "cat" as regular user but I
> could as root how could that form a "multiversing" be -technically-
> happening (other than having forces actively messing with your work)?

Maybe some user-defined alias ?
Try

alias cat

Mine says "bash: alias: cat: not found". But with "cp" instead of "cat"
it says "alias cp='cp -i'".


Have a nice day :)

Thomas

[Tixy]

On Fri, 2022-07-08 at 05:02 -0500, Albretch Mueller wrote:
>  Actually, I just noticed I couldn't run "cat" as regular user but I
> could as root how could that form a "multiversing" be -technically-
> happening (other than having forces actively messing with your work)?
>
> export _GRAALVM_HOME=.../graalvm-ce-java17-22.1.0

There's one too many '.' characters there, but that shouldn't be the
cause of your issue.

> export PATH=${PATH}:${_GRAALVM_HOME}/bin
> which javac
> which java
> $
>
> bash: which: command not found

So, did you check what $PATH contains? (e.g. echo $PATH) It seems
likely it's corrupted or missing the right directory (/usr/bin see
below).

>
> # apt-get install which
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: Unable to locate package which

Because there's no package called 'which', the which command is
provided by debianutils. Which you could have found by Googling for the
ways to find out the package. For me, the first search result was...
https://superuser.com/questions/10997/find-what-package-a-file-belongs-to-in-ubuntu-debian

[...]


# which bash
/usr/bin/bash

So, $PATH in your root environment is OK. So you could have run

#which which
/usr/bin/which

So it's in /usr/bin and you could have found the package it belongs with using:

#dpkg -S /usr/bin/which
debianutils: /usr/bin/which

--
Tixy

[to...@tuxteam.de]

On Fri, Jul 08, 2022 at 05:02:47AM -0500, Albretch Mueller wrote:
> Actually, I just noticed I couldn't run "cat" as regular user but I
> could as root how could that form a "multiversing" be -technically-
> happening (other than having forces actively messing with your work)?

Sorry. I don't understand what you are saying there. What does mean
"you couldn't run cat"? Your fingers froze while typing? Your keyboard
delivered an electric jolt to you? Help your helpers. Don't tease them
with riddles.

> export _GRAALVM_HOME=.../graalvm-ce-java17-22.1.0
> export PATH=${PATH}:${_GRAALVM_HOME}/bin
> which javac
> which java
> $
>
> bash: which: command not found
>
> # apt-get install which
> Reading package lists... Done
> Building dependency tree... Done
> Reading state information... Done
> E: Unable to locate package which
> #

[...]

Not every binary is contained in a package called like it.
That's what "apt-file" is for (in the same named package):

tomas@trotzki:~$ apt-file search bin/which
debian-goodies: /usr/bin/which-pkg-broke
debian-goodies: /usr/bin/which-pkg-broke-build
debianutils: /usr/bin/which
emboss: /usr/bin/whichdb
whichman: /usr/bin/whichman

...i provided more of the path ("bin/which") because I'd
otherwise get too many hits.

It seems you're looking for the package "debianutils".

(NB: "apt", not "apt-get" has an interface to "apt-file"
so you can just type "apt search").

Cheers
--
t

[Jude DaShiell]

If using bash, likely the type command will work.

[Greg Wooledge]

On Fri, Jul 08, 2022 at 12:47:19PM +0100, mick crane wrote:
> here on bookworm
> mick@pumpkin:~$ ls -la /usr/bin |grep which
> lrwxrwxrwx 1 root root 23 Jan 23 18:05 which ->
> /etc/alternatives/which
> -rwxr-xr-x 1 root root 946 May 1 17:47 which.debianutils
> mick@pumpkin:~$
>
> what are these "alternatives" ?

https://wiki.debian.org/DebianAlternatives

[mick crane]

On 2022-07-08 11:30, to...@tuxteam.de wrote:

> Not every binary is contained in a package called like it.
> That's what "apt-file" is for (in the same named package):
>
> tomas@trotzki:~$ apt-file search bin/which
> debian-goodies: /usr/bin/which-pkg-broke
> debian-goodies: /usr/bin/which-pkg-broke-build
> debianutils: /usr/bin/which
> emboss: /usr/bin/whichdb
> whichman: /usr/bin/whichman

here on bookworm
mick@pumpkin:~$ ls -la /usr/bin |grep which
lrwxrwxrwx 1 root root 23 Jan 23 18:05 which ->
/etc/alternatives/which
-rwxr-xr-x 1 root root 946 May 1 17:47 which.debianutils
mick@pumpkin:~$

what are these "alternatives" ?

mick

[The Wanderer]

There's also

/etc/alternatives/README

which points you to the update-alternatives(1) man page, which provides
a reasonable level of documentation of the concept.

(Though I'll admit that that README may be a bit hard to notice, among
the many other items in that directory.)

[Greg Wooledge]

On Fri, Jul 08, 2022 at 05:02:47AM -0500, Albretch Mueller wrote:

> Actually, I just noticed I couldn't run "cat" as regular user but I
> could as root

My first guess: you broke your PATH variable, and however you're becoming
root (there are many ways, so it would be nice if you told us which one
you're using) is restoring a sensible PATH for you.

> how could that form a "multiversing" be -technically-
> happening (other than having forces actively messing with your work)?

You're delusional.

If you need any additional help (beyond what has already been provided)
in fixing your "couldn't run cat" problem, please follow these basic
guidelines when asking for help:

1) Show us the problem. "I couldn't run cat" is about a 2 out of 10 on
the usefulness scale.

A much better start would be to *paste* the relevant lines (whole lines)
from your terminal session into the email. What you paste should show
us your shell prompt, the shell command that you typed, and all of the
output you received. For example:

unicorn:~$ catt /etc/group
bash: catt: command not found

2) Give us basic background about your system. What version of Debian are
you running? What, if anything, have you changed which might have an
effect on the problem you're experiencing?

Since you're having a problem running a standard shell command, things
that might fall into this category would include:

* I changed my account's shell from ___ to ___.
* I edited my ~/.bashrc (or ~/.zshrc or whatever) dot file.
* I tried to upgrade from buster to bookworm, and I got errors, but I
ignored them until now.

3) Tell us what, if anything, you've already tried. Give us all the
additional details you have.

* The problem happens in all terminals I've tried -- xterm, rxvt-unicode,
gnome-terminal and konsole.
* If I type 'zsh' the problem goes away. But I really want it to work
in bash too.
* I did a 'locate cat' and I can see that it's in /usr/bin, or at least
locate thinks it is. Here is the output of 'ls -l /usr/bin/cat'.

[Albretch Mueller]

after reading through all your suggestions and still wondering about
what exactly was the mistake that I had made, I realized that it was a
simple and stupid "type in a rush and let 'the compiler' (sorry!) find
the mistake for you" kind of error: it seemed to have been somehow
blanketed by my "unconscious" that bash utils needed to be declared in
the PATH in order for you to access them. Noticing it and opening
another windows was all it took.

$ export _GRAALVM_HOME=".../GraalVM/graalvm-ce-java17-22.1.0"
$ export PATH=${_GRAALVM_HOME}/bin:${PATH}

$ which javac
.../GraalVM/graalvm-ce-java17-22.1.0/bin/javac

$ which java
.../GraalVM/graalvm-ce-java17-22.1.0/bin/java

$ javac -version
javac 17.0.3

$ java -version
openjdk version "17.0.3" 2022-04-19
OpenJDK Runtime Environment GraalVM CE 22.1.0 (build 17.0.3+7-jvmci-22.1-b06)
OpenJDK 64-Bit Server VM GraalVM CE 22.1.0 (build
17.0.3+7-jvmci-22.1-b06, mixed mode, sharing)
$


"So far as these truths are concerned, I do not at all fear the
arguments of the Academics when they say, What if you are mistaken?
For if I am mistaken, I exist." Saint Augustine (De Civitate Dei (book
XI, 26))

it amazes me also how all we do, learn, even dream, as well as our
mistakes and how we notice them we do -functionally-

thank you to you all,
lbrtchx

[Tixy]

On Fri, 2022-07-08 at 08:37 -0500, Albretch Mueller wrote:
> it seemed to have been somehow
> blanketed by my "unconscious" that bash utils needed to be declared in
> the PATH in order for you to access them.

'which' isn't a 'bash util' whatever that is (presumably you mean a
shell built-in). As you've found out, 'which' is an external program.

To find out how the shell thinks about out a command, use the 'type'
command...

$ type which
which is /usr/bin/which

$ type type
type is a shell builtin

$ type foobar
bash: type: foobar: not found

$ type which
which is hashed (/usr/bin/which)

In the last, 'hashed' sorta means 'cached' so it doesn't have to search
the whole path again to find it. From the posix standard [1]...

an implementation may remember its location and need not search for the
utility again unless the PATH variable has been the subject of an
assignment. If the remembered location fails for a subsequent
invocation, the shell shall repeat the search to find the new location
for the utility, if any.

[1] https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/V3_chap02.html#tag_18_09_01_01

--
Tixy

[to...@tuxteam.de]

On Fri, Jul 08, 2022 at 08:37:19AM -0500, Albretch Mueller wrote:

> [...] that bash utils needed to be declared in

> the PATH in order for you to access them. Noticing it and opening
> another windows was all it took.

Ah, oh. You overwrote your PATH. Makes sense now :)

> it amazes me also how all we do, learn, even dream, as well as our
> mistakes and how we notice them we do -functionally-

Indeed.

Cheers
--
t