Chet Ramey wrote:
You probably have the `checkhash' shell option set.
---
Yup...didn't know about that
Posix requires
that the command hash table be transparent, in the sense that it can
only be used if the hashed command corresponds to a valid pathname.
It's designed to address the is
Thomas Schwinge wrote:
> Hello!
>
> There seems to be a problem with bash's usage of named pipes on GNU/Hurd
> systems.
Bash uses named pipes for process substitution only if /dev/fd (or the
Linux variant, /proc/self/fd) is not available. I'd check config.h to
see which is being used (look for H
Linda Walsh wrote:
>So what's the deal? Aren't hits supposed to be incremented?
> If a hash entry is setup, shouldn't that 1) take precedence over and
> 2) allow the command to be found, even in the absence of a PATH?
>
>This behavior was in my locally built bash:
> version 3.1.11(2)-rel
Hello!
There seems to be a problem with bash's usage of named pipes on GNU/Hurd
systems.
#v+
[EMAIL PROTECTED]:~ $ diff -u <(echo a) <(echo b)
--- /proc/self/fd/632006-11-19 15:32:53.622504951 +0100
+++ /proc/self/fd/622006-11-19 15:32:53.614508451 +0100
@@ -1 +1 @@
-a
+b
[EMAIL PROTECTED
I'm having a problem in understanding the "hash" command in bash:
Starting from a clean hash list, I issue a regular command and it is
then placed in the hash list (NOTE, option "hashall
/> set -o|grep hash# check relevant setting
hashall on # has d
