Today's ROM, 24/01/21

Today only, my boot displays an error along the lines of: File “-quit” not found.

I’ve searched the whole boot for the incidence of a “-quit” to no avail, but then looked at Julie’s “removal of need for quote-marks” work, and see that, for example, the Alias$@Runtype for file FFB does include such a term, and am therefore wondering if this is where the error is being introduced.

If so, a rethink may be needed!

I have reverted to yesterday’s ROM – all this being the purpose of testing the experimental ROM images!

RPi2 Model B running 5.29 (24-Jan-21) showing this error.

:-/

Are you able to use Harinezumi or Reporter in your !Boot to see what is making the error?

It’s a post-Harinezumi error, a desktop error box.

I have Harinezumi running as part of the boot.

Perhaps someone who has Reporter already installed and sees the error may be able to help more?

I have reported, I have reverted!

Perhaps if I have time later.

Where are these aliases set?

After a quick test with todays ROM I suspect the problem is that SYS "OS_GetEnv" TO env$ used to have double quotes round the program name, but now does not. This, in my case, seemed to upset !SerialDev.Utils.RepeatBoot … but to say ‘Directory ’BASIC’ not found, which is not the same as above.

But the omission of quotes could upset different programs in different ways. I will do some more experiments…

Can’t reproduce that on RPCEmu with only the ROM replaced with the Jan 24, however from playing around with the SideDiff boot file I still have the last two lines commented out.
Let’s change that and restart…

Edit No not that.
Edit2 Merged in latest !Boot (keeping the Harinezumi version Run) still no error.

Looks like something specific in your Desktop that’s triggering it.

Testing with a BASIC program RAM:CheckEnv containing just

SYS "OS_GetEnv" TO env$
*Report env$

RAM:CheckEnv fred jim joe

13:08:57.36 Run RAM::RamDisc0.$.Check
13:08:57.36 @RunType_FEB RAM::RamDisc0.$.Check
13:08:57.36 %Set Obey$File RAM::RamDisc0.$.Check
13:08:57.36 %Obey RAM::RamDisc0.$.Check
13:08:57.36 RAM:CheckEnv fred jim joe
13:08:57.36 @RunType_FFB RAM::RamDisc0.$.CheckEnv fred jim joe
13:08:57.36 Basic -quit "RAM::RamDisc0.$.CheckEnv" fred jim joe
env$="BASIC -quit "RAM::RamDisc0.$.CheckEnv" fred jim joe"

13:09:38.82 Run RAM::RamDisc0.$.Check
13:09:38.82 @RunType_FEB RAM::RamDisc0.$.Check
13:09:38.82 Obey RAM::RamDisc0.$.Check
13:09:38.82 RAM:CheckEnv fred jim joe
13:09:38.82 @RunType_FFB RAM::RamDisc0.$.CheckEnv fred jim joe
13:09:38.82 Basic -quit RAM::RamDisc0.$.CheckEnv fred jim joe
env$="BASIC -quit RAM::RamDisc0.$.CheckEnv fred jim joe"

I fear this will upset different programs in different ways, depending on how they parse the environment string.

For future reference, here is how part of the RISC OS build system reads a filename argument:

bufsz% = 25
DIM buf% bufsz%
SYS "OS_GetEnv" TO args%
SYS "OS_ReadArgs", ",load=quit/K,file", args%, buf%, bufsz%
SYS "XOS_GenerateError", buf%!8 TO file$
IF LEN(file$) THEN
  ...
ENDIF
QUIT

Perhaps if I have time later.

Right, I have loaded Martin’s excellent Reporter and it tells me that the error occurs the first time I attempt to use a BASIC program – in my case my own TaskCheck program attempting to see if a task is running before executing some further action.

So it seems that any BASIC program may raise the error.

It also mucked up my ROOL forums log-in program, which also uses a BASIC routine as part of its process, so that I’ve had to revert to yesterday’s ROM to post this message.

The appropriate bit of Reporter’s log is this:

15:15:08.00 [WindowManager/] Set CDROMFS$Dir <Obey$Dir>
15:15:08.00 [WindowManager/] IconSprites <Obey$Dir>.!Sprites
15:15:08.01 [WindowManager/] <Obey$Dir>.TaskCheck "CDROMFS Filer"
15:15:08.01 [WindowManager/] @RunType_FFB SDFS::SD16Tosh_1.$.!BOOT.Choices.Boot.Tasks.!cdromfs.TaskCheck "CDROMFS Filer"
15:15:08.01 [WindowManager/] Basic -quit SDFS::SD16Tosh_1.$.!BOOT.Choices.Boot.Tasks.!cdromfs.TaskCheck "CDROMFS Filer"
15:15:08.01 [BASIC/] -quit SDFS::SD16Tosh_1.$.!BOOT.Choices.Boot.Tasks.!cdromfs.TaskCheck "CDROMFS Filer"
File '-quit' not found
15:15:08.02 ** Error **
  Error  : &000000D6
  Message: File '-quit' not found
