SET command parsing

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.

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.

Guys,

Whilst you're addressing SET syntax, I wonder if the AUTOFAV concept should actually be moved to the EFT scope.

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.

In terms of 'buying enough', I agree. I wonder how widespread the use of AUTOFAV actually is.