SideDiff & 17/01/21 ROM

The !Boot obey file in SideDiff is tripping up with an ‘Unknown operand’ error with today’s ROM for the BeagleBoard.

SideDiff v 2.44 5/9/2005

The error happens on the penultimate line,

If "<Alias$@LoadType_FD1>"="" Then Set Alias$@LoadType_FD1 @LoadType_FFB %%*

but you can strip it down to

*Set A |"%0
*If "<A>"="" Then Echo
Unknown operand

The error happens on this ROM because it sets

Alias@LoadType_FD1 : Basic -load |"%0|" %*1

by default.

Does anybody know a reliable way to test if a variable is set?

The !Boot obey file in SideDiff is tripping up with an ‘Unknown operand’ error with today’s ROM for the BeagleBoard.

Bottom two lines are giving the error – also on RPCEmu so it’s across the board(all boards) in all likelihood.

If "<Alias$@LoadType_FD1>"="" Then Set Alias$@LoadType_FD1 @LoadType_FFB %%*0
If "<Alias$@RunType_FD1>"="" Then Set Alias$@RunType_FD1 @RunType_FFB %%*0

The thing is that the LoadType and RunType aren’t null strings, so that shouldn’t actually trigger, should it?

The error happens on the penultimate line

both penultimate and ultimate

Does anybody know a reliable way to test if a variable is set?

You mean manually?
echo <Alias$@LoadType_FD1>

I mean in an obey file, how can those two lines be fixed? They are meant to test whether the variables are set, but that doesn’t work for some string values, so is there a way to do it that works for all values?

Does anybody know a reliable way to test if a variable is set?

The canonical method is to call XOS_ReadVarVal with R2 bit 31 set (this will return zero in R2 if the system variable does not exist). You’d need to write a small piece of (e.g.) BASIC to do it from an Obey file, though.

Hmm. Why do the BASIC associations have |“%0|” for the filename bit anyway? We know that it can’t contain spaces.

I think the origin of the problem is the behaviour of the Obey module.
It expands the Alias before doing the comparison with the null length string in a test that’s only intended to check whether the alias actually exists.

As you’ve noted the expanded alias has values that break the comparison, IIRC there’s a means of stopping the alias string being expanded which would be one way of avoiding the break.
The other would be if there was an IFEXIST/IFNOTEXIST for variables in Obey.

Both of course mean that a fix still requires a change to the actual affected Obey file.

Or change the ROM so that it doesn’t have |“%0|”

And yes, *IfExist would be good. But would have to be part of !Boot for older systems.

And yes, *IfExist would be good. But would have to be part of !Boot for older systems.

That would be an addition to this download then

Edit: Stuart, you’re right on both points

1. ROM change to remove the nonsense
2. Obey module additional feature

I’d like to be able to write things like

*If varSet(Alias$@RunType_FFB) Then Echo
*If objThere("ADFS:$.Fred") Then Echo

I wonder if there’s a way to extend OS_EvaluateExpression to make that work?

That has a lot going for it, Julie. Use Sys$ReturnCode. They’d have to be Utility commands I think.

*If varSet(Alias$@RunType_FFB) Then Echo

The thing is, this really ought to work…

*If "<Alias$@RunType_FFB>" <> "" Then Echo

*If objThere(“ADFS:$.Fred”) Then Echo

I think the logic behind having utilities like IfThere is to try to keep Obey “clean”. It wouldn’t be hard to add extra commands (though potentially dodgy for backwards compatibility), but that’s a slippery slope to a hulking mess.

Wouldn’t it be nice to have labels and be able to test stuff and GOTO ? How about wait for the user to prod a mouse button? Or how about doing something if a module is loaded rather than when it isn’t? Or load a helper, but only on a Saturday…
All of the above can be done with some convoluted logic, but hey, why don’t we just add some extra code into Obey to do it for us. Oh, and since you’ve written it in C, should make it easy to link in wget so Obey can handle fetching stuff as well.

Hyperbole, but you get the point, I hope.

The thing is, this really ought to work…
If “<Alias$@RunType_FFB>” <> "" Then Echo

But I suspect that falls over in the same manner when Obey expands the Alias

Alias$@RunType_FD1 to this: Basic -quit |"%0|" %*1 ready to do the comparison with the null length string

Hyperbole, but you get the point, I hope.

Yes, you’re on the if it ain’t broke don’t fix it train.

The problem is that people are trying to get an effect (if exist) from a comparison which has an inherent flaw. I’m sure the flaw has been there a long time and people have probably noticed, grumbled quietly and tried to work round it.

Oh, BTW.

Or how about doing something if a module is loaded rather than when it isn’t?

RMEnsure

Hyperbole, but you get the point, I hope.