15:15:08.02 ** Error **
  Error  : &000000D6
  Message: File '-quit' not found
15:15:08.02 ** WimpError ** from unknown task
  Error  : &000000D6
  Message: File '-quit' not found

It would therefore seem to me that the premise on which the change from using quotes was based was a misunderstanding!

A similar problem occurs with !Delay by Ian Hamilton.

Delay is called with a command to be run and a delay to be applied before it is run.

OS_GetEnv is called followed by a search for the last inverted comma, the cpmmand to be delayed and the delay are thus extracted. The difference is shown below.

*FX0
RISC OS 5.29 (03 Dec 2020)
*

5:08:27.56 RUN <Delay$Dir>.Delay Filer_Run Resources:$.Apps.!Alarm 2100
15:08:27.56 @RunType_FFB SDFS::SD32gr.$.Boot.Resources.ToBeBoots.!Delay.Delay Filer_Run Resources:$.Apps.!Alarm 2100
15:08:27.56 Basic -quit "SDFS::SD32gr.$.Boot.Resources.ToBeBoots.!Delay.Delay" Filer_Run Resources:$.Apps.!Alarm 2100
command$=" Filer_Run Resources:$.Apps.!Alarm 2100"
command$="Filer_Run Resources:$.Apps.!Alarm" , delay%=2100
15:08:27.56 Exec

*FX0
RISC OS 5.29 (24 Jan 2021)
*

14:59:47.83 RUN <Delay$Dir>.Delay Filer_Run Resources:$.Apps.!Alarm 2100
14:59:47.83 @RunType_FFB SCSI::SSD120.$.Boot.Resources.ToBeBoots.!Delay.Delay Filer_Run Resources:$.Apps.!Alarm 2100
14:59:47.83 Basic -quit SCSI::SSD120.$.Boot.Resources.ToBeBoots.!Delay.Delay Filer_Run Resources:$.Apps.!Alarm 2100
command$="BASIC -quit SCSI::SSD120.$.Boot.Resources.ToBeBoots.!Delay.Delay Filer_Run Resources:$.Apps.!Alarm 2100"
command$="BASIC -quit SCSI::SSD120.$.Boot.Resources.ToBeBoots.!Delay.Delay Filer_Run Resources:$.Apps.!Alarm" , delay%=2100
14:59:47.84 Exec

It would therefore seem to me that the premise on which the change from using quotes was based was a misunderstanding!

What I think I’m saying there is that a reversion is necessary until something is sorted which makes it actually work!

But, as I said before, that’s why we have a “daily” test ROM image – to highlight problems! Thank you for trying!

It would therefore seem to me that the premise on which the change from using quotes was based was a misunderstanding!

It’s hard to tell what TaskCheck is doing, given that there’s no uncrunched source, but the fact that it seems to be navigating its way through the *command which called it using INSTR() and CHR$34 doesn’t give me a warm, fuzzy feeling. Command lines are space separated, so you should be breaking it down by spaces and parsing it that way.

Or, as Julie points out, using OS_ReadArgs, which is what it’s for. I’d be slightly hypocritical if I supported that idea, but at least my released BASIC seems to rely on spaces and named parameters, and doesn’t assume that things are quoted. I think… I have just done a grep -r OS_ReadArgs on my source code folder to see what crimes it might conceal.

That said, there will probably be a lot of stuff out there which is doing similarly broken things. It’s nice to highlight it (and I’ll probably fix my stuff now, to use the far simpler approach of OS_ReadArgs instead of rolling my own equivalent), but whether breaking it is good is another issue.

The case I found was the BASIC program RepeatBoot v0.10, part of the !SerialDev package now maintained by Paul Reuvers of X-Ample. It certainly looks for the quotes round the file name to extract it.

Some individual ones can no doubt be fixed, but there is no way to find them all – probably most would be found by users trying to run something that has worked fine for years, and I think we have to avoid that.

I have just tried the code that Julie suggested above, using OS_ReadArgs … and it does not seem to work when passed *Basic -quit TestEnv, as the filename appears at buf%!4 not 8.

However, if *Basic TestEnv is omitted from the command, it does work.

I need to think about that…

trying to run something that has worked fine for years

Yes, I think the expression evaluation needs to be looked at (if possible/feasible), not just removing the quotes from the command.

Martin, if you add “/S” to the end of “load=quit/K”, I think you’ll find it works.

I’m puzzled as to why we need to get rid of quotes at all, particularly as it seems to break many pre-exising things. What are the potential benefits we may harvest from this endeavor?

