mIRC Home    About    Download    Register    News    Help

Print Thread
Hashtable item names with spaces #266694 13/01/20 06:55 PM
Joined: Jan 2004
Posts: 1,282
maroon Offline OP
Hoopy frood
OP Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,282
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)

Re: Hashtable item names with spaces [Re: maroon] #266695 13/01/20 07:42 PM
Joined: Jul 2006
Posts: 3,658
W
Wims Offline
Hoopy frood
Offline
Hoopy frood
W
Joined: Jul 2006
Posts: 3,658
I like the idea of a new switch on /hadd /hdel /hinc /hdel to indicate the item name is quoted.

The fact that mIRC doesn't load the last line with odd numbered line number should be a seperate report imo, it has nothing to do with quoted item name, if you make this same switch 'fix' the way mIRC handle this last line situation, it's then not possible to get that behavior only as well with the current hash table behaviors.


Looking for a good help channel about mIRC? Check #mircscripting @ irc.swiftirc.net