BASIC Problem

I have been trying to re-acquaint myself with files in BASIC. I’ve tried to do the following to write the content of TIME$ to a file, but it consistantly crashes RPCEmu.

filename$=“HostFS::$.Test”
file%=OPENOUT
BPUT#file%,TIME$
CLOSE#file%

(LINUX, RPCEmu 0.8.11, RISC OS 5.21(10/12/13)

It’s fine with the filename Test, but when I use a full path or set and use a an environment file such as <Test$Dir> it crashes RPCEmu. I presume if you could not use full pathnames, very little would run on the emulator, so what am I doing wrong? There is no existing file called test.

Cheers.

Assuming you actually mean ‘file%=OPENOUT filename$’… try using one colon, i.e.

filename$=“HostFS:$.Test”

The way RPCEmu objects to the double colon is a bit dramatic…

so what am I doing wrong?

One colon too many in the path. It’s “HostFS:$.Test” you need.
Spotted with the left eye¹ :-)
Actually that single colon rather than two is something I noted a while back²
adfs:: , pipe: , hostfs:

¹ As opposed to the shortsighted right with a proto-cataract

² Twiddling with blackhole and looking at what caused the base over apexness.

Ah brilliant, mystery solved. Thanks guys.

Actually that single colon rather than two is something I noted a while back

It’s because it’s using a disc name:
adfs:$.Foo is fine
:HardDisc4.$ is fine
adfs::HardDisc4.$.Foo puts them together

pipe: and hostfs: don’t have disc names and the disc name is what’s preceded by the colon.

To expand on Theo’s post – a disc specifier of any form, be it a name (IDEFS::Kyoko.$) or a drive specifier (IDEFS::4.$).

Just be aware that you are using a device specifier (HostFS, xxxFS…) with a single colon and a path following will actually be telling RISC OS to “look for this path on the currently selected disc on this device”. This will usually work with specific devices that don’t have a concept of multiple discs (RAMFS, HostFS, and the internal services that aren’t really an FS (pipe, vdu, serial…)).
It isn’t so wise to rely upon this doing what you expect¹ on devices that do support multiple discs (ADFS, SCSIFS, IDEFS, etc).

¹ Back in the Dark Ages, there was a game that loaded itself from floppy disc and kept referring to itself as adfs:$.blahblah – which stopped working as soon as I got a machine where the harddisc was ADFS drive :4 and the default. I copied the game to harddisc, but it refused to run except from floppy. A bit of fiddling with the Debugger² soon fixed that nonsense. ;-)

² Either I didn’t know about Zap, or this predated Zap. Heck, I was still going on-line with !ZANSI before I wrote my own terminal (in BASIC!) and, finally, plumped for Hearsay because of decent (read: working (!)) Zmodem (unlike my attempt…in BASIC).

This will usually work with specific devices that don’t have a concept of multiple discs (RAMFS, HostFS, and the internal services that aren’t really an FS (pipe, vdu, serial…)).
It isn’t so wise to rely upon this doing what you expect1 on devices that do support multiple discs (ADFS, SCSIFS, IDEFS, etc).

I had a half formed question last night and then reasoned that things would be iffy if you didn’t specify which disc you wanted on a multiple disc interface, but also reasoned it would use the current device – which might not be what you intended

I copied the game to harddisc, but it refused to run except from floppy. A bit of fiddling with the Debugger2 soon fixed that nonsense. ;-)

Yeah, done a bit of editing to correct things including tacky “protection”.