Don’t worry, I don’t expect this would involve changing Obey. *Eval already allows you to sort-of use functions in the form of code variables, but you can’t pass arguments to code variables¹. So I’m thinking about ways to introduce functions with arguments into OS_EvaluateExpression.

I just had a look at the Select PRM’s, and found this for OS_EvaluateExpression, much to my surprise…

  SET
     Returns boolean value of whether a system variable is set, -1
     if set, 0 if not set.
     Example:       SET "Not$Set"
     Evaluates to:  0

There are several other useful functions built in as well.

¹ I guess you have to use assembler for code variables, so this could be an opportunity to look at alternatives.

(Non programmer interrupts) So it’s an OS issue(?)… or should Harriet Bazley be informed?

Yes, you’re on the if it ain’t broke don’t fix it train.

More like the KISS train.

ready to do the comparison with the null length string

So, does this mean that any expansion that contains quotes would fail?

RMEnsure

Which evaluates the clause if the module is not present (or too old). Can be used in a convoluted way by setting a flag and then unsetting it if the module isn’t present, to then check to see if the flag is set.

(Non programmer interrupts) So it’s an OS issue(?)… or should Harriet Bazley be informed?

It is an OS issue, and I’ve submitted a patch for it. Until it’s fixed you can comment out the lines from the !Boot with |’s, or remove them.

So, does this mean that any expansion that contains quotes would fail?

The way I understand it, when your Obey file mentions <Alias$@RunType_FD1> it expands that to Basic -quit |"%0|" %*1
and the %0 and %*1 are what exactly at that time? and thus what exactly is the string that is being compared to "" ? and does that string contain "’s
My little non-programmer brain is frazzled.

Which evaluates the clause if the module is not present (or too old). Can be used in a convoluted way by setting a flag and then unsetting it if the module isn’t present, to then check to see if the flag is set.

Looking at the Select docs, you could do

If MODULEVERSION "UtilityModule" < 0 Then Echo Module not preset Else Module present

and the %0 and %*1 are what exactly at that time?

Nothing, we’re only testing whether that string is zero-length, we don’t do any replacing of %’s.

It goes

If "<Alias$@RunType_FD1>" = "" Then ...
If "Basic -quit "%0" %*1" = "" Then ...

But on the left of the equals is

"Basic -quit "%0" %*1"

which isn’t a valid expression (as far as *Eval is concerned, it’s two strings separated by gobbledeegook), so it goes No.

which isn’t a valid expression (as far as *Eval is concerned, it’s two strings separated by gobbledeegook),

I’d just got my head to the “string” %0 “string” bit, at which point the answer to Ricks question is pretty much “Yes” unless by some chance you have something valid for joining two strings

so it goes No.

As in “computer says No”

Whilst this was triggered by my change, OS_EvaluateExpression is clearly broken, PRM Volume 1 page 458 states:

Any strings in the evaluation string are passed to OS_GSTrans, so all its operators will
be used. This of course means that OS_ReadUnsigned and OS_ReadVarVal will in turn
be called if you use a string that requires them. Note, however, that vertical bar escape
sequences (eg ‘|G’ for ASCII 7) are not recognised.

As well as passing operators in strings to OS_ReadVarVal, any item which
cannot immediately be treated as a string or a number is also looked up as a system
variable. For example, in the expression FRED+1, FRED will be looked up as a
variable.

No mention of applying GSTrans before parsing the expression, which allow shenanigans such as:

*Set password "|" = |"|" OR |""
*
*Eval "<password>" = "Secret"
Result is an integer, value : -1
*If "<password>" = "Secret" Then Echo Allowed Else Echo Denied
Allowed

If you use the bare system variable name it works correctly for existing variables:

*Set password "|" = |"|" OR |""
*
*Eval password = "Secret"
Result is an integer, value : 0
*If password = "Secret" Then Echo Allowed Else Echo Denied
Denied

Unfortunately that doesn’t work for non-existent variables.

If I understand all this (I don’t) it seems to step from the runtype variable being created with 4 quotes, intended to act as nested quotes, but being evaluated as separate quoted strings. Or possibly the opposite.

WHY???

WHY???

Because Acorn did something broken and no one discovered it (and notified anyone else) before

It’s there all the way back in RISC OS 2, and maybe before. I must have put that particular alias setting in FileSwitch in 1986 or 87, but am pretty sure that I wouldn’t have put the separate quoted filename argument like that unless someone else specifically requested it (compare with all the other ones thereabouts in FileSwBody). Alas, that’s shrouded in the mists of time… (I do think that it ought not to have quotes now and software authors need to fix any of their borked BASIC command line parsers. Use OS_ReadArgs. You know it makes sense.)