Loops in Obey Files

It would be handy to be able to code loops inside an Obey file. I did look around to see if this was already supported but couldn’t find anything. I wonder if you could achieve the same effect by having an Obey file run itself recursively, passing in a count of how many times are left to run it, decrementing it, and stopping when it reaches zero.

I’m not sure what the advantage would be over the Obey file calling a wee BASIC program, that could do whatever else you wanted to do in the Obey file, and in which loops (and whatever else) would be no problem?

Yes you’re right that BASIC is the obvious and very powerful solution for scripting on our machines. I suppose I just feel like Obey files can already do a lot and a couple of extra features like loops would make them even more capable and a little closer in functionality to things like Linux shell scripts.

Hmmm, even MS-DOS batch files supported looping (by abusing GOTO). ;)

But, it’s perhaps worth pointing out that Obey files (currently) aren’t fault tolerant. If there’s an error, everything will grind to a crashing halt. The current hack workaround is to have a command called ‘x’ that does what is wanted and discards any error state.
Would perhaps be useful, if modifying Obey, to have an option to set Obey$ErrorNum / Obey$ErrorMsg and allow it to be checked later, rather than just blowing up.

Hmmm, even MS-DOS batch files supported looping

But then A Mess DOS didn’t have a built-in, always-available equivalent of RISCOS’s BASIC.

But then A Mess

I said it could do it. I didn’t say it was good (actually, I did reference the abuse if GOTO).

DOS didn’t have a built-in, always-available equivalent of RISCOS’s BASIC.

<cough> QBASIC </cough>

That’s actually what got me started with C, fiddling around with TurboPascal, because QBASIC was really rather awful.

Actually, I swiped TurboPascal from the college server, but found it mildly unpleasant ¹ as it seemed to be as much trying to make a point as being a language. It amused me that Borland had to bastardise it greatly in order that it be capable of actually doing stuff.
But it was a useful exercise in learning how to make programs modular. BASIC’s LIBRARY just isn’t the same, and the variable scope rules are amazingly different (and actually logical at that!).

So when my A5000 that I bought second hand came with Cv4, I had some idea of what C was about (namely Pascal without the stick up its arse). It took a while to get used to C even so, because coming from BASIC some parts are mindscrewey. Entire books have been written on the subject of pointers, for instance. There’s a lot of clever stuff one can do, and equally much clever stuff one probably shouldn’t ever do (the language is totally okay with indirections off of negative array subscripts), not to mention the ‘.’ and ‘->’ difference.

Anyway, via a torturous route, one can trace my use of C in RISC OS back to how awful QBASIC was on DOS, and my wanting to look for something better.

I don’t think too much should be done to Obey. It’s not a shell in the Unix sense. However simple loops (or maybe just named jumps) would be good, as well as treating errors as not the end of the world, so the Obey file could then programatically handle them. Take a look at some larger resource heavy apps and marvel at the hoops the author jumped through in order to check and test in a way that wouldn’t upset things and throw an error.

¹ As in mount it’s head on a pole and then set the whole thing on fire. Still far better than QBASIC, mind you. ;)

DOS didn’t have a built-in, always-available equivalent of RISCOS’s BASIC.

QBASIC

That’s actually what got me started with C, fiddling around with TurboPascal, because QBASIC was really rather awful.

Until you wrote that last bit, I was about to recommend a visit to your local mental health facility, and you totally redeemed yourself with the footnote.

Is QBASIC actually built-in and always available in A Mess DOS? If so, was it always? Shows you how little interest I ever took in PCs…before the BBC, we had Exidy Sorcerers running CPM at Shipley College…how A Mess DOS edged CPM out, I’ll never understand. Well, I do really: never mind the quality, feel the marketing…

GW Basic in the earlier stuff certainly.
That rather naff thing was what Mr. Gates actually wrote (so the story goes) and DOS was an acquired item because he realised that IBM didn’t know he didn’t have an OS and that was what they actually wanted.

Wouldn’t adding to Julies CObey be the thing to do though? If you wanted additional features, that is.

Taken to Aldershot.

I found myself wishing, just a few days ago, that Obey files could have loops.

My use case is that I can mount a share via either LanMan or LanMan98, but they result in two different paths. I call an Obey file to mount the share (I sometimes edit the Obey file to try the other one). It returns immediately, but the share is not yet mounted, so any attempt to access a file results in an error of course. If I could loop in an Obey file, I could waste time while multi-tasking and loop back until the share is mounted.

I could do the whole thing in BASIC, but it would be rather specific to the application, so a looping Obey file would be a simpler and neater solution.

It would be handy to be able to code loops inside an Obey file.

You actually can loop in obey files. I have created a “looper” as a script that one can call to loop through things.

Here is the sources on the riscoscommunity on github:
https://github.com/RISC-OS-Community/ROCUtils/blob/develop/src/ObeyLooper/ObeyLooper%2Cfeb

Some tests here to see how to use it:
https://github.com/RISC-OS-Community/ROCUtils/tree/develop/src/ObeyLooper/tests

Hope this helps,

P.S. ObeyLooper also allow the creation of nested loops

Multi-line IF statements anyone?

