Weird behaviour of 'hash' builtin
Hello Chet, hello list, during some discussion in the IRC #bash channel on freenode we found a weird behaviour of the 'hash' builtin command. The command exits true if the operand in question contains a /, no matter if that makes sense or not: --- $ hash 'CHANGELOG_CURRENT="http://slackware.osuosl.org/slackware-current/ChangeLog.txt";'; echo $? 0 --- --- $ hash 'meow/foo/baz'; echo $? 0 --- This alone is weird enough. When you add the -t option (if available) to print the pathname, it fails: --- $ hash -t 'CHANGELOG_CURRENT="http://slackware.osuosl.org/slackware-current/ChangeLog.txt";'; echo $? bash: hash: CHANGELOG_CURRENT="http://slackware.osuosl.org/slackware-current/ChangeLog.txt": not found 1 --- --- $ hash -t 'meow/foo/baz'; echo $? bash: hash: meow/foo/baz: not found 1 --- This happens on a 2.04 (no -t option to check the other case) aswell as on a 4.1. If this is not a bug, what's the reason behind this? Is it to blindly report success when an operand "looks like a pathname"? Regards, Jan "TheBonsai"
Re: Weird behaviour of 'hash' builtin
Jan Schampera writes: > If this is not a bug, what's the reason behind this? Probably because a command name containing a slash is never looked up on $PATH, thus never remembered and put in the hash table. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: create array in loop with variable in array's name
monoped wrote: > > Am 29.05.2010 01:04, schrieb pikta: >> >> Hi all, >> I'm just a beginer and I got stucked I'm trying to create multiple >> array with variable in array's name. I would expect to have 3 arrays and >> each of them would contain 3 elements like array1=(a b c) array2=(a b c >> ) >> array3=(a b c) ; what means that first element of array1[0]="a" and for >> example third element of array3[2]="c". This is the way how I do it : >> >> for (( n=1; n<4; n++ )) >> do >> array$n=(a b c) >> done >> >> ...but there is syntax error > > That's because array$n isn't a valid name. Use eval: > > eval "array$n=(a b c)" > > Bernd > > -- > Bernd Eggink > http://sudrala.de > > > Hi, thanks a lot for hint, it works as expected (I tried to give you 5 stars but somehow there are only 3 and I can not chacge it ...; but thanks a lot again!) -- View this message in context: http://old.nabble.com/create-array-in-loop-with-variable-in-array%27s-name-tp28712785p28723207.html Sent from the Gnu - Bash mailing list archive at Nabble.com.
fallback programmable completion for many or all commands
I like the programmable completion but I'm having some trouble getting it do do exactly what I want: I have a directory called fsbmk with links into my tree structure. I'd like all commands to fall back to looking here if they don't find anything else, or at least to merge all completion from this source with others. Problems: 1. Using complete -C whatever for every command in $PATH is too slow to do at startup. But I don't see another way to add compspecs for many or all commands. 2. I would like to operate without disturbing existing, potentially more specialized completion. The -D option doesn't work because it only applies when no compspec exists (I have some big library of compspecs from somewhere, though sorry I couldn't remember what). One can of course use parse the output of complete -p and make a wrapper function, maybe this is the best and intended mechanism. But its a little cumbersome. Thoughts? Britton
