Is 'bash' the Chicken or the Egg?

@ David J Ruck

@Paolo I’ve rebuilt GraphTask, and put it on the ARM Club website so please give it a try now.

On it David, will let you know soon, firing up all my boards now it’s finally weekend!!!! :D

Everything in C on there should have been rebuilt in 2020 or 2021, but I haven’t updated any version numbers at this stage.

Nice! :)

@ David J Ruck

Ok, I ran few tests with RISC OS 5.28 on the following boards:

• Iyonix
• RPi 3B+
• RPi 400
• mini.m
• Panda Board

GraphTask seems to be working fine on all of them and the error is gone.

All Demos runs well except the demos in the directory “Mode 7”, which, even following the instructions, gives always the same error when trying to load a Mode 7 in GraphTask (on all the boards):

“Cannot open <7> for I/O redirection”

Also, quick side note:

When tested it on my Iyonix (which is also my Access/Access+ fileserver), Access/Access+ started to go a little funky. On the clients side, when trying to open a file on a shared disc, Filer reported “it’s not a file” error.

This has happened on multiple clients so far. Not sure if it’s related to !GraphTask (need more tests to be sure), however rebooting the Iyonix solved the issue. It started after testing the new !GraphTask and it has never happened before, so I though was worth mentioning it.

NAFF for example

Does that mean that I ought to describe myself as naff?

Somehow…..that just doesn’t quite seem right. 😂

That said, there is of course a more plausible non-rude interpretation: https://www.worldwidewords.org/qa/qa-naf1.htm

(as well as fuel for the fire that everything can be rude if you try)

That said, there is of course a more plausible non-rude interpretation: https://www.worldwidewords.org/qa/qa-naf1.htm

Which actually, after a bit of vagueness¹, loops back to Polari.
The confusion about showmans private language or homosexual community language (GAY is part of that) set me wondering whether our resident WordHound had info on which came first. Then realised that !WordHound was on topic for these forums, if not actually this thread.

¹ Vagueness and misattribution? See Aldershot Misattribution?

GraphTask seems to be working fine on all of them and the error is gone.

Will the “new” GraphTask be made available or is it something users can fix?

I started GraphTask 4.03 just now and the error didn’t pop up! I would’ve sworn that it “always does”.
I have been cleaning things up, garbage collection, old file deletions, trying to make more free space on the 2GB SDFS disk.
I also did a CloneDisk of SDFS::0 from a 32GB SD to a 2GB SD card. Not saying it’s related but, I no longer get the error when starting GraphTask while running from the 2GB card.

@ Phillip

Hearing that a fatal error is gone is good news. Did you figure out the specific cause of the error? Researching the elements of the stack trace dump is still outside of my available reference materials.

Yes when you read in the error message “Illegal Instruction” it’s almost certainly that the binary was compiled for an ARM architecture that had an instruction that is no longer supported on the ARM chip you’re running the application on.

This can happen if the binary was compiled with an old compiler or compiled for a different target CPU or if the Assembly was written for a different target CPU.

Will the “new” GraphTask be made available or is it something users can fix?

David already made it available to everyone publicly and posted the link on his previous posts, I think it has got hidden from the ongoing off-topic discussion about acronyms, lol get used to the creativity and the constant going off topic of the lovely RISC OS community :D

Link here again for you:
http://www.armclub.org.uk/free

Also on that page you’ll find a lot of very good and useful tools for coding on RISC OS ;)

Thanks to David J Ruck for fixing this quickly!

I started GraphTask 4.03 just now and the error didn’t pop up! I would’ve sworn that it “always does”.

The illegal instruction will always pop up if the code containing it is executed on the wrong target, most likely refreshing your SD has restored a version that did not have the issue (David also said he had a version that did not have the problem). The version with the issue was the one downloadable from the armclub I think.

I also did a CloneDisk of SDFS::0 from a 32GB SD to a 2GB SD card. Not saying it’s related but, I no longer get the error when starting GraphTask while running from the 2GB card.

Typical actually :) RISC OS is a very open OS, so everyone can do everything to it. If you keep your !Boot clean (or only install on it very well tested and solid modules and resources), RISC OS behaves generally fine. This is a big generalisation TBH, because you could still install software somewhere else on the SD that loads stuff on boot process that makes the system a little funky, but I did not want to write an essay here on how to keep your RISC OS stable (so just limited my answer to the very minimal to keep in check).

Link here again for you:
http://www.armclub.org.uk/free

Somewhat confusingly, the GraphTask link on that pages advertises the utility with a version and date of “4.03 (06-Feb-2009) [32bit]”

Somewhat confusingly, the GraphTask link on that pages advertises the utility with a version and date of “4.03 (06-Feb-2009) [32bit]”

Yup… I was actually about to comment and ask David if it isn’t the case maybe to just bump up the release number or at least the build date?

I was actually about to comment and ask David if it isn’t the case maybe to just bump up the release number or at least the build date?

I’ve checked. The download has a !RunImage fie date of 2021-01-14

This can happen if the binary was compiled with an old compiler or compiled for a different target CPU or if the Assembly was written for a different target CPU.

This is the issue I spoke of earlier regarding listing the system requirements in Packman or Store. A new user is unlikely to have a thorough knowledge of past CPUs and platforms but, with a “Works on RPIx y z” flag it is much less likely they will break their system or their spirit to pursue RiscOS.

I did not want to write an essay here on how to keep your RISC OS stable

