Hello, I have encountered an issue with chroot (from Coreutils version 9.0), but I think this email might fall more under the category of "comment" or maybe "question" rather than "bug report", since it's not clear that the observed behavior is unintentional.
I have noticed that chroot will incorrectly report that a command could not be found, when in fact it is a shared library which the command needs that could not be found, while the command itself is actually present. Example: say you have the bare minimum dependencies to run 'bash' in some isolated directory: $ cd ~/my_isolated_env $ ldd usr/bin/bash ... libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 $ sudo chroot . /usr/bin/bash -c "echo hello" # successful execution hello $ rm ./lib/x86_64-linux-gnu/libc.so.6 # delete shared library that bash needs $ sudo chroot . /usr/bin/bash -c "echo hello" # unsuccessful execution chroot: failed to run command '/usr/bin/bash': No such file or directory Looking at the source code in chroot.c, it doesn't seem impossible to add some logic that makes this error message more accurate (i.e. that a shared library is missing, not the executable itself). Unless this behaviour is well known and intentional (which wouldn't surprise me). In which case, my question would be: why is that? Is this error message not to be considered misleading? Is there some practical reason for not being more specific in this error message?
