Open stevesims opened 7 months ago
key matching, whether that is for *show
or *echo
, is case insensitive, and supports wildcards (#
for single characters, and *
for multiple characters)
when using *show
all keys that match the pattern will be shown, so for instance *show s*a*th
on a freshly booted RO3 emulator will show Serial$Path(Macro)
, SharedCLibrary$Path
and Switcher$Path
. *show s#s$time
shows Sys$Time
, and so on
*
will match zero or more characters, #
explicitly is any single character. a pattern string can have multiple wildcards, and the matching works as one might expect. *show *at#f*a#
will for instance match Sys$DateFormat
with *echo
only the first matching key will be shown/used.
some info on the different variable types that RISC OS understands can be seen here: https://www.riscosopen.org/wiki/documentation/show/System%20Variables#type https://www.riscosopen.org/wiki/documentation/show/OS_ReadVarVal%20Variable%20Types
as can be seen, something like Sys$Time
is a "machine code" variable - which is what we'd use to expose sysvars
we should probably follow Acorn's lead, and broadly follow their APIs - altho for now most likely omit support for "expressions", as for instance provided via *seteval
. initially we may also omit integer variables, as well as "expanded" (those sent to OS_EvaluateExpression). expression handling does not seem overly complicated, but is probably not worth adding initially - it can be a future expansion
I think that pattern matching for system variables should work the same as pattern matching for filenames (as used in filing system commands). we might be able to re-use pre-existing pattern matching code - or at least use pre-existing code as a starting point
It should be noted that RISC OS's system variables were essentially a feature inherited from PANOS, the operating system they wrote for their 32016 second processor for the BBC Micro, and the Acorn Cambridge Workstation.
For some further context see the PANOS Guide to Operations manual: http://chrisacorns.computinghistory.org.uk/docs/Acorn/Sci/AcornScientific_GuideToOperations.pdf
We currently have an expanding number of things within MOS where strings of text are stored (e.g. command history, hotkeys), and we have a growing number of pieces of system information that can be set or read (keyboard type, time, etc). Future expansions to this may be providing a mechanism to change the current command prompt, and to adjust the search path used when running commands.
It would be good to expose these pieces of information in a more convenient way.
On the Archimedes, Acorn added system variables to accomplish this. For instance, a function key definition for F1 is found in a system variable named
Key$1
, the CLI prompt is in a variable namedCLI$Prompt
. Lots of other information is also made available via system variables, which allows for some potentially sophisticated scripting options and system control.This system for instance means that F1 can be set in two different ways:
*key 1 Foo
or*set Key$1 Foo
- both commands have exactly the same effect. Arguably the former is there for convenience, and/or backward compatibility with older Acorn systems.Additionally these variables could be macros. Setting the CLI prompt to show the time before a star can be done using the following command:
(You can even use
setmacro
to set a function key to have a string that includes system variables.)Viewing variables/macros is done via
*show
. Using*show
with no arguments will show all of the current variables. It can also be used with a single argument to show a specific variable, or an argument with a wildcard to show any/all that match.It is suggested that we should implement a very similar system on Agon MOS.
Once these variables are in place, we can look to implement other features that can make use of them. An
echo
command for instance that interpolates in variables into its output. There are lots of possibilitiesInformation on Acorn's system can be found here: http://www.riscos.com/support/developers/prm/systemvars.html