Name of parrot executable
Will Coleda
[info nameofexecutable]
I need to get the name of the exectuable parrot was invoked with. I would
have expected to live in interpinfo, but don't see it there.
Anyone have a pointer to where this is? (If it's not in yet, I'll
add a TODO)
Leopold Toetsch
> To implement tcl's
> [info nameofexecutable]
> I need to get the name of the exectuable parrot was invoked with. I would
> have expected to live in interpinfo, but don't see it there.
The executable name (and all interpreter arguments) are swallowed by
imcc/main.c:parseflags. AFAIK is the access to the executable name not
really portable, e.g. if it contains the full path or not.
Perl5 has for sure some code to create $0. Patches welcome.
> Anyone have a pointer to where this is? (If it's not in yet, I'll
> add a TODO)
Thanks,
leo
Dan Sugalski
Let's add it as a TODO. Two new interpinfo options -- fullname (which
gives the entire executable name as we got it) and basename which
gives the name without the path and suffix information.
As an example, if we were invoked as:
~/src/parrot/parrot foo.pbc
then fullname would be "~/src/parrot/parrot" and basename would be
"parrot". If, on the other hand, we were invoked as:
parrot foo.pbc
then both fullname and basename would be "parrot". Unix hashbang (and
Windows file association) invocation may give us something different
-- if the user did:
~/src/foo.pasm
and you'd either associated .pasm with parrot, or foo.pasm started
"#! /usr/bin/parrot" (which is legal :) then you'd get a fullname of
"~/src/foo.pasm" and a basename of "foo".
Clear and sensible?
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Dan Sugalski
>On Wed, Jan 19, 2005 at 10:54:53AM -0500, Dan Sugalski wrote:
>
>> "parrot". If, on the other hand, we were invoked as:
>>
>> parrot foo.pbc
>>
>> then both fullname and basename would be "parrot". Unix hashbang (and
>> Windows file association) invocation may give us something different
>> -- if the user did:
>>
>> ~/src/foo.pasm
>>
>> and you'd either associated .pasm with parrot, or foo.pasm started
>> "#! /usr/bin/parrot" (which is legal :) then you'd get a fullname of
>> "~/src/foo.pasm" and a basename of "foo".
>>
>> Clear and sensible?
>
>(the script name)
>
>Perl 5 also puts some effort into seeing if it can get a fully qualified
>path for the interpreter from the OS. Certainly this is do-able on Solaris,
>on Linux given /proc, and on FreeBSD given /proc and a following wind
>(at least on FreeBSD 4 where there is a bug). I think it's do-able on Win32
>too.
>
>Would we want to try to do this?
Good point--we should. That'd mean we'd want to have three sets of
data: the invoked full/base name, the 'program' full/base name, and
the interpreter full/base name. (With the invoked full/base being the
same as either the program or interpreter full/base, but which way it
went would depend on how things were fired off, so we might as well
have them all separate)
Jonathan Worthington
> On Wed, Jan 19, 2005 at 10:54:53AM -0500, Dan Sugalski wrote:
>
>>
>> parrot foo.pbc
>>
>> then both fullname and basename would be "parrot". Unix hashbang (and
>> Windows file association) invocation may give us something different
>> -- if the user did:
>>
>> ~/src/foo.pasm
>>
>> and you'd either associated .pasm with parrot, or foo.pasm started
>> "#! /usr/bin/parrot" (which is legal :) then you'd get a fullname of
>> "~/src/foo.pasm" and a basename of "foo".
>>
>> Clear and sensible?
>
> (the script name)
>
> Perl 5 also puts some effort into seeing if it can get a fully qualified
> path for the interpreter from the OS. Certainly this is do-able on
> Solaris,
> on Linux given /proc, and on FreeBSD given /proc and a following wind
> (at least on FreeBSD 4 where there is a bug). I think it's do-able on
> Win32
> too.
>
NULL in as the first parameter. That gives the full path and name of the
current executable.
Jonathan
Nicholas Clark
> "parrot". If, on the other hand, we were invoked as:
>
> parrot foo.pbc
>
> then both fullname and basename would be "parrot". Unix hashbang (and
> Windows file association) invocation may give us something different
> -- if the user did:
>
> ~/src/foo.pasm
>
> and you'd either associated .pasm with parrot, or foo.pasm started
> "#! /usr/bin/parrot" (which is legal :) then you'd get a fullname of
> "~/src/foo.pasm" and a basename of "foo".
>
> Clear and sensible?
Perl 5 makes the distinction between $^X (the interpreter name) and $0
(the script name)
Perl 5 also puts some effort into seeing if it can get a fully qualified
path for the interpreter from the OS. Certainly this is do-able on Solaris,
on Linux given /proc, and on FreeBSD given /proc and a following wind
(at least on FreeBSD 4 where there is a bug). I think it's do-able on Win32
too.
Would we want to try to do this?
Nicholas Clark
Matt Diephouse
> Good point--we should. That'd mean we'd want to have three sets of
> data: the invoked full/base name, the 'program' full/base name, and
> the interpreter full/base name.
Then we can use this to have parrot look for .include's and dynclasses
from the root parrot directory? (See #32178)
--
matt diephouse
http://matt.diephouse.com
Dan Sugalski
>On Wed, 19 Jan 2005 11:09:19 -0500, Dan Sugalski <d...@sidhe.org> wrote:
>> Good point--we should. That'd mean we'd want to have three sets of
>> data: the invoked full/base name, the 'program' full/base name, and
>> the interpreter full/base name.
>
>Then we can use this to have parrot look for .include's and dynclasses
>from the root parrot directory? (See #32178)
I think so, but I'll admit the prospect makes the sysadmin bit of me
profoundly nervous. I'm thinking Parrot should have some pretty
draconian, paranoid defaults about where things it wants live, with a
mechanism to lift them if need be. I'd feel a lot more comfortable
about that -- we can't stop people from compromising their accounts
and systems, but I'm thinking we ought not make it too easy.