Today's ROM, 24/01/21

[Steve Fryatt]: 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.

To be fair, it is dealing with tasknames, which CAN contain spaces, unlike Julie’s pathnames!

I admit I could have done better with hindsight! But then, …

Taken from here a further possible issue with 24-01-21 ROM.

So thats most likely why Private Eye is broken as well then…

From a Titanium.

*FX0
RISC OS 5.29 (24 Jan 2021)
*

PrivatEye fails :-

Filing system or path PrivateEyeRes: not present

Postmortem requested
fc161848 in anonymous function
cb1c in anonymous function
  Arg2: 0x0000cae4 51940 -> [0xe1a0c00d 0xe92ddbf0 0xe24cb004 0xe24dcf45]
  Arg1: 0x0006c538 443704 -> [0x6972503c 0x65746176 0x24657945 0x3e726944]
fc1517c0 in shared library function
5dc98 in anonymous function

Its !Run has this :_

Run <PrivateEye$Dir>.Resources.ResFind PrivateEye

What gets set is this :-

*show privat*
PrivateEye$DALimit : 0
PrivateEye$Dir : ADFS::Titan4.$.Utilities.!PrivatEye
PrivatEye$Dir : ADFS::Titan4.$.Utilities.!PrivatEye
PrivatEyeRes$Dir : ADFS::Titan4.$.Utilities.!PrivatEye.Resources.UK
PrivatEyeRes$Path : ADFS::Titan4.$.Utilities.!PrivatEye.Resources.UK.,ADFS::Titan4.$.Utilities.!PrivatEye.Resources.,ADFS::Titan4.$.Utilities.!PrivatEye.
*

Privat v Private that is. The argument on the end of the ResFind call has got lost.

This bodge in !Run ducks the issue for now.

Run <PrivateEye$Dir>.Resources.ResFind PrivateEye

Set PrivateEyeRes$Path <PrivatEyeRes$Path>

And hopefully this fixes the problem that Juile was trying to fix.

PrivatEye fails

As it turns out the issue had already been fixed, but elsewhere.

PrivatEye comes with ResFind 2.20 which falls into the newly discovered hole exposed by the 24Jan21 ROM. ResFind 4.00, as used by StrongED at !StrongED.Tools.ResFind, does use OS_ReadArgs so might do better, and it does, PrivatEye runs again.

To be fair, it is dealing with tasknames, which CAN contain spaces, unlike Julie’s pathnames!

Which should therefore be quoted on the command line, so you need to parse the spaces and quotes (such that spaces are separators, unless they’re within a quoted string). Parsing command lines isn’t simple, which is why we have reusable libraries… and OS_ReadArgs…

ResFind 4.00, as used by StrongED at !StrongED.Tools.ResFind, does use OS_ReadArgs so might do better, and it does, PrivatEye runs again.

Well, that’s rather fortuitous as I only used OS_ReadArgs because I found it neater than parsing the command tail manually as the original code was doing. Nice to know that it actually turned out to be a real improvement.

Thanks David, that brought a nice little smile on what was a somewhat gloomy day (the 25th) – Mom turning 80 but due to the restrictions there was no party to be had.

rather fortuitous

A search here did not find any other instances of old version 2 ResFinds failing. PrivatEye is exceptional in that the Resources Dir and Path names are different from the app name. Mostly they are the same, which is just as well as the old ResFind does not find its name argument. It ‘gets away’ with it which is not the same as good practice.

My TaskCheck utillity was amongst a number of programs which failed when Julie Stamp changed FileSwitch to get-rid of the theoretically unnecessary quotes around filenames returned by OS_GetEnv.

Even though this change has now been reverted to its original behaviour, a new version of TaskCheck which skips over the filenames part, and would therefore work even if the change was reinstated, has been devised.

TaskCheck 0.04 is now available to download from here

As Pic_Index uses the utility, I have updated the current download, 1.24d, available from here

We might as well have it right! If you want to future-proof a bit, download the latest!