A nuts and bolts tutorial on the subject may be very helpful to me and others. I’ve noticed the newer users to the forum are at least technical enough to experiment with “other” OSs. While I’m glad that my system appears more predictable, I can’t be sure of what I did to achieve it is repeatable so, very little knowledge gained in the experience.

Somewhat confusingly, the GraphTask link on that pages advertises the utility with a version and date of “4.03 (06-Feb-2009) [32bit]”

When I noticed this, I decided to hold off on the upgrade but I did spend quite some time reading archived magazine articles. Added the site to my hotlist. I’ll continue to follow the GraphTask mystery and look for the update to be Packman.

The illegal instruction will always pop up if the code containing it is executed on the wrong target, most likely refreshing your SD has restored a version that did not have the issue (David also said he had a version that did not have the problem). The version with the issue was the one downloadable from the armclub I think.

This adds to the mystery of the error because I did not update the existing app. I made room on the system disk by deleting collected gems in the download folder “most all was documentation”. The disc refresh was a clone of the running system that displays the error so, there wouldn’t have been any change in the version “or anything really”.

you could still install software somewhere else on the SD that loads stuff on boot process that makes the system a little funky

Remember the DLL Hell that MS unleashed on its user base? Are we talking about going through that again? Not complaining, just expressing my terror!

As a recompile of GraphTask seems to have fixed the problem, I’ve up issued the version number to 4.04 so it’s easier to tell if you have the new one.

@Paolo I’ve not managed to reproduce any problems with the Mode 7 demos on my Pi4. They obey set the run type to change to mode 7, print the file, and cancel teletext effects. It looks like on your machine the Echo |<22>|<7> is being interpreted as trying to redirect to a file, which is puzzling.

I’ve not seen the “not a file” error either, you weren’t trying to run it from an archive in the access folder? That often causes problems.

@Paolo you aren’t using the CObey module are you? Just saw it was having some problems with Echo, which may explain the above.

I hope it isn’t?!

It looks like on your machine the Echo |<22>|<7> is being interpreted as trying to redirect to a file, which is puzzling.

The culprit is probably GNU core utils. Try:

*Show alias$echo

Sorry guys, had a couple of crazy busy days at work…

@ David J Ruck

I’ve not seen the “not a file” error either, you weren’t trying to run it from an archive in the access folder? That often causes problems.

Confirmed, it was caused by other software loaded, so no problem with GraphTask, thanks!

@Paolo I’ve not managed to reproduce any problems with the Mode 7 demos on my Pi4.

I did some digging and it’s caused by CoreUtils so no issue from GraphTask

@ edwardx

The culprit is probably GNU core utils.

Yup found that yesterday… also JFYI CoreUtils (indirectly) causes problems with DDE as well:

• Touch is also a BASIC program used in DDE Shared MakeFiles
• chmod same
• link same

To fix that all one needs to do is to add such paths in DDE stdTools in AcornC/C++ → Makefiles → StdTools

Here is what I do:

Add the following variable:

BASEDIR        = <SetPaths$Dir>.Lib32

And then for the lines that defines the commands above:

LD             = ${BASEDIR}.link

same for touch and chmod

To make GraphTask mode 7 works fine and potentially other things I just created a new utility called !StartBash, when running it, it does all the filler look for CoreUtils and !Bash etc… it also opens a TaskWindow with WimpSlot -min 16384K so can run GCC from bash without any issues and ld as well etc.

Will publish the utility ASAP, most likely this weekend.

Thanks

With the linux echo command in CoreUtils a command to set Mode 7 is:-

echo -e \x16\x07

Tested in GraphTest and RISC OS outside of the Desktop.

I was enjoying playing with !Bash with !CoreUtils until I tried to update one of my websites with SiteMatch. It seems that Unix and RISC OS don’t always play nicely together.

You can get the same effect on any OS when you load a utility that aliases a core command to its own version.

I was enjoying playing with !Bash with !CoreUtils until I tried to update one of my websites with SiteMatch. It seems that Unix and RISC OS don’t always play nicely together.

All the commands in CoreUtils are aliases. To stop RISC OS using an alias just prefix the command with ‘%’. e.g.,

*%sort

All the commands in CoreUtils are aliases. To stop RISC OS using an alias just prefix the command with ‘%’. e.g.,

*%sort

Thanks Chris,
I can fix my copy and let Richard Porter know.

All the commands in CoreUtils are aliases. To stop RISC OS using an alias just prefix the command with ‘%’. e.g.,

Interesting answer, but shouldn’t CoreUtils be producing a set of command names that are distinct from the OS resident commands? Like perhaps CUSort?

John has (confusingly) raised another thread titled Mixing with the wrong sort about this, to which I replied. Having a solution which requires a change to all applications using the official ArmSort command *sort is not really practical, is it?

@ Steve Pampling

Interesting answer, but shouldn’t CoreUtils be producing a set of command names that are distinct from the OS resident commands? Like perhaps CUSort?

Bash + CoreUtils are clearly to have a Linux CLI on RISC OS, so they are useful for porting Unix software to RISC OS or to users that are more familiar with Linux than with RISC OS CLI.

CUSort would not help in either of the use cases above. My recommendation is, if one has none of the use cases above, to not use Bash + CoreUtils on RISC OS. And, if one really want to use them, they should avoid the “Look at” at boot and limit it only when they want to use Bash+CoreUtils.

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.

P.S. in general Apps should probably use %{command} anyway to avoid problems with any form of aliases (think of it as a secure measure too…)

just my 0.5c