/unset is indeed buggy, but not because of the loop. It's because of the variable in $read(). Unlike /set, /unset is weird when you pass it an identifier that contains variables (I'm guessing it's somehow related to its ability to unset multiple variables). In your example, the variable %x inside $read() isn't even evaluated correctly. For example, this:
echo -a unset -s $read(safedb.txt,n,%x) | unset -s $read(safedb.txt,n,%asdflkjlg)
always unsets the first variable in the file. This also happens if you type it manually, outside of any loops. For some odd reason, $read(safedb.txt,n,%anythinghere) always returns the first line to /unset.
If you're interested in a solution, you can enclose $read() in [ ] to pre-evaluate it, so that /unset doesn't get to see the variable name or $read():
unset -s [ $read(safedb.txt,n,%x) ]
Edit: the reason $read() returns the first line isn't that odd after all: it's because the variable name (and not the value) is passed to $read(). When you pass $read() anything other than a number as N (in this case the string "%x"), it defaults to the first line. So /unset's problem in your case is that it doesn't evaluate %x at all.
Last edited by qwerty; 25/04/05 11:14 AM.
