'parrot foo' automatically finds and invokes foo.pbc

[pmichaud]

I just recently committed examples/sdl/blue_rect.pl as an example of exercising the SDL library using NQP. At the beginning of the file the instructions read:

To run this file, execute the following command from the Parrot directory:

$ ./parrot compilers/nqp/nqp.pbc examples/sdl/blue_rect.pl

Typing in that pathname is a bit of a pain -- what I'd really like to be able to say is

$ ./parrot nqp examples/sdl/blue_rect.pl

and then since parrot can't immediately find anything called 'nqp' to execute, it looks for nqp.pbc in a standard location or locations and invokes that. Similarly

$ ./parrot perl6 blue_rect.pl $ ./parrot tgc --output=gen.pir PASTGrammar.tg $ ./parrot abc $ ./parrot tcl xyz.tcl $ ./parrot pynie hello.py etc.

Before we get too far, let me point out what I'm *not* asking for. Specifically, I'm *not* asking for parrot to automatically select an appropriate compiler based on a file's signature or magic, as discussed in RT#32374. In other words, I'm *not* asking that

$ ./parrot examples/sdl/blue_rect.pl

be able to automatically determine an appropriate compiler and invoke it on the script. While this is a very worthy and important goal, at the moment there seem to be so many issues around "how does Parrot register compilers and figure out which one to use" that I fear it will be a while before this gets implemented. I want something sooner than that.

I'm also explicitly *not* asking to try to handle or resolve things based on Unix shebang lines, so that a file starting with

#!/path/to/parrot nqp

will automatically be executed with nqp. Again, it's something we will eventually want to consider, but given the vagaries of dealing with shebangs in so many different languages and platforms it's not what I'm aiming to get from this ticket.

All I'm really looking is to be able to place the .pbc file for a compiler or other application into a standard location where it can be invoked from Parrot without having to give a complete path to the .pbc file.

This could also have the benefit of simplifying Makefiles as well. For example, when I moved nqp from languages/ to compilers/ , I had to change the Makefile from

$(PARROT) $(PARROT)/languages/nqp/nqp.pbc ....

to

$(PARROT) $(PARROT)/compilers/nqp/nqp.pbc ...

While it was easy to do for this one case -- imagine if we had 10 or 20 applications that were using nqp as part of the build process. With the approach proposed here, the Makefile can have

$(PARROT) nqp ...

and it all just works.

I would also be willing to accept an option-based version of this, such as (pick an appropriate option name or letter):

$ ./parrot --prog=nqp blue_rect.pl

Comments, suggestions, and (most importantly) implementations welcomed. Thanks,

Pm

[coke]

Originally posted as  http://rt.perl.org/rt3/Ticket/Display.html?id=47992

[coke]

Comment from allison:

As mentioned in RT #49168, I'm in favor of a --language flag, that selects the default PBC/PIR file to run, and passes all other arguments to the ':main' sub in that file. It can also select default paths based on the options set the the configuration file for that language.

Then, using the $0 argument to 'main' in src/main.c, we can treat the name of the executable as setting the --language option, so, if 'perl6' is an alias to 'parrot', then:

$ perl6 myfile.pl

is the same as:

$ parrot --language=perl6 myfile.pl

I'm opposed to the command-line pattern of:

$ parrot perl6 myfile.pl

We don't want people to have to type 'parrot' every time they run a script with a language implemented on Parrot, so there's no value in providing a shortcut that only does half the job. It could also lead to some nasty conflicts, if someone happens to have a source file with the same name as one of their installed languages.

Allison

[coke]

Followup from pmichaud:

On Sat, Aug 30, 2008 at 07:45:08AM -0700, Allison Randal via RT wrote:

As mentioned in RT #49168, I'm in favor of a --language flag, that selects the default PBC/PIR file to run, and passes all other arguments to the ':main' sub in that file. It can also select default paths based on the options set the the configuration file for that language.

Agreed on the --language concept, although I think I prefer "--prog" (mentioned in #49168) to "--language". Not everything we might want to invoke in this manner is actually a compiler or language.

If we're agreed on this approach, I'll open a [todo] ticket for it. I might even write the patch to make it work. :-)

Pm

[coke]

Finally, a discussion occurred regarding whether or not fakeceutables would satisfy the spirit of the request. Answer? No.

[jkeenan]

Can we ask those interested in Parrot interface design to opine on the issues in this ticket?

Thank you very much.

kid51