From memory Obey performs some interesting tricks around environment handlers so it can intercept errors. It wouldn’t surprise if that breaks horribly when using recursive Obey files to emulate loops, possibly leaking RMA if an error occurs within a recursive Obey. That said I seem to recall it keeps a linked list so it can clean up so it might be okay.

I have created a “looper” as a script that one can call to loop through things.

Nice work! I wanted to experiment with the recursive approach but you’ve just saved me the time and I don’t think I would’ve ever ended up with something so functional.

It wouldn’t surprise if that breaks horribly when using recursive Obey files to emulate loops

Oh.

@ Jon

It wouldn’t surprise if that breaks horribly when using recursive Obey files to emulate loops

Thanks for your suggestion! :) – I have added a test that generates an error in the BASIC tok1 file, to check what happens.

Execution stops at the error, which is good, so no damage is done by the loop. I need to check if there is any RMA leakage, but by a quick look there seems to be no issues (however more testing is needed)

Thanks againg and if others have ideas or tests to run please let me know :)

New test is available in the repository linked on my original post (above).

Cheers

I’m not sure what the advantage would be over the Obey file calling a wee BASIC program, that could do whatever else you wanted to do in the Obey file, and in which loops (and whatever else) would be no problem?

Or, forget having an ‘obey’ file. Just use BASIC. In it’s simplest form, an obey file is a text file which is interpreted – just like BASIC.

Or, forget having an ‘obey’ file. Just use BASIC.

I’m not at the Pi at the moment, so I can’t check – but doesn’t the OS expect to find !Boot and !Run in !xxxx applications directories, and doesn’t it expect them to be Obey files? Can they be BASIC? If so, I never knew that! Quite handy to set up a few things before the main BASIC program starts anyway, so I’d generally be chaining one BASIC program from the other anyway, but if the main program wasn’t in BASIC, I can see the advantage of chaining a C (or other) program from BASIC.

but doesn’t the OS expect to find !Boot and !Run in !xxxx applications directories, and doesn’t it expect them to be Obey files?

No, and no. It will act upon !Boot, !Run, !Help and !Sprites files (plus treat !RunImage as “special” for some limited things), but they don’t have to be there.

The first three don’t have to be Obey files, either: they can be any executable type. I use BASIC for the !Help in my applications, for example, for more or less this reason.

However, there has long been concern that this is the case, particularly for !Boot and, maybe to a lesser extent, !Run (and IIRC there was some tutting about my use of !Help back in the ROL days). The Filer will run every Boot file that it finds when folders are opened, so allowing any executable type here is arguably quite a brave design decision.

Personally, I’d probably stick with Obey files for !Boot and !Run, and use them to chain small utilities if required along the way. It feels more “correct”, and – given the number of times that “make !Boot have to be an Obey file” comes up as a discussion – it also feels more “future proof”.

No, and no. It will act upon !Boot, !Run, !Help and !Sprites files (plus treat !RunImage as “special” for some limited things), but they don’t have to be there.

!Run has to be there, does it not? Otherwise it won’t know what to do when you double-click on the app.

I knew you could omit !Help (often simply a text file in my apps) and !Sprites (although blank iconbar icons are a bit odd!) but it never occurred to me to omit !Boot or !Run 8~)

The only disadvantage I have found using a !Run file which is BASIC (and is in itself the main program) is that Obey$Dir is not set (and that can set at the start of the BASIC).

Otherwise, an application can just consist of one BASIC file named !Run.

Also, if you omit !Boot, the OS will also do a *iconsprites !Sprites for you. When a !Boot file is included it is expected that you do this yourself as you may wish to load in different ones depending on a condition or have them in a non-standard location.

AFAIK, the only “required” file is !Run and only if one wants to double click on an !App.

If one wants to use BASIC (or Lua, or any other language) instead, that is totally possible as long as such language has a Run_file defined and the interpreter is reachable by the Filer or is a module loaded in memory.

The replacement language interpreter should be a Module so, if scripts call for an executable (given we are in single task land), things won’t go wrong.

is arguably quite a brave design decision

I don’t think it’s a design decision so much as a design omission.

The OS will run a file according to some predefined rules depending on type. The Filer will run certain files at certain times.
You could probably even set !Run to be an Impression or Ovation file, as long as something knew what to do with it…

Remember, this comes from an earlier more innocent time when an unvetted SWI to give any code complete kernel level access and putting network passwords on the wire in cleartext were both not considered world ending things.

!Run has to be there, does it not?

For an app, yes.

occurred to me to omit !Boot or !Run 8~)

Whether or not I use Boot depends on whether I need anything done when the app is first seen.

is that Obey$Dir is not set (and that can set at the start of the BASIC).

All the Obey module does is strip the path from the filespec passed to the *Obey command.
You could determine the location of the BASIC program using OS_GetEnv and parsing it out of the command used to run the program.

A potentially more important issue, depending on use case, is that BASIC ¹ has no support for long command lines. Obey… does.

¹ BASIC as in the ROM, not Basalt. ;)

Whether or not I use Boot depends on whether I need anything done when the app is first seen.

Exactly my thinking, unless you want a filetype set or variable set before the app is run then surely !Boot has no purpose