OS_GetEnv result
Peter Naulls
I'm pretty sure the result of this isn't what you'd expect:
#include <stdio.h>
#include <kernel.h>
#include <swis.h>
int main(int argc, char *argv[]) {
char *cli;
_swi(OS_GetEnv, _OUT(0), &cli);
puts(cli);
return 0;
}
If you run the program with a full pathname, you'll get something like:
*lanman98::peter.$.temp.moose
:peter.$.temp.moose
This is RISC OS 4.29
And yes, this isn't a C library issue - the result is the same in SCL
and UnixLib. Can people try on other versions?
Thanks.
--
------------------------------------------------------------------------
Peter Naulls - pe...@chocky.org
Homepage - http://www.chocky.org/
RISC OS C Programming - http://www.riscos.info/
Unix Programs on RISC OS - http://www.chocky.org/unix/
------------------------------------------------------------------------
Nemo
> I'm pretty sure the result of this isn't what you'd expect:
Well it should be. That's exactly what I would expect when running a file
from a temporary filing system.
There is a big difference between...
*lanman98::peter.$.temp.moose
and...
*/lanman98::peter.$.temp.moose
...I take it you didn't know this.
You are clearly not a Master Programmer (as in M128) ;-)
--
Nemo ne...@20000.org
Martin Dann
Peter Naulls <pe...@chocky.org> wrote:
> _swi(OS_GetEnv, _OUT(0), &cli);
>
> puts(cli);
> *lanman98::peter.$.temp.moose
> :peter.$.temp.moose
> This is RISC OS 4.29
>
> And yes, this isn't a C library issue - the result is the same in SCL
> and UnixLib. Can people try on other versions?
Using the following assembler programme, written entirly in Zaps
code mode:
00008000 : ...ļ : EF000010 : SWI OS_GetEnv
00008004 : ...ļ : EF000002 : SWI OS_Write0
00008008 : .š į : E1A0F00E : MOV PC,R14
0000800C :
Typeing adfs::hd4.$.dim.ab
I get
:hd4.dim.ab
However typeing run adfs::hd4.$.dim.ab
I get
adfs::hd4.$.dim.ab
So the error is in RO.
(me using RO3.7).
--
Typed by monkey #27662472869676 on typewriter #7552416572242
Peter Naulls
Nemo <ne...@20000.invalid> wrote:
> On 1 Aug, Peter Naulls wrote:
>
> > I'm pretty sure the result of this isn't what you'd expect:
>
> Well it should be. That's exactly what I would expect when running a file
> from a temporary filing system.
>
> There is a big difference between...
>
> *lanman98::peter.$.temp.moose
>
> and...
>
> */lanman98::peter.$.temp.moose
>
> ...I take it you didn't know this.
I'm not sure why the result of the first is useful :-| Anyway, it
occurs with a non "temporary" filesystem too - e.g. ADFS, ATAFS.
> You are clearly not a Master Programmer (as in M128) ;-)
It's been 7 years since I programmed a Master Compact :-)
What I really want is useful results in argv[0] in Unixlib when programs
are launched with full pathnames.
Peter
Martin Wuerthner
Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> Typeing adfs::hd4.$.dim.ab
> I get
> :hd4.dim.ab
> However typeing run adfs::hd4.$.dim.ab
> I get
> adfs::hd4.$.dim.ab
>
> So the error is in RO.
> (me using RO3.7).
It is not an error, it is documented behaviour - although not exactly what
you would expect. To expand on Nemo's slightly cryptic hints:
In RISC OS, a command can be prefixed by a filing system name to force it
to be interpreted by the given filing system. This is how you can
disambiguate commands that are provided by several filing systems, e.g.,
Format. The prefixed filing system becomes the temporarily selected filing
system during the interpretation of the command (as opposed to the
currently selected filing system, which you can select by typing its name
at the command line without the colon). Therefore, RISC OS defines that if
a command starts with a sequence of letters followed by a colon, then the
remainder of the command is passed to the filing system if such a filing
system exists.
The mix-up happens because a file name or path name can also be a command
under RISC OS being an implicit *Run.
So, the command "adfs::hd4.$.dim.ab" is interpreted in the following way
by RISC OS: A leading "adfs:" means that the remainder of the command
should be sent to the ADFS filing system. The remainder happens to be
":hd4.$.dim.ab", so this is all ADFS gets to see. ADFS looks at the
command and decides that it is not a special one provided by itself, so it
then takes this as a path name and *Runs it.
This is a big difference to "run adfs::hd4.$.dim.ab" or
"/adfs::hd4.$.dim.ab". These contain a real command and are therefore not
interpreted by ADFS.
So, it is all in the manual...
Martin
--
---------------------------------------------------------------------
Martin Wuerthner MW Software mar...@mw-software.com
---------------------------------------------------------------------
Martin Wuerthner
Peter Naulls <pe...@chocky.org> wrote:
> In message <c3c8665f4b%ne...@20000.invalid>
> Nemo <ne...@20000.invalid> wrote:
>
> > On 1 Aug, Peter Naulls wrote:
> >
> > > I'm pretty sure the result of this isn't what you'd expect:
> >
> > Well it should be. That's exactly what I would expect when running a file
> > from a temporary filing system.
> >
> > There is a big difference between...
> >
> > *lanman98::peter.$.temp.moose
> >
> > and...
> >
> > */lanman98::peter.$.temp.moose
> >
> > ...I take it you didn't know this.
>
> I'm not sure why the result of the first is useful :-| Anyway, it
> occurs with a non "temporary" filesystem too - e.g. ADFS, ATAFS.
"Temporary" as in "temporarily selected" by prefixing a command with it.
You can do this with all filing systems. See my other longish explanation.
> > You are clearly not a Master Programmer (as in M128) ;-)
>
> It's been 7 years since I programmed a Master Compact :-)
>
> What I really want is useful results in argv[0] in Unixlib when programs
> are launched with full pathnames.
"When", but in the above case, they are not. They are launched with a
filing system relative pathname within the temporarily selected filing
system.
I wonder how often this happens: When typing commands at the command
prompt, you would normally expect to launch programs via the Library or
Run$Path, so you type "gcc" without specifying the full path name.
Alternatively, in a script or a program, I always use "Run" or "/" to
avoid exactly the above problem. Why do you think it is customary under
RISC OS to NOT use "<XXX$Dir>.!RunImage" as the last line of a !Run file,
but ALWAYS either "/<XXX$Dir>.!RunImage" or "Run <XXX$Dir>.!RunImage"?
Rik Griffin
> In message <c3c8665f4b%ne...@20000.invalid>
> Nemo <ne...@20000.invalid> wrote:
>
> > Well it should be. That's exactly what I would expect when running a
> > file from a temporary filing system.
> >
> > There is a big difference between...
> >
> > *lanman98::peter.$.temp.moose
> >
> > and...
> >
> > */lanman98::peter.$.temp.moose
>
> I'm not sure why the result of the first is useful :-| Anyway, it
> occurs with a non "temporary" filesystem too - e.g. ADFS, ATAFS.
That's not what Nemo means.
When RISCOS sees:
lanman98::peter.$.temp.moose
it interprests this in 2 parts. First, it changes FS to "lanman98:" -
this is the "temporary filesystem". Then it executes the file
":peter.$.temp.moose" on that filesystem. Finally, it changes back to
the current filesystem.
The same effect can be seen by typing: -lanman98-:peter.$.temp.moose
I refer you to the PRMs, page 2-11.
--
Rik Griffin
My opinions are my own. Oi you, hands off my opinions!
John Tytgat
>What I really want is useful results in argv[0] in Unixlib when programs
>are launched with full pathnames.
>
Me too. I've seen this behaviour in CVS too but didn't found the time
yet to fix this (it needs to be done at various places). It is not only
argv[0] but also to the code to read the current directory.
BTW, another problem with argv[0] is when you've configured UnixLib to
get Unix alike file specs, argv[0] is still a RISC OS file spec.
Jo.
--
John Tytgat f u cn rd ths,
Jo...@esko-graphics.com u cn gt a gd jb n cmptr prgrmmng !
Peter Naulls
Martin Wuerthner <mar...@mw-software.com.invalid> wrote:
> > What I really want is useful results in argv[0] in Unixlib when programs
> > are launched with full pathnames.
>
> "When", but in the above case, they are not. They are launched with a
> filing system relative pathname within the temporarily selected filing
> system.
They are. The full path was entered ("launched"); what happens after
it's passed to fileswitch is another matter. I think you are just
pushing semantics here.
> I wonder how often this happens: When typing commands at the command
> prompt, you would normally expect to launch programs via the Library or
> Run$Path, so you type "gcc" without specifying the full path name.
> Alternatively, in a script or a program, I always use "Run" or "/" to
> avoid exactly the above problem. Why do you think it is customary under
> RISC OS to NOT use "<XXX$Dir>.!RunImage" as the last line of a !Run file,
> but ALWAYS either "/<XXX$Dir>.!RunImage" or "Run <XXX$Dir>.!RunImage"?
It's common enough to be a real issue. Apart from the case of
shift-dragging an absolute to a taskwindow (which is something I do
quite often), programs may launch other programs in various ways which
may or may not result in this.
I think the solution may be to reconstruct the full filename for argv[0]
using the fileswitch variables.
In message <3D4A53BC...@esko-graphics.com>
John Tytgat <Jo...@esko-graphics.com> wrote:
> BTW, another problem with argv[0] is when you've configured UnixLib to
> get Unix alike file specs, argv[0] is still a RISC OS file spec.
This is the related issue of course. A weak symbol may be in order
here. However, given that the Unixlib default is to use unix filenames,
probably argv[0] should have unix semtantics. As you're no doubt aware,
it's quite common for programs to pick up argv[0], and truncate it to a
'/' for use with message reporting.
John Tytgat
>In message <3D4A53BC...@esko-graphics.com>
> John Tytgat <Jo...@esko-graphics.com> wrote:
>
>>BTW, another problem with argv[0] is when you've configured UnixLib to
>>get Unix alike file specs, argv[0] is still a RISC OS file spec.
>>
>
>This is the related issue of course. A weak symbol may be in order
>here.
>
I'm not sure whether I fully understand the purpose of this weak symbol
here.
> However, given that the Unixlib default is to use unix filenames,
>probably argv[0] should have unix semtantics. As you're no doubt aware,
>it's quite common for programs to pick up argv[0], and truncate it to a
>'/' for use with message reporting.
>
Indeed.
We better to followup this discussion in the GCC mailing list.
John.
Nemo
> To expand on Nemo's slightly cryptic hints
Me, terse?
> a command can be prefixed by a filing system name to force it to be
> interpreted by the given filing system.
In fact, the behaviour isn't limited to filing systems, you can direct a
command at any particular module. So "*WindowManager:Iconsprites" is
/nearly/ functionally identical to "*Iconsprites".
I say "nearly", because this prefixing defeats aliases - if you set
Alias$Iconsprites to "echo %*0" then *Iconsprites won't do anything useful,
but *WindowManager:Iconsprites will, and you can't alias the prefixed
version.
To summarize:
*<prefix>:<command> Sends <command> to the module <prefix> or, if
that fails, select <prefix> as the temporary
filing system and execute <command> (which need
not be a file - "*adfs:Iconsprites" is legal)
*-<fs>-<file> Select <fs> as the temporary filing system and
run <file>. [For Master compatability only]
I don't know why Peter was surprised at the result of GetEnv though - what
if I had typed:
*/lanman98::p*.t*.m*
...GetEnv only returns the command line - this isn't necessarily a unique or
canonical pathname. Should you need to "fix" such a pathname, use
FSControl,37 to canonicalise the path - this will take account of the
temporary FS and return what Peter was originally (erroneously) expecting.
;-)
> So, it is all in the manual...
And now it is floating round the ether of the internet, for evermore. :-)
--
Nemo ne...@20000.org
Peter Naulls
Nemo <ne...@20000.invalid> wrote:
> I don't know why Peter was surprised at the result of GetEnv though - what
> if I had typed:
Simple. Because I wasn't aware of the behaviour (at least, not that I'd
remebered)
>
> */lanman98::p*.t*.m*
>
> ...GetEnv only returns the command line - this isn't necessarily a unique or
> canonical pathname. Should you need to "fix" such a pathname, use
> FSControl,37 to canonicalise the path - this will take account of the
> temporary FS and return what Peter was originally (erroneously) expecting.
There was nothing erroneous. I was asking why it was the case.
Probably I should have known that csa.p would only reply in terms that
are close to rants.
Rik Griffin
Nemo <ne...@20000.invalid> wrote:
> I don't know why Peter was surprised at the result of GetEnv though -
> what if I had typed:
>
> */lanman98::p*.t*.m*
> ...GetEnv only returns the command line - this isn't necessarily a
> unique or canonical pathname. Should you need to "fix" such a
> pathname, use FSControl,37 to canonicalise the path - this will take
> account of the temporary FS and return what Peter was originally
> (erroneously) expecting.
Actually calling FSControl 37 makes matters worse.
I think that by the time the program is actually running, the temporary
filing system has been set back to what it was BEFORE the program was
run. The TFS is probably only changed for as long as OS_CLI is setting
up the program's environment (or whoever sets this up - I'm not certain
of exactly how this works).
If you canonicalise ":peter.$.temp.moose" from within the posted
program, you'll get "ADFS::peter.$.temp.moose", assuming ADFS was the
current filing system.
druck
> I think the solution may be to reconstruct the full filename for argv[0]
> using the fileswitch variables.
OS_FSControl Canonicalise Path (37) is your friend.
If given a partial path such as ":Disc.$.Whatever" it will convert it to
the full "XXFS::Disc.$.Whatever".
---druck
--
The ARM Club * http://www.armclub.org.uk/
Peter Naulls
druck <ne...@druck.freeuk.com> wrote:
> On 2 Aug 2002 Peter Naulls <pe...@chocky.org> wrote:
> > I think the solution may be to reconstruct the full filename for argv[0]
> > using the fileswitch variables.
>
> OS_FSControl Canonicalise Path (37) is your friend.
>
> If given a partial path such as ":Disc.$.Whatever" it will convert it to
> the full "XXFS::Disc.$.Whatever".
Alas, this will only work if the temporary filing system is the same as
the current one. Which it often won't be. (Lanman98 vs ATAFS in my
example). As has also been pointed out, I'm not sure that reading
variables will work either.
Peter
Stefan Bellon
> In message <f990ce5f...@druck.freeuk.net>
> druck <ne...@druck.freeuk.com> wrote:
[snip]
> > OS_FSControl Canonicalise Path (37) is your friend.
> >
> > If given a partial path such as ":Disc.$.Whatever" it will convert
> > it to the full "XXFS::Disc.$.Whatever".
> Alas, this will only work if the temporary filing system is the same
> as the current one.
Are you sure? I used this in my "hack" to make UnixLib detect PipeFS
file names. It worked so far and Nick committed it. It's in
source/unix/dev.c.
--
Stefan Bellon * <mailto:sbe...@sbellon.de> * <http://www.sbellon.de/>
PGP 2 and OpenPGP keys available from my home page
Sometimes what you get free costs entirely too much.
Peter Naulls
Stefan Bellon <sbe...@sbellon.de> wrote:
> Peter Naulls wrote:
> > In message <f990ce5f...@druck.freeuk.net>
> > druck <ne...@druck.freeuk.com> wrote:
>
> [snip]
>
> > > OS_FSControl Canonicalise Path (37) is your friend.
> > >
> > > If given a partial path such as ":Disc.$.Whatever" it will convert
> > > it to the full "XXFS::Disc.$.Whatever".
>
> > Alas, this will only work if the temporary filing system is the same
> > as the current one.
>
> Are you sure? I used this in my "hack" to make UnixLib detect PipeFS
> file names. It worked so far and Nick committed it. It's in
> source/unix/dev.c.
But that addresses rather a different issue - in your case, there's no
running of a program. Peraps you didn't read the thread in its
entirety?
Nemo
> Probably I should have known that csa.p would only reply in terms that are
> close to rants.
I'm sorry if I sounded ratty, nothing could be further from the truth. :-)
Actually I'm feeling quite warm and snuggly right now, and I don't know why
my writing should look unfriendly.
Perhaps I should change to a different font. FancyDress perhaps :-))
--
Nemo ne...@20000.org
Stefan Bellon
[snip]
> > Are you sure? I used this in my "hack" to make UnixLib detect PipeFS
> > file names. It worked so far and Nick committed it. It's in
> > source/unix/dev.c.
> But that addresses rather a different issue - in your case, there's no
> running of a program. Peraps you didn't read the thread in its
> entirety?
Sury I did. I only follow up to postings when I've read at least the
last five references (if there exist that many). ;-)
But I haven't understood the difference. :-}
I now have taken your minimal example and added the OS_FSControl thing:
#include <stdio.h>
#include <stdlib.h>
#include <kernel.h>
#include <swis.h>
int main(int argc, char *argv[]) {
char *cli, *tmp;
int len;
_swi(OS_GetEnv, _OUT(0), &cli);
_swi (OS_FSControl,
_INR(0,2) | _IN(5) | _OUT(5),
37, cli, 0, 0,
&len);
if (len>0) return 1;
tmp = malloc (1 - len);
if (tmp)
_swi (OS_FSControl,
_INR(0,2) | _IN(5) | _OUT(5),
37, cli, tmp, 1 - len,
&len);
else
tmp = cli;
puts(tmp);
return 0;
}
Let's call this executable 'test' for a moment and watch what happens:
*copy test RAM::RAMDisc0.$.test ~c~v
*cdir RAM::RAMDisc0.$.foobar
*copy test RAM::RAMDisc0.$.foobar.test ~c~v
*dir ADFS::A5.$.Apps
*ram:test
ADFS::A5.$.Apps.test
*ram:foobar.test
ADFS::A5.$.Apps.foobar.test
This means, OS_FSControl in fact takes the CSD (not just the current
filing system) and adds the filename given in R1 to its end.
Or am I wrong again. ;-)
--
Stefan Bellon * <mailto:sbe...@sbellon.de> * <http://www.sbellon.de/>
PGP 2 and OpenPGP keys available from my home page
Ceterum censeo Microsoft esse delendam
Stewart Brodie
Martin Dann <Mar...@f451.freeserve.co.uk> wrote:
> In message <f43f655f...@moo.chocky.org>
> Peter Naulls <pe...@chocky.org> wrote:
>
>
> > _swi(OS_GetEnv, _OUT(0), &cli);
> >
> > puts(cli);
>
> > *lanman98::peter.$.temp.moose
> > :peter.$.temp.moose
>
>
> > This is RISC OS 4.29
> >
> > And yes, this isn't a C library issue - the result is the same in SCL
> > and UnixLib. Can people try on other versions?
>
> Using the following assembler programme, written entirly in Zaps
> code mode:
>
> 00008000 : ...ï : EF000010 : SWI OS_GetEnv
> 00008004 : ...ï : EF000002 : SWI OS_Write0
I think you meant "SWIVC OS_Write0" to be absolutely safe :)
> 00008008 : .ð á : E1A0F00E : MOV PC,R14
> 0000800C :
> Typeing adfs::hd4.$.dim.ab
> I get
> :hd4.dim.ab
> However typeing run adfs::hd4.$.dim.ab
> I get
> adfs::hd4.$.dim.ab
>
> So the error is in RO.
> (me using RO3.7).
No, there is no error - you are just mistaken in what you think you are
asking for.
If you type "adfs::hd4.$.dim.ab", then that means to RISC OS: "Select ADFS as
the temporary filesystem, then execute the *-command :hd4.$.dim.ab in that
context; restore the previous filesystem"
If you type "run adfs::hd4.$.dim.ab" (or "/adfs::hd4.$.dim.ab"), that means
to RISC OS: "Run the file adfs::hd4.$.dim.ab", and doesn't involve messing
around with the currently set filesystem.
The <filingsystem>: prefix thing has been present for a very long time
(perhaps even as far back as on the BBC B). It also works with <modulename>:
prefixes, which is why you can do things like:
*URL_Fetcher:urlprotoshow
This is useful if you have multiple modules providing the same *-command.
The most common place this arises is with filing system commands but it would
be a pain to always have to prefix commands with the filesystem name, which
is why there is a special bit in the flags for a *-command which marks
commands which are only "available" if that module holds the currently
selected filesystem. These are commands listed as "Filing system commands"
in a module's *Help output.
--
Stewart Brodie, Senior Software Engineer (Views expressed are my own and
Pace Micro Technology PLC not those of my employer)
645 Newmarket Road
Cambridge, CB5 8PB, United Kingdom WWW: http://www.pacemicro.com/
Nemo
> In message <64efa35f4b%ne...@20000.invalid>
> Nemo <ne...@20000.invalid> wrote:
>
> > use FSControl,37 to canonicalise the path - this will take account of
> > the temporary FS
>
> Actually calling FSControl 37 makes matters worse.
Under some circumstances, you are right.
> I think that by the time the program is actually running, the temporary
> filing system has been set back to what it was BEFORE the program was run.
It depends on what the filetype is. If it's a Utility for example, all will
be well and FSC37 will work as expected. However, if it is an Absolute, or a
Load/Exec file, FileSwitch resets the temporary filing system before running
it.
It may be possible to fix this by canonicalising the first "word" of the
command line on FSControl,4, UpCall,256, or ServiceCall,42, but I haven't
tried.
--
Nemo ne...@20000.org
Peter Naulls
Stefan Bellon <sbe...@sbellon.de> wrote:
> Let's call this executable 'test' for a moment and watch what happens:
>
> *copy test RAM::RAMDisc0.$.test ~c~v
> *cdir RAM::RAMDisc0.$.foobar
> *copy test RAM::RAMDisc0.$.foobar.test ~c~v
> *dir ADFS::A5.$.Apps
> *ram:test
> ADFS::A5.$.Apps.test
> *ram:foobar.test
> ADFS::A5.$.Apps.foobar.test
>
> This means, OS_FSControl in fact takes the CSD (not just the current
> filing system) and adds the filename given in R1 to its end.
>
> Or am I wrong again. ;-)
Yes, it takes the CSD, although that doesn't really help us get to where
we'd like in argv[0]. i.e., argv[0] should be exactly (or canonically)
identical to what was typed at the start prompt.
Either way, your program is buggy :-)
*RAM::RamDisc0.$.test
쓡#:UnixLib$env:RamDisc0.$.test
Stefan Bellon
[snip]
> > This means, OS_FSControl in fact takes the CSD (not just the current
> > filing system) and adds the filename given in R1 to its end.
> >
> > Or am I wrong again. ;-)
> Yes, it takes the CSD, although that doesn't really help us get to
> where we'd like in argv[0].
Of course not, but nobody mentioned the CSD so far, so I thought I
should. ;-)
[snip]
> Either way, your program is buggy :-)
What do you expect at 1 a.m. in the morning? ;-)
--
Stefan Bellon * <mailto:sbe...@sbellon.de> * <http://www.sbellon.de/>
PGP 2 and OpenPGP keys available from my home page
f u cn rd ths, u cn gt a gd jb s cmptr prgrmmr!