Re: I wish hash -r (or something like it) would happen automaticly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Britton Leo Kerin on 1/6/2006 12:10 PM: > I sometimes forget to run hash -r after sticking something new in my > path, and get confused. One thing I've always been hazy on is whether > there is a way in unix to connect to a 'dir-contents-changed' signal > or the like, but if so I would much prefer my interactive shells at > least to automaticly notice new binaries as they show up in $PATH. > Its especially confusing because the 'which' command, which is the > first one people learn to find out which binaries they are running. You could always turn hashing off: set +h There is also a feature for re-searching the path when a program disappears from its hashed location, but that is not quite the same as your question of adding a program earlier in the PATH than what was hashed: shopt -s checkhash As for a "'dir-contents-changed' signal", the ctime (found from calling stat()) of every directory in the PATH is the POSIX way of detecting whether a directory has been modified, but bash does not currently cache or check the ctime of the directories that appear in PATH prior to the hashed location of a command. Maybe someone would like to submit a patch that does that? If so, it would probably belong to another shopt setting, since the point of hashing is to avoid extra stat calls. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDv9Xh84KuGfSFAYARAgefAJ4uNguLJny63tqdIvjYFaLUQLyVGACgtbsh dg7+9DBCKg11q/CUfSU2jgc= =jOO0 -END PGP SIGNATURE- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: Conditional expression problem: both "-a file" and "! -a file" return true
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to [EMAIL PROTECTED] on 1/6/2006 3:02 PM: > > [EMAIL PROTECTED]:~$ touch testFile > [EMAIL PROTECTED]:~$ [ -a testFile ] && echo true || echo false > true POSIX requires (http://www.opengroup.org/onlinepubs/009695399/utilities/test.html) that a test with two arguments (in your case, "-a" and "testFile") produce unspecified results if the first is neither "!" nor a unary primary. "-a" is not a required POSIX unary operator. So bash is in its right to return whatever it wants; in this case, bash has the extension that "-a" is also a unary operator, returning 0 if file exists (contrast that with coreutils' /bin/test, which does not have a unary -a, so it currently returns 1, although it would also be valid for coreutils to print an error message that an unknown unary operator was encountered and return 2). > > [EMAIL PROTECTED]:~$ [ ! -a testFile ] && echo true || echo false > true Now, in this case, you have three arguments, and POSIX requires that the binary operator "-a" have higher precedence than the "!" negation operator on a 2-argument test. And the one-argument test of "!" and of "testFile" both return true (since neither is the empty string), so the overall expression returns 0. You are probably better off using the unary operator -e for file existance rather than -a. Also, be aware that bash also defines a unary -o, so the following also has strange results, for the same reasons as above: $ set -o monitor $ rm -f monitor $ test -o monitor && echo true true $ test ! -o monitor && echo true true - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDv9t084KuGfSFAYARAmpVAJsF+DGBDWhubt2hNB4aVgNMuhTsbgCgliGS dtP5QKjRVthlW5zcgKcGy00= =28b8 -END PGP SIGNATURE- ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash-3.1.1: source does not work in conjunction with process substitution
Dmitry V. Levin wrote: > Hi, > > The "source" builtin does not work in conjunction with process > substitution: Correct. The bash source builtin only works with regular files. This is a limitation that will someday be lifted. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
Re: bash-3.1.1: unable to feed "trap -p" output into a pipe
Dmitry V. Levin wrote: > Hi, > > A "trap -p" output doesn't feed into a pipe: > $ trap -p > > $ trap "echo ..." EXIT > > $ trap -p EXIT > > trap -- 'echo ...' EXIT > > $ trap -p EXIT |wc -l > > 0 > Each element of a pipeline is run in a subshell. Subshells don't traps from their parent. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ( ``Discere est Dolere'' -- chet ) Live Strong. Chet Ramey, ITS, CWRU[EMAIL PROTECTED]http://cnswww.cns.cwru.edu/~chet/ ___ Bug-bash mailing list Bug-bash@gnu.org http://lists.gnu.org/mailman/listinfo/bug-bash
