@getstatus needs a new, or user-selectable, separator

[Former user]

@getstatus uses / to separate the commands it's reporting.

The problem is that some recently introduced, persistant commands which could be reported by getstatus include paths in #RLV which also use / as a delimiter. Net result - when one of these commands is read back by getstatus it's not possible to determine if you're reading another element of the #RLV path or the next restriction along

Preferred fix - extend getstatus(all) to allow a single or multi-character delimiter to be specified. If none is specified keep the existing behaviour.

-Chorazin Allen

[Alan Glover]

Another aspect of the same thing needs highlighting too - consider a #RLV folder named the same as a RLV restriction, let's say sendim, and let's also say that sendchat and recvim restrictions are in effect.

Say the following is applied - @detachthis:folder1/sendim/folder2=n ...and read back with getstatus, it could return as

/sendchat/detachthis:folder1/sendim/folder2/recvim

There's no easy way for the script to figure out where the #RLV path ends, and worse, it could end up believing a sendim restriction is in effect when it isn't (some toys already check whether restrictions are in effect that prevent them functioning - eg checking for wear being prevented if they want to wear something). This could be exploited to fool toys into believing restrictions are in effect when they actually are not.

[I said no easy way... a script could conceivably do multiple getstatus:<command> calls to check for every RLV lasting restriction which uses a #RLV path and then eliminate the returned substrings from the overall returned getstatus, however that's a long way from being ideal and is putting the complexity in the wrong place - in the script not the viewer]

[Marine Kelley]

Yes, that was a long-standing bug, introduced because I didn't notice the separators were conflicting.

Fixed in 2.8 by turning the @getstatus[all] command into this :

@getstatus[all][:command[;separator]]=2222

Attention, this means the separator needs to be put behind a semi-colon (";"), and only when there is already a colon (":"). If there is no colon, then the command won't work.

[Marine Kelley]

After talking with Henri, I changed the first slash to be equal to the separator too (except if the specified separator is empty, in which case it defaults to a slash). That way scripts will have it easier to parse it.

Since it is a minor change in the spec, I am bumping it to 2.8.1, and releasing a new RLV to match it.