Is 'bash' the Chicken or the Egg?

In a perfect world Bash + CoreUtils should be used in a container, but RISC OS doesn’t yet support such tech, so probably for now it’s best to stick to the above or use the trick suggested by Chris Gransden.

I think you’ve missed the point that I was making, and Martin has amplified:

The OS has a command and every application expects it to respond in a specific way, anything that changes that and causes problems with those applications is broken.

What CoreUtils needs to do is “make its own arrangements” with regard to a command name that does not clash. My suggestion of CUSort was an extremely obvious modification, it could as easily be Xsort.

The OS is a defined API, the likes of CoreUtils should seek to complement and enhance not clash and break.

The OS is a defined API, the likes of CoreUtils should seek to complement and enhance not clash and break.

Exactly. Just imagine the chaos if something else was installed that implemented an *Obey command …but tried to do its own thing. Try changing all uses of *Obey to *%Obey …!

!CoreUtils should only use resources officially allocated for it to use.

Guys I think there is a misunderstanding here…

The way both Steve and Martin are describing the problem is that they are describing a use case where a user would want to use Linux commands in a pure RISC OS and for RISC OS tasks. <— note this is the use case where CoreUtils, as it is right now, break things.

I am sure this particular case is something that others would want too, but I am afraid if the CoreUtils will change the original Linux command names that may not be enough and (at the same time) it would also break Makefiles for ported stuff that have been left unchanged (that’s because of the support for linux commands).

How useful are the Linux commands (left as they are) on RISC OS? This is a different question IMHO. And, given that some of them (bash included) uses a different file system syntax, I’d say they would break the RISC OS model anyway, even when renamed, because, for example, in a script you may end up having things like:

*{original-riscos-command} $.subdir1.subdir2.c.file
*{linux-command} /subdir1/subdir2/file/c

This gets even more tricky when you’ve stored a path in a variable and even using variables (you should use the Do command always before a linux command).

So, it seems that probably a better way would be to create a new library of Linux derived commands (with different names) and that fully embrace the RISC OS model.

Am I correct in my understanding?

I have now found and downloaded !CoreUtils, and I now see how it works. There is a collection of Absolute files – one for each command – and in the !Boot file a collection of

Set Alias$<command> Run <CoreUtils$Dir>.command

After running the !Boot I have checked using ‘which’ to find where each of the commands are now found. Ones currently clashing with my RO5.29 here are:

*echo (213k) overrides that in UtilityModule
The CoreUtils echo seems to ‘work’ … but I suspect with no GSRead!

*md5sum (230k) overrides an Absolute (8k) in my Library
The CoreUtils md5sum seems to ‘work’ … but does not understand all RISC OS filenames.

*sort overrides the ArmSort module command
The CoreUtils sort will not work.

So, it seems to me that even if !CoreUtils has been seen (ie booted) then it has broken 3 commands that I would expect to work.

Imagine the chaos if a popular RISC OS command had been aliased!
Some solution has to be found before this happens … but I am not sure what it should be.

Imagine the chaos if a popular RISC OS command had been aliased!

That problem is not unique to unixlib apps.
This gets back to the argument about unixlib binaries not being 100% adapted for RISC OS.
What should be included is a !Help file explaining that this is a unixlib representation of CoreUtils unmodified, and that some binaries may need to be deleted, renamed or otherwise.
There are many ways to swing the cat. eg use kat or catenate (:
I think any binaries that cause crashes and will never work in RISC OS should be removed from the building in AB though.

@ Martin Avison

Imagine the chaos if a popular RISC OS command had been aliased!

Clearly no one was using CoreUtils (until now lol) :D

Anyway the fix for the aliases is to create the aliases in bash, so only bash will see them.

BUT again this won’t solve the ///// issue (read up for more details)

Anyway the fix for the aliases is to create the aliases in bash

Fine, but the current situation is that Bash is not a dependancy for
running the CoreUtils, they run in the CLI ok.
Using either RISC OS or unixlib shell paths is another way to be more selective.
Unixlib shells might need the alias done repeatedly in scripts, whereas the PATH is global.

An ommision in dash for a few months has been the changing of its’ PATH separator from a colon to a semicolon to allow /ADFS:: type paths to be used.
However while it was broken I did find away to use RISC OS dir variables in PATH, which is a major step forward (avoids relying on hard paths).
I’m told by Alan the update (With improved PATHology) should be available in a day or so.
Still built from the same source version, so look for the extra ‘bin’ directory in the App dir to know it is the latest.
Edit: The new version has moved from 0.5.8-4 to 0.5.8-5 and has been uploaded.

Clearly no one was using CoreUtils (until now lol) :D

Or they were like me. I installed it a couple of years ago, it broke everything, I couldn’t be bothered with figuring out what was wrong, so I removed it again.

*echo (213k) overrides that in UtilityModule

213k to do this?!