|
|
Post by Jo on Sept 24, 2023 16:26:32 GMT -5
ML short form of MAKELIST only accept one parm: "Excessive operands for the ml command". Circumvention: MAKELIST (long form) accepts additional parms (SYM REPL).
Jo (Vers 23267)
|
|
|
|
Post by Robert on Sept 24, 2023 22:07:45 GMT -5
Jo, the fastest circumvention is to set up an alias so that you can use the ML command:
SET ALIAS.ML= MAKELIST
I just tried it with ML MYLIST SYM and it created this as MYLIST.FLIST:
D:\MYFOLDER\ABC\|*.*
I believe this ALIAS should do what you need. Of course it would be good if the ML command worked right natively, but this is a good workaround.
R
|
|
|
|
Post by mueh on Sept 25, 2023 8:26:47 GMT -5
Hi George !
ObjPCmdT.inc
DATA "ML", 99, 1, N, 0, 99, N, N, N, N, N, "SYM,REPLACE,APPEND"
DATA "MAKELIST", 0, 3, N, 0, 99, N, N, N, N, N, "SYM,REPLACE,APPEND"
'- PCmd# NmOp LnOp Scr FMPcmd Macro Chain Track Brws EFT
ML cmd has NMOp 1 .
Hope this saves time .
|
|
|
|
Post by George on Sept 25, 2023 9:22:58 GMT -5
MUEH: Before even looking for it I assumed that was the cause. The error message wasn't from ML, it was from the general command scanner.
I'll correct it.
Thanks
George
|
|
|
|
Post by Robert on Sept 25, 2023 11:06:23 GMT -5
George, forgive me for saying so, but I feel that the bug that was revealed here shows that your design is error-prone. You ought to correct the design, and not just fix the bug.
How? Right now, in this example, ML is treated exactly like its own command, and not as an alias of MAKELIST. That forces you to type in two entries that are identical, except for name. That is just a bug waiting to happen.
I recommend that you restructure your command table into two parts. The first part would be an "alias lookup". In this example, "ML" would be in the alias table, and its only data would be the main command name of MAKELIST. If you find a command in the alias table, that is the name you then use to search the main table, otherwise the command as entered by the user is used to search the main table.
And no, I don't see this as slowing anything down, because right now you are ALREADY searching for aliases - only, you are doing so at the same time you are searching for the full-name versions of commands.
If my memory serves, this kind of bug has happened before in the past. Take this opportunity to squash this vulnerability once and for all.
R
|
|
|
|
Post by George on Sept 25, 2023 12:12:18 GMT -5
Robert: I appreciate your thoughts, but no. These entries only change when a primary command is added or deleted. There's probably more danger in creating the alias table and removing them from the main table than there is in just leaving them alone.
Also, I don't need make-work projects.
George
|
|
|
|
Post by Robert on Sept 25, 2023 12:22:34 GMT -5
George, just so I was sure, I looked up "make-work". The Cambridge dictionary says it means, "unimportant work given to someone [merely] to keep that person busy". Do you really believe a design change that would avoid the creation of inadvertent bugs is unimportant? Is moving a single line, like the one defining ML, actually dangerous?
I didn't realize you were so skittish about making changes. I would have thought that debugging work was work, too. JSYK, I had your best interests at heart in making this suggestion. Oh well.
R
|
|
|
|
Post by George on Sept 25, 2023 12:46:01 GMT -5
Robert: In my mind I have a very long list of potential SPFLite internal re-structuring that could be done. I look at the code almost every day, I see the problems in how things 'just grew' in the past, and wish they had been done better.
But past experience in doing such changes is that the simplest ones can still uncover an un-Godly number of forgotten tweaks and minor 'accommodations' that we put in over the years. So I let sleeping dogs lie.
I've done significant revisions over the years to tidy things up, the last one was the 23259 one I believe. It started out as just a minor one and 'just grew'. But no more. Cleanup stuff like the alias table here will not happen. I've had it, I'm making too many dumb errors.
George
|
|
