Messed up Perl
Daniel J. Luke
dluke at geeklair.net
Mon Oct 4 13:11:34 PDT 2010
On Oct 4, 2010, at 4:04 PM, Michael_google gmail_Gersten wrote:
>
> So, for any program with a local version and a system version, we need
> a generic_select program.
How is having a *_select problem going to be easier for people than using the full path to the binary they want or having the user modify their $PATH to do what they want?
> So the first question is, how does python_select work, and can we make
> a generic_select?
You can pretty easily check out the source code if you're actually curious as to how it works. I don't think it's going to be any easier to remember to run *_select for whichever program you want.
> And note that this doesn't quite address the issue of "User 1 installs
> the newest perl for their use, but user 2 wants the older, system
> perl".
That user will just put #!/usr/bin/perl in his/her script, use the full path to the perl he/she wants, or adjust his/her path.
It's very common to have more than one perl binary installed on a system (especially think back to when perl5 was new).
> But we must have run into that with python already -- how do
> python users deal with multiple users on a system wanting different
> versions?
I would venture to guess that most Mac OS X systems really only have one user who cares about a particular perl/python version.
--
Daniel J. Luke
+========================================================+
| *---------------- dluke at geeklair.net ----------------* |
| *-------------- http://www.geeklair.net -------------* |
+========================================================+
| Opinions expressed are mine and do not necessarily |
| reflect the opinions of my employer. |
+========================================================+
More information about the macports-users
mailing list