|
Post by Stefan on May 20, 2024 3:51:37 GMT -5
George, Found this with v3.0.24091 as well as subsequent v3 betas.
I've always struggled with the SET command syntax. I expect it is a nightmare for the parser. Hence I tend to just open a SET edit session and add the desired entry, like a command ALIAS, directly there. So I'm not certain if this is buggy or working perfectly but I'm just too stupid. Example:
How do I set an alias command which has multiple terms, example: CHANGE ABC DEF ALL or even anything that requires quote, like CHANGE "A B C" "DEF" ALL ? SET ALIAS.mycmd = CHANGE ABC DEF ALL returns msg: Unkown SET operands
The HELP documentation suggests enclosing the entire 'value' clause in (different) quotes, but those are not removed. SET ALIAS.mycmd = "CHANGE ABC DEF ALL" works as a SET command, but the double quotes remain and when user enters mycmd, the string "CHANGE ABC DEF ALL" (including quotes) is left in the command line but not executed. Looks like parsing/coding may be a bit broken. Some errors in SET command syntax also return an error message consisting only of a single colon (:) Example: SET ALIAS.name =booboo (ie. missing a blank after '=')
I think there's gremlins here.
|
|
|
Post by Robert on May 20, 2024 8:15:42 GMT -5
Your last example of SET ALIAS.name =booboo is a usage error. According to the (old) SET parsing logic, the = sign must stand alone as a separate token. When you use a token like =booboo on the command line, the whole thing means to go look up a set symbol called booboo and substitute it in. That is not strictly a gremlin.
However, the whole logic behind the SET command is unfortunate and unsatisfactory. It means that the syntax used for a set assignment in the SET Edit session is not the same as a SET command. I have pointed this out in the past, but George decided that the command parser of the time couldn't accommodate it.
I could wish that the SET primary command, and the SET Edit data, adhered to the same syntax. Perhaps the existence of a new parser means there is now an opportunity to change this. But, then that would create inconsistencies with existing SET Edit data already stored.
There doesn't seem to be an ideal solution here. Perhaps the way SET handles quotes could be special-cased, but then that would mean an exception to the parsing logic. You could say that everything after the = sign was the value of the SET name, but then that would defeat the use of ; for multiple commands on the command line.
I believe the only solution is to change the syntax of the SET command, and apply a rigorous syntax definition so that these issues wouldn't occur again. For instance, the use of quotes here wasn't really well-defined; it's just an ad hoc piece of code. There's nowhere in the Help where you can read how to correctly use quotes, and there should be.
|
|
|
Post by George on May 20, 2024 12:05:48 GMT -5
Robert: The current HELP SET does a reasonable job of explaining the way the existing sdupport works.
ANyway, I had a look at the SET *COMMAND* when creating/updating a variable. I tweaked it so:
It will take either of XXX = YYY or XXX=YYY or XXX= YYY but not of course XXX =YYY for the reason Robert mentioned.
Multiple words, quoted or unquoted: Examples: Set symbol is xxx = 'yyy' yyy xxx = "'yyy'" 'yyy' xxx = 'yyy zzz xxx' yyy zzz xxx xxx = yyy 'sss' zzz yyy 'sss' zzz xxx = "'abc' def 'ghi'" 'abc' def 'ghi'
Basically just ONE set of OUSIDE quotes is removed from ALL combined data to the right of the = sign. All other quotes remain as-is.
A bit of updating to the doc. is needed as to how this works. Entering data in SETEdit remains the same. And existing SET data should work as expected.
I think this will do, we don't need some more involved changes to SET syntax to solve this.
George
|
|
|
Post by Robert on May 20, 2024 15:25:01 GMT -5
I wasn't aware that SET quoting had gotten so complicated. I have some concerns about this point, "Basically just ONE set of OUSIDE quotes is removed from ALL combined data to the right of the = sign. All other quotes remain as-is."
The one set of quotes that are removed, are they the first set going left to right? What happens if you actually want the SET value to include the quotes? Is there any way to prevent quotes from being removed?
Many moons again, far too many for me to remember, there was a thing you could do in COBOL when you wanted to replace text from a COPY module. The syntax was like this (IIRC):
COPY 'member' REPLACING ==ABC== BY ==DEF==, REPLACING ==123== BY =="XYZ" ...
The point is that the == double equal sign acted as "syntax quotes" so that you were quoting any valid syntax and replacing it with any other valid syntax. And of course, == was not used in COBOL for anything else, so it couldn't be mistaken for the wrong thing.
I think this could be a useful idea, for basically the same reason. Suppose you allowed == to mean a "syntax quote". Then, you could put anything inside the syntax quotes and not worry about literal string quotes getting removed by mistake.
Here, == is just an example. You could make up any nonstandard punctuation, like \\ or something, that wasn't used anywhere else. Using syntax quotes also would mean that a SET command could be followed by a ; and another command without problems, and a SET value could CONTAIN a ; without confusing the parser.
|
|
|
Post by George on May 20, 2024 15:42:35 GMT -5
Robert: It's really not complicated:
1. Everything after the = sign is treated as one single string. 2. The standard StrUnquote function is applied. i.e. if it starts and ends with a " ' or `, they are removed. 3. Whatever remains, whether it has any further quotes or not, is the value for the SET variable.
Examples:
xxx = FRED the value of xxx is FRED xxx = "FRED" the value of xxx is FRED xxx = "'FRED'" the value of xxx is 'FRED' xxx = abc def 'ghi' jkl the value of xxx is abc def 'ghi' jkl xxx = "abc def ghi" the value of xxx is abc def ghi xxx = '"abc" def "ghi" "jkl"' the value of xxx is "abc" def "ghi" "jkl"
Hope this clarifies it.
George
|
|
|
Post by Stefan on May 21, 2024 0:38:32 GMT -5
Guys,
Whilst you're addressing SET syntax, I wonder if the AUTOFAV concept should actually be moved to the EFT scope.
|
|
|
Post by George on May 21, 2024 10:15:14 GMT -5
Stefan: Hmmm possibility. I'll see how it looks.
George
|
|
|
Post by Robert on May 21, 2024 10:41:22 GMT -5
AUTOFAV uses a SET name to add a file to a favorites file list.
SET AUTOFAV.filemask = filelist-name
EFT uses a file mask to select a profile name. Not really the same. Now, *maybe* the EFT extended file mask syntax could be adapted by the AUTOFAV logic, but since you could have multiple AUTOFAV set names pointing to the same filelist, I don't see how adding this would really buy you anything. I am the one that came up with the AUTOFAV idea, and even I wouldn't ask for it to be extended. I think it's good enough as it is.
|
|
|
Post by George on May 21, 2024 13:16:04 GMT -5
Robert is probably right. EFT may offer a more powerful masking ability, but I don't think it 'buys' enough. Migrating could be tricky. With R2 and R3 versions sharing the CFG file, it gets really dicy if the EFT table in one version has new functionality.
George
|
|
|
Post by Stefan on May 21, 2024 13:36:45 GMT -5
In terms of 'buying enough', I agree. I wonder how widespread the use of AUTOFAV actually is.
|
|
|
Post by Robert on May 21, 2024 17:18:42 GMT -5
The answer to that is, no one knows, like it always has been. If SPFLite had telemetry we could answer it, but adding telemetry now wouldn't be worth it if the code is going into maintenance mode. I would sincerely advise against yanking features that seem to be little used. If they aren't hurting anything I say leave them be.
|
|
|
Post by George on May 22, 2024 8:09:53 GMT -5
Robert: ![???](//storage.proboards.com/forum/images/smiley/huh.png) When I had telemetry in and working in a test version you shot it down over possible security implications in EU and elsewhere. So I yanked it. Now it sounds like you wish we had it. Can't win. George
|
|