Hashtable item names with spaces - 13/01/20 06:55 PM
This could turn into a feature request or a bug report.
There should probably be either
+ a different definition of what's a valid itemname
+ a different behavior when they're encountered
+ a new switch to allow /hadd /hdel /hinc /hdec to handle itemnames having spaces.
When hload in 'default' format encounters a textfile having an odd number of lines, it silently ignores the final line. It should either load that final line as an itemname with $null data, or show a *info message, or both.
When any odd-numbered line contains spaces, /hload fills the itemname with spaces, which can be in the leading/trailing/internal/consecutive positions. There's no problem accessing them like $hget(table,N).data or $hget(table,%var_containing_itemname_with_spaces), but /commands like /hdel or /hadd can't access it.
It wouldn't be backwards compatible for /hdel to interpret the entire commandline as the itemname, because of scripts using the same string for creating and deleting the item like:
//hfree -w test | var %a item1 data1 | hadd -m test %a | echo -a $hget(test,1).item $hget(test,1).data | hdel test %a | echo -a gone: $hget(test,1).item $hget(test,1).data
Even if /hdel changed to see the entire commandline as the itemname, that doesn't solve the issue for /hadd/hinc/hdec. I can see this causing scripts to freeze due to assuming that $hget(table,1).item can always be deleted.
A compromise that would support all filenames except those containing double-spaces or a leading/trailing doublequote would be a -q switch to indicate the itemname has been $qt()'ed. Another alternative would be a -v switch that the 1st parm is a %var containing the 'real' itemname. Using a &binvar to contain the name has the overhead of calling $regsubex to fill it. Or have /hload specifically ignore leading/trailing spaces in itemnames, but keep current behavior for the data rows.
There are cases where itemnames containing spaces can be useful, such as using filenames as itemname instead of placing them as the .data, so I'm not advocating silently treating this as an invalid itemname, which would either drop an item from the middle of the .hsh file, or cause all remaining items to be skipped. Unless it's considered a 'feature' to have read-only itemnames.
In this example, test.txt has 3 lines, so the 2nd item is silently ignored, which has nothing to do with the itemname having spaces. In this case, it should do something besides silently ignoring the itemname, whatever that is.
If you remove the semi-colon from the 2nd /write, it completes the 2nd record, allowing the 2nd itemname containing spaces to be created. It also writes a 3rd item name having a leading space. Neither of these items can be /hdel'ed or /hadd'ed.
//write -c test.txt $+(item1,$crlf,data1,$crlf,cant delete itemnames with spaces) | write test.txt $+($crlf item3,$crlf,data3) | hfree -w test | hload -m test test.txt | hdel -s test item3 | echo -a there are $hget(test,0).item items | var %i 1 | while ($hget(test,%i).item) { echo 4 -a item: $v1 data: $hget(test,$v1) | inc %i } | echo -a length of itemname3 is $len($hget(test,3).item)
There should probably be either
+ a different definition of what's a valid itemname
+ a different behavior when they're encountered
+ a new switch to allow /hadd /hdel /hinc /hdec to handle itemnames having spaces.
When hload in 'default' format encounters a textfile having an odd number of lines, it silently ignores the final line. It should either load that final line as an itemname with $null data, or show a *info message, or both.
When any odd-numbered line contains spaces, /hload fills the itemname with spaces, which can be in the leading/trailing/internal/consecutive positions. There's no problem accessing them like $hget(table,N).data or $hget(table,%var_containing_itemname_with_spaces), but /commands like /hdel or /hadd can't access it.
It wouldn't be backwards compatible for /hdel to interpret the entire commandline as the itemname, because of scripts using the same string for creating and deleting the item like:
//hfree -w test | var %a item1 data1 | hadd -m test %a | echo -a $hget(test,1).item $hget(test,1).data | hdel test %a | echo -a gone: $hget(test,1).item $hget(test,1).data
Even if /hdel changed to see the entire commandline as the itemname, that doesn't solve the issue for /hadd/hinc/hdec. I can see this causing scripts to freeze due to assuming that $hget(table,1).item can always be deleted.
A compromise that would support all filenames except those containing double-spaces or a leading/trailing doublequote would be a -q switch to indicate the itemname has been $qt()'ed. Another alternative would be a -v switch that the 1st parm is a %var containing the 'real' itemname. Using a &binvar to contain the name has the overhead of calling $regsubex to fill it. Or have /hload specifically ignore leading/trailing spaces in itemnames, but keep current behavior for the data rows.
There are cases where itemnames containing spaces can be useful, such as using filenames as itemname instead of placing them as the .data, so I'm not advocating silently treating this as an invalid itemname, which would either drop an item from the middle of the .hsh file, or cause all remaining items to be skipped. Unless it's considered a 'feature' to have read-only itemnames.
In this example, test.txt has 3 lines, so the 2nd item is silently ignored, which has nothing to do with the itemname having spaces. In this case, it should do something besides silently ignoring the itemname, whatever that is.
If you remove the semi-colon from the 2nd /write, it completes the 2nd record, allowing the 2nd itemname containing spaces to be created. It also writes a 3rd item name having a leading space. Neither of these items can be /hdel'ed or /hadd'ed.
//write -c test.txt $+(item1,$crlf,data1,$crlf,cant delete itemnames with spaces) | write test.txt $+($crlf item3,$crlf,data3) | hfree -w test | hload -m test test.txt | hdel -s test item3 | echo -a there are $hget(test,0).item items | var %i 1 | while ($hget(test,%i).item) { echo 4 -a item: $v1 data: $hget(test,$v1) | inc %i } | echo -a length of itemname3 is $len($hget(test,3).item)