ArmSort

I use the ARMSort module (version 4.08) in one of my applications which provides a command ‘sort’ to sort array variables in BASIC. It works excellently.

I have encountered a strange problem – when the ‘sort’ command is issued, my application exits silently. If I add some diagnostics I get the following error:

/SCSI::HardDisc4.$/Utilities/!CoreUtils/sort: cannot read: i%: No such file or directory

If I rename the file $.Utilities.!CoreUtils.sort to sortx I then get

File 'SCSI::HardDisc4.$.Utilities.!CoreUtils.sort' not found

Should I just delete the rogue application $.Utilities.!CoreUtils which is causing the problem? And then recommend users who have picked up this app to delete it?

I could add a command to delete $.Utilities.!CoreUtils to my !Run file.

Alternatively I could add an alias for the sort command to avoid CoreUtils being called? As a temporary measure I have added ‘*unset Alias$sort’ to my Run file.

Surely the sort command is registered to ArmSort?

There are loads of name clashes with established RISC OS utilities when you start installing the *nix-derived packages.

I have to have diffutils installed for dev, which clashes with programs from the DDE, so have had to rename the ‘Acorn’ ones, e.g. cdiff to avoid diff.

It will only get worse :-)

Surely the sort command is registered to ArmSort?

Certainly is … and has been since 2005!
I can see no better solution than unsetting the alias, as Chris suggested.
It is just one of nearly 100 that CoreUtils sets!

I can see no better solution than unsetting the alias, as Chris suggested.

Doing it in the application’s !Run would be the least destructive option.

Might need to put something in the Release Notes so people aren’t puzzled when ‘sort’ no longer works afterwards!

[Edit: Or just invoke ArmSort with *%sort ... to bypass the alias]

Use a CLI command targetted at a specific module, rather than unaliasing or even the bypass of the alias system:

*ARMSort:sort <arguments>

just invoke ArmSort with *%sort … to bypass the alias

Brilliant! Thanks Stuart – I had forgotten about that.

*ARMSort:Sort <arguments>

And that works as well, as gerph points out.

I think extending that to modules was a RISC OS 2-ism I’d forgotten about (Arthur passed commands to filesystems using the prefix).

An excellent set of answers, many thanks. I can confirm that context overriding was included in the RISC OS 2 PRMs. I had not forgotten, just never known that a * command could be limited to a specific module.

The interesting thing about the problem is that the command ‘*sort i% …’ in my application was aliased into a command that would set up a Wimpslot and run an application called ‘sort’ which would terminate using OS_Exit which would silently kill my applicatiob – it would just vanish from the icon bar without generating an error. This was because the error from the application ‘sort’ (cannot read: i%: No such file or directory) was a fatal one.