Re: [perl #47992] [RFE] 'parrot foo' automatically finds and invokes foo.pbc

[Patrick R. Michaud]

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

[Allison Randal via RT]

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

[Patrick R. Michaud]

On Sun, Sep 20, 2009 at 11:30:58PM -0700, Will Coleda via RT wrote:

> Do the fakecutables satisfy the spirit of this request?

IMO, not really. I don't think we want to treat fakecutables as
the official mechanism for creating command-line tools using Parrot.

Pm