right but when using in a controlled environment (ie. your own scripts) 80% of the error checking is unnecessary, turning the snippet into essentially a one-(technically, two)-liner:
alias hcopy { var %f = $+($1,$ticks) | hsave -bu $1 %f | hmake $2 | hload -b $2 %f | .remove %f }
alias hren { hcopy $1 $2 | .hdel $1 }
This, however, is not how renaming *should* be done. It *should* be done by just changing the symbol name in the script engine's symbol table so that no copying is necessary at all. Renaming the symbol name would mean improved performance, which is why I believe the suggestion is good on the grounds that it is not possible to do (properly) via script-- NOT because it will reduce your script's line count by ~7 lines. hcopy could also be better implemented at the C level simply by a memcpy() of the hash structure, but of course everything could be better implemented in C, so I won't delve into that.
ps. you'll notice I used hsave/load in my implementation. You claim that it does not work properly in certain situations-- manually using /hadd will work improperly in many more situations, specifically with binary data, which your alias cannot get out. Technically, my alias probably won't maintain "unset" information or any items set with -z. unset information can be maintained by looping with
and adding with
hadd -mbu $+ $hget($1,%i).unset $2 &tmp
but this method still will not maintain the -z information. This is yet another reason this suggestion is useful, since you can't accurately copy a hash table via script anyway, no matter how many lines it takes.
Why you would need to copy or rename a table after creating it is another question though, but I won't even bother to ask. I don't buy the "using the name to store the status" story, by the way-- that can much more easily just be done with a "status" item in the table, and it makes more implementation sense too.
