Re: [HEADS UP] perl symlinks in /usr/bin will be gone

From: Chuck Swiger (cswiger_at_mac.com)
Date: 01/30/05

  • Next message: Robert Watson: "Re: [HEADS UP] perl symlinks in /usr/bin will be gone"
    Date: Sun, 30 Jan 2005 07:26:30 -0500
    To: Holger Kipp <hk@alogis.com>
    
    

    Holger Kipp wrote:
    > On Sun, Jan 30, 2005 at 05:31:21AM -0500, Chuck Swiger wrote:
    >>Sure, assuming there actually was a perl in /usr/bin. I would not choose
    >>to hardcode the path to perl when env is available to properly locate the
    >>interpreter for #!-based scripts via the $PATH.
    >
    > a) we had perl at /usr/bin/perl
    > => many scripts are using "#!/usr/bin/perl"

    If "we" means FreeBSD-4, OK.

    Otherwise, I remember using a /usr/local/bin/perl-4.036 several years before
    vendors started shipping Perl with the system in /usr/bin.

    >> I don't want the Perl port to change in a way that breaks existing scripts.
    >
    > fine, so we must keep the symlink in /usr/bin/

    That is one solution, but it is not the only available choice.

    >> I don't want perl scripts to assume that Perl is in /usr/bin, or
    >> /usr/local/bin, or any other specific place.
    >
    > Your problem. Write your scripts accordingly and be happy. Talk with several
    > thousand programmers who use perl and assume it is located at /usr/bin/perl
    > and convince them to write their programs differently. Otherwise, this
    > breaks POLA. See c)

    As I said to Kris, I'm perfectly willing to change existing software or write
    my own to suit my preferences. If other people want to do something else
    which pleases them better, fine, that's up to them.

    >>I don't want to have perl symlinked between /usr/bin and /usr/local/bin.
    >
    > Fine, then _you_ can remove the symlink by hand on your systems every time.

    Or I could not bother and simply let env deal with finding the right version
    of perl. Works for me.

    >> I do want scripts to use a portable mechanism to invoke Perl regardless of
    >> where the binary happens to be found, but if people are determined to do
    >> otherwise, well, that's up to them. One solution for those people might be
    >> to install the Perl port with a $PREFIX of /usr rather than /usr/local.
    >
    > Huh? It was removed from the base system, so it belongs to /usr/local.

    There is a conflict between installing perl to /usr/local/bin and expecting to
    invoke perl from /usr/bin. Perhaps you've decided to live with it and are
    happy with symlinks so that both paths work.

    > Get real.

    Oh, I am. Mostly. :-)

    > Removing the symlinks permanently is causing lots of trouble.

    For some people, agreed. It doesn't matter one bit to other people...

    > Not removing them is fine with me and at least most other users.

    Leaving the symlinks as they are now is probably the least intrusive way of
    dealing with the current mess that Perl script invocation has become.

    Fortunately, people doing Python seemed to have learned from these problems,
    as a quick check via GoogleFight suggests that the majority of Python scripts
    use env rather than hardcoding a path.

    -- 
    -Chuck
    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
    

  • Next message: Robert Watson: "Re: [HEADS UP] perl symlinks in /usr/bin will be gone"

    Relevant Pages

    • Why not to use env (was Re: Perl executable pathname needs to be hardwired?)
      ... Chris> My understanding is that the Python idiom is to avoid putting the full ... This won't work if env is not in your current directory! ... One problem is that while Perl may be in *my* PATH for an unusual ... and env launches Perl... ...
      (perl.beginners)
    • Re: setting %ENV in a module
      ... then the resulting hash value is the literal $ENV-VAR - perl is not ... "$v", to the value of the %ENV hash, that string gets stored as is. ... $ENV{TMPTEST} to $TMPTEST, and changing one will change the other. ... process the lines of that array one-at-a-time, ...
      (comp.lang.perl.misc)
    • Re: setting %ENV in a module
      ... then the resulting hash value is the literal $ENV-VAR - perl is not ... "$v", to the value of the %ENV hash, that string gets stored as is. ... $ENV{TMPTEST} to $TMPTEST, and changing one will change the other. ... process the lines of that array one-at-a-time, ...
      (comp.lang.perl.misc)
    • Re: creating shell scripts using #!/usr/local/env perl
      ... >>Paul Lalli ... > did you actually read the man page for env? ... current environment, that is, without modifying the environment at all. ... This is useful for transporting perl scripts from one machine to another, ...
      (comp.lang.perl.misc)
    • Re: creating shell scripts using #!/usr/local/env perl
      ... zzapper> Actually as env is always available you can do ... And that's not a Unix system. ... print "Just another Perl hacker,"; ...
      (comp.lang.perl.misc)