Forums Feature Suggestions /bset enhancements

Responses to your responses.

Your response for #1:

I don't see how it's breaking compatibility for /bset to report an error when someone makes a syntax error, instead of giving them something different than nobody would want. The default for /bset it to treat input as numeric byte values, so it should not switch to seeing it as text when the -t switch is not used. Someone feeding %string to /bset wanted the whole thing put into the &binvar. They wouldn't want it treated as if a byte value when it happens to be integer, or having 1 character of the string put into the &binvar when it's not. It would be as if $encode(&soitgoes) decided to use the contents of a binvar if a binvar of that name happened to exist at the time, but at other times would treat it as if it's a text string.

Your response for #4:

You could argue whether or not you think it's a useful feature, but I don't understand your claim that this interferes with backwards compatibility. Nobody is intentionally using $bvar(&v,1-).nlong and using the .property with the intention of being given 1-or-more byte values instead.

My proposed change would make the identifier's behavior conform with F1 help, where the 4 .properties don't say 'sure but only if you ask it for just 1 of them'. Note it says values plural not 1 value:



Your response for #9:

Agreed. It probably makes more sense to have a different letter. I was just trying to make the switch letter be intuitive, and p-for-position is what I came up with, but this is fine.

Your response for #2:

First time you yell at me that my post wasn't long enough. Progress!

To keep it shorter I just listed 1 example in the post directly. But I also had a 2nd example in the base85 decoder script I linked, where I did this so that it has the same behavior as $decode does for mime, where it sets the &binvar as blank if it contains exactly 1 encoding character. i.e.

//bset -t &v 1 B | noop $decode(&v,bm) | echo -a blank binvar: $bvar(&v1) : $bvar(&v,0)

A 3rd way is in some of my other scripts to immunize a &binvar from identifiers that bomb if you feed them a binvar that doesn't exist:

echo -a debug message: $bvar(&no_such_binvar,1-)
echo -a debug message: $sha1(&no_such_binvar,1)
bcopy -c &destination 1 &no_such_binvar 1 -1
bwrite -c delme.txt 0 -1 &no_such_binvar

Regarding #2, you mentioned in channel that you thought a switch wouldn't be needed, and it could just create a blank binvar like "bset &var 1 $null" or create a &binvar containing 3 zeroes from "bset &var 4 $null". I was basing the -z switch from the new switch for /writeini which requires a switch to verify that the intent is to write a blank rather than accidentally doing it because a %variable was empty. Though, the opposite is being done by /write like in your suggestion, in the case of "write delme.txt" which does create a zero byte file when the write_string is 'missing'.