I’m puzzled as to why we need to get rid of quotes at all, particularly as it seems to break many pre-exising things.

Having the quotes breaks other stuff, it seems.

Specifically, a BASICTxt filetype was added, which contained the aforementioned quotes.

This upsets the standard way to test for a variable being set in an Obey file, which presumably has never been noticed because no-one has bothered to check if BASIC has a load action set before – they just assume that it does. And very possibly BASIC was one of the few things to quote the filename in its load and run action variables.

It was pointed out, not unreasonably, that the quotes are superfluous since filenames can’t contain spaces… which was acted on a few days ago.

Unfortunately, what this change has revealed is that a lot of people are not parsing the BASIC command line correctly in their BASIC programs, but are doing icky stuff involving looking for quotes and other specific bits which depend a lot on how Alias$@RunType_FFB happens to have been set for the past 30 years…

Unfortunately, what this change has revealed is that a lot of people are not parsing the BASIC command line correctly in their BASIC programs, but are doing icky stuff involving looking for quotes and other specific bits which depend a lot on how Alias$@RunType_FFB happens to have been set for the past 30 years…

Is it just me or does anyone else see parallels with the thousand-and-one “undocumented API” items in Windows, which were actually security flaws and when fixed the change broke various programs that were “not doing it the right way”

Or more locally – zero page abuse.

not parsing the BASIC command line correctly in their BASIC programs

Please define parsing correctly.

If it is burned into ROM that BASIC run actions are “this has quotes around it”, then it is perfectly acceptable to search for the start of parameters either by looking for a quote character, or, safer, looking for “-quit” and advancing seven places from that. Which is, I should point out, exactly how ChangeFSI does it.
Thus, if there isn’t a quote, consider ChangeFSI to be broken too, because it expects to see one.
Likewise, if you are only looking for one thing (like a filename), you might not even think to call a SWI to parse that. Just get the command line, INSTR for the quote, MID$ out that, and hack off the last character (the closing quote). There’s nothing ickier about that than all the block%!offset% rubbish that is required to do Wimp stuff in BASIC.

In my life hacking code, it always seems to me that the simple fixes cause the biggest amount of damage. Rewrite the Obey module in C? Yeah, no probs. Remove two simple quotes? Kabluey. ;-)

Please define parsing correctly.

Treating it as a command line…?

If it is burned into ROM that BASIC run actions are “this has quotes around it”, […]

That’s until someone does

Set Alias$@RunType_FFB ...

as part of their boot sequence, because they want to do something clever when BASIC files are run?

Thus, if there isn’t a quote, consider ChangeFSI to be broken too, because it expects to see one.

Having spent some of the day staring at bits of the FormEd code, I’m afraid that I’m not necessarily going to accept “what Acorn did in the 1980s” as an arbiter of “not broken”. :)

if you add “/S” to the end of “load=quit/K”, I think you’ll find it works.

So it does. (Note that I tried first just adding the S, which did not work, but I then added /S as you said and it was indeed ok.)

I agree that the RunType would have been better without the added quotes, but I cannot yet see how we can avoid breaking things – some of which will be difficult to mend.

Yes, I think the expression evaluation needs to be looked at (if possible/feasible), not just removing the quotes from the command.

So I change the expression evaluator to follow the documentation and only GSTrans strings, only to find this in !StrongED.StartUp.SetupCfg:

If "<StrED_cfg$Dir>" = "" AND <Ctrl$Pressed> = 0 Then IfThere <Choices$Write>.!StrED_cfg Then Set StrED_cfg$Dir <Choices$Write>.!StrED_cfg
If "<StrED_cfg$Dir>" = "" AND <Ctrl$Pressed> = 0 Then IfThere <StrongED$SettingsDir>.!StrED_cfg Then Set StrED_cfg$Dir <StrongED$SettingsDir>.!StrED_cfg

And !ZapFonts.!Boot contains:

If "<Zap$OSVsn>" <> "" Then SetEval ZapFonts$OSVsn <Zap$OSVsn>

I am trying applying a GSTrans like transformation to the expression without expanding anything in quotes.

Having spent some of the day staring at bits of the FormEd code, I’m afraid that I’m not necessarily going to accept “what Acorn did in the 1980s” as an arbiter of “not broken”. :)

Sometimes people are “sentimentally” (or mentally) attached to the brokenness.
I did mention undocumented Windows API’s earlier. How many years between Acorn deprecating zero page access and the 2012 change? How many complaints?

Not necessarily, complexity is another perspective. Hence the experimental ROM surfacing the implementation detail, the behaviour.

Replies to what I’ve written or off-topic banter → Aldershot… ;)

Sorry for the inconvenience everybody. I’ve put in a request to change back to how it was.

If anybody wants to use the development ROM in the mean time, please use Rick’s workaround.