vanaards@p4.cs.man.ac.uk (Steven van Aardt) (04/24/91)
In the user guide it states that a pseudo filing system can be created using the ':' . Ie you could do *. system: Well I've tried this and it doesn't work. I'd also like to know what you out there understand by 'Hypertext'. Steve. -- --------------------------------------------------------------------------- - JANET E-mail : vanaards@uk.ac.man.cs.p4 (Steven van Aardt) -- -- Warning this user has been designated for termination on the 21.6.91 -- ---------------------------------------------------------------------------
sal1@ukc.ac.uk (S.A.Lockhart) (04/25/91)
In article <vanaards.672489794@p4.cs.man.ac.uk> vanaards@p4.cs.man.ac.uk (Steven van Aardt) writes: > > In the user guide it states that a pseudo filing system can be >created using the ':' . Ie you could do *. system: Well I've tried this >and it doesn't work. What you need to do is set a variable as follows: *set system$path <Path> Then when you refer to system:, the operating system will substitute in the value you put for <Path>. In article <1991Apr23.033416.23230@comp.vuw.ac.nz> jwright@comp.vuw.ac.nz (Julian Wright) writes: >It seems that !Extract wants a module to be present that is not commonly >available at present, if the unknown SWI message I got is anything to go >by. Further investigation into the compacted code reveals that this non- >existant SWI call only gets called if your WIMP has a version number less >than 2.85... Alan Murta replied: >Julian is certainly not alone in having unknown SWI problems with !Extract. >Does anyone know of a fix? If you look in comp.binaries.acorn now, Alan Glover has cancelled the original posting, and has reposted it with this, and several other bugs fixed. Obviously he was using Risc OS 3 (which doesn't exist :-) when he wrote !Extract. -- Simon Lockhart
dhmyrdal@solan.unit.no (Dag H}kon Myrdal) (04/26/91)
In article <vanaards.672489794@p4.cs.man.ac.uk>, vanaards@p4.cs.man.ac.uk (Steven van Aardt) writes: |> |> In the user guide it states that a pseudo filing system can be |> created using the ':' . Ie you could do *. system: Well I've tried this |> and it doesn't work. The whole 'pseudoFS' feature is, according to earlier discussion, only a quick hack.... It works for loading and executing files only... :-( I just hope that Acorn includes this feature in a better version in the next release of RISC OS! -- Dag Haakon Myrdal, student of electronics -- email: dhmyrdal@solan.unit.no (-SUN internet, Trondheim) snail: DH Myrdal,Studpost 136, N-7034 Trondheim, Norway phone: +47 7 588244 -- About MS-DOS: "... an OS originally designed for a microprocessor that modern kitchen appliances would sneer at...." - Dave Trowbridge, _Computer Technology Review_, Aug 90
thsa@rhi.hi.is (Thorvaldur S Arnarson) (05/01/91)
In article <vanaards.672489794@p4.cs.man.ac.uk> vanaards@p4.cs.man.ac.uk (Steven van Aardt) writes: | | In the user guide it states that a pseudo filing system can be |created using the ':' . Ie you could do *. system: Well I've tried this |and it doesn't work. The answer is quite simple. A path can consist of a list of directories like: *set foo$path adfs::4.$.,scsi::5.$. so what would you want the OS to do about a command like: *cat foo: or even worse: *rename foo:text foo:bar *save foo:bar 8000+100 -- thsa@rhi.hi.is (Thorvaldur S. Arnarson) Microscopic .sig rules! :-) *<-<
dhmyrdal@solan.unit.no (Dag H}kon Myrdal) (05/02/91)
In article <3089@krafla.rhi.hi.is>, thsa@rhi.hi.is (Thorvaldur S Arnarson) writes: |> |> The answer is quite simple. A path can consist of a list of directories |> like: |> *set foo$path adfs::4.$.,scsi::5.$. |> so what would you want the OS to do about a command like: |> *cat foo: |> or even worse: |> *rename foo:text foo:bar |> *save foo:bar 8000+100 [...] Simple! I want it to do what I tell it to as long as it's not ambigous... After all, most commands can use '*' and '#' as wildcards, so why shouldn't pseudo filing systems work the same way? After looking at your examples, I can see two possible solutions: 1: Do the same thing as is done for wildcards: search the path as given, using the *FIRST* occurence found that satisfy the command. If the command is sensible using several arguments, then DO SO! i.e.: *cat foo: equals *cat adfs::4.$ and then *cat scsi::5.$ *rename foo:text foo:bar uses adfs::4.$.<file> if found, scsi::5.$.<file> otherwise... *save foo:bar 8000+100 uses adfs::4.$.<file> 2: The not so sophisticated, but easier to implement solution would be: When more than one path-reference is given via a pseudo-filing-system: Either: stripp off all susequent references, or, if the command could be disastrous if not handled the way the user expected: give an error stating: "ambigous reference found in foo:" i.e.: *rename foo:text foo:bar uses adfs::4.$.text if found, scsi::5.$.text otherwise... *save foo:bar 8000+100 could flag an error As you can see; the whole point is that there is *no* need to eliminate the useful aspects of pseudo filing systems just because it *might* cause the user to issue ambigous commands... Just define a way to handle such cases. Either give an error or do the same thing as one would expect from a 'wildcarded' command! -- Dag Haakon Myrdal, student of electronics -- email: dhmyrdal@solan.unit.no (-SUN internet, Trondheim) snail: DH Myrdal, Moholt Alle 2-01, N-7035 Trondheim, Norway phone: +47 7 588244 -- About MS-DOS: "... an OS originally designed for a microprocessor that modern kitchen appliances would sneer at...." - Dave Trowbridge, _Computer Technology Review_, Aug 90
osmith@acorn.co.uk (Owen Smith) (05/02/91)
Try *set foo$dir adfs::4.$.fred
*setmacro foo$path <foo$dir>.,adfs::4.$.fred2.
Now, when you try to read a file eg. *dump foo:wombat, all of the directories
on the path variable foo$path will be searched. If you do something
that needs a single directory eg. *dir foo:, *cat foo:, *create foo:fred
then the single directory in foo$dir will be used.
This is not secret information. Various of the !Boot and !Run files in the
RiscOS TcpIp suite set path and dir variables. So does C release 3 - look
at CLib$Dir, CLib$Path, Risc_OSLib$Dir and Risc_OSLib$Path.
Doing *show * from time to time and perusing the output can be quite
interesting.
Owen.
The views expressed are my own and are not necessarily those of Acorn.gilbertd@p4.cs.man.ac.uk (Dave Gilbert) (05/03/91)
Owen says that if you do cat foo: where you have a number of things set up under foo$path it will look at foo$dir - why shouldnt it do something like produce a pseudo root directory e.g. set foo$path adfs::hard.$.apps, adfs::hard.$.dev and then doing cat foo: should give Directory $ containing two subdirectorys apps and dev. So I would then be able to say foo::$.dev.file This would allow you to easily emulate a UNIX system so that you could effectivly mount a number of drives, RAMFS etc under 1 directory structure. e.g. set foo$path adfs::hard.$, adfs::work.$ etc. I cant see this being that difficult to implement - please Acorn.... Dave -- ------------------------------------------------------------------------------- - Dave Gilbert - gilbertd@p4.cs.man.ac.uk - The MTBF of a piece of equipment - - G7FHJ@GB7NWP - is inversly proportional to its - ------------------------------------------- importance -
RMokady@acorn.co.uk (Ran "The horrible little oik" Mokady) (05/03/91)
In article <6815@acorn.co.uk> osmith@acorn.co.uk (Owen Smith) writes: >Try *set foo$dir adfs::4.$.fred > *setmacro foo$path <foo$dir>.,adfs::4.$.fred2. > >Now, when you try to read a file eg. *dump foo:wombat, all of the directories >on the path variable foo$path will be searched. If you do something >that needs a single directory eg. *dir foo:, *cat foo:, *create foo:fred >then the single directory in foo$dir will be used. > >This is not secret information. Various of the !Boot and !Run files in the >RiscOS TcpIp suite set path and dir variables. So does C release 3 - look >at CLib$Dir, CLib$Path, Risc_OSLib$Dir and Risc_OSLib$Path. > >Doing *show * from time to time and perusing the output can be quite >interesting. > >Owen. > >The views expressed are my own and are not necessarily those of Acorn. I think Owen got things a bit wrong. It is not possible to do any operation which requires a write on anything which contains a pseudo filing system reference - RISC OS simply doesn't know which directory to use. Things like the Risc OS TCP/IP suite set path variables in order to enable you to add other directories in the search list, when they are READING the files. In short, path variables can only be used to add directories to a search path when reading files, even operations such as *cat path: do not work. Ran. ----- "We're children, Needing other children And yet letting our grown up pride Hide all the need inside Acting more like children than children"
thsa@rhi.hi.is (Thorvaldur S Arnarson) (05/04/91)
In article <1991May1.184943.1835@ugle.unit.no> dhmyrdal@solan.unit.no (Dag H}kon Myrdal) writes: [My comments deleted...] |Simple! I want it to do what I tell it to as long as it's not ambigous... |After all, most commands can use '*' and '#' as wildcards, so why shouldn't |pseudo filing systems work the same way? |After looking at your examples, I can see two possible solutions: | |1: Do the same thing as is done for wildcards: | search the path as given, using the *FIRST* occurence found that satisfy | the command. | If the command is sensible using several arguments, then DO SO! ^^^^^^ This opens up the very lively discussion of globing. Why shouldn't the cli do globing a la unix shells. Comments anyone? And while I'm at it. Acorn! When can we expect to see a filingsystem thet can handle filenames of the "couple of miles long" variety. I'm not talking about NFS but something slightly more standalone. The abillity to handle many files with the same name but different type would also be usefull. -- thsa@rhi.hi.is (Thorvaldur S. Arnarson) Microscopic .sig rules! :-) *<-<
dbh@doc.ic.ac.uk (Denis Howe) (05/06/91)
In article <6815@acorn.co.uk> osmith@acorn.co.uk (Owen Smith) writes: >Try *set foo$dir adfs::4.$.fred > *setmacro foo$path <foo$dir>.,adfs::4.$.fred2. > >Now, when you try to read a file eg. *dump foo:wombat, all of the directories >on the path variable foo$path will be searched. Someone reported a problem with using macros as path variables due to a bug in OS_ReadVarVal which tries to expand macros into a non-existent buffer. foo$path only needs to be a macro if you want it to reflect subsequent changes to <foo$dir> so you could use probably plain *Set here, no? -- Denis Howe <dbh@doc.ic.ac.uk> C-C H558A Imperial College London C-C-C +44 (71) 589 5111 x5064 N=N
dbh@doc.ic.ac.uk (Denis Howe) (05/06/91)
In article <3106@krafla.rhi.hi.is> thsa@rhi.hi.is (Thorvaldur S Arnarson) writes: >This opens up the very lively discussion of globing. Why shouldn't the >cli do globing a la unix shells. Comments anyone? I was disappointed at first that RiscOS's CLI doesn't glob like Unix but there are a couple of advantages to leaving it up to the application that I can think of (gosh, me criticise Unix, This RiscOs must really be getting to me!): 1. The application can tell that it has wild cards in the argument. This makes possible things like mv *.o *.obj which are much harder under Unix. It can also complain if it doesn't want wild args, like *Delete. Of course you can quote the wild cards so that they are passed unexpanded but then Unix doesn't provide you with a nice library routine to expand them (or does it? apart from running a shell to do it :-(). 2. Neither the CLI nor the application need to allocate space for the whole expansion. Under RiscOS you can read one match at a time. Unix has a (large) limit on the length of the argument list. (The Unix utility xargs is a partial solution). I have always suspected the reason this, and various other things are the way they are is that the authors of RiscOS came from a VMS background rather than a Unix one. :-) Am I right? -- Denis Howe <dbh@doc.ic.ac.uk> C-C H558A Imperial College London C-C-C +44 (71) 589 5111 x5064 N=N
julian@sideways.gen.nz (Julian Wright) (05/07/91)
I have tried
*Set Foo$Dir adfs::foobar.$
*Set Foo$Path adfs::foobar.$.library.,adfs::foobar.$.,adfs::foobar.$.foo
.bar.fb.
followed by
*dir adfs::system.$
*cat Foo:
and I end up with a catalogue of adfs::system.$
In general for anything except loading or running, the path seems to be
ignored, and the existence of a foo$dir variable seems to have no special
significance...
Cheers, Julian.