How to put '#!/usr/bin/env perl -w' at the beginning of a perlscript?

W

Wanna-Be Sys Admin

Ilya said:
When I "invented" your proposed solution, I investigated why it does
not work. There were several reasons; what I remember:

I think there is some confusion. I wasn't the one that proposed
modifying $HOME or creating symlinks. I talked about them in response
to what some others had suggested.
a) when entering from different computers on the net, $HOME may
point to different locations (via local disk, or via NFS mount
points - which in turn may be mounted differently on different
architectures);

Yes, they might. The OP's issue was having the script work across
different systems, stating the path has to be fixed to use whatever
unique install. There are only so many ways to go about that, and
several people offered various solutions. If it's always a unique
install on the local account, then they should be able to set the path
without setting it absolute (and static) perhaps. Who knows what will
really work for them well, since they didn't outline the different
scenarios about the exact problem porting their script to different
systems.
b) when a disk carrying (a bunch of $HOME directories) would fill
up, $HOME may migrate to a different disk on a different
computer.

True, I was simply saying that usually an account is set up for one
directory or partition, or drive, or mount (local or NFS, or iscsi, or
whatever), and not moved, as new accounts are usually set up with a
different path if the other starts to become full, but you're right,
accounts may be moved after the fact to clear up room. I'd hope any
system admin that moved accounts would be smart enough to know they
should do one of two things; 1) inform the client so they can update
any absolute paths any scripts might use that point to their home
directory, or better yet 2) move the account and create a symlink from
the old path to the new one (e.g., ln -s /home2/account /home), so the
paths remain the same. Of course, there's no guarantee the OP will put
their script on a system where someone thought to do that if they did
move data and the $PATH or $HOME variable changed (or needs to be).
Anyway, I never recommended using $HOME.
I do not think "prior notice" matters

See above about what I had meant, and I agree it shouldn't matter.
- should I hunt for all
symlinks which are going to be broken?

Nope, but as a sys admin, it's wise to not assume or force clients to
have to update a bunch of absolute paths in their scripts (for any
number of things) when the sys admin can simply create a link to the
new target so things continue to work as normal (and it takes a single
inode for that symlink, so space/inode issues don't have any
relevance). Anyway, I just responded previously to state that a
symlink solution could work, but that depends on a few variables, just
like most any other solution does. There's not enough information to
suggest that anything in particular will work best for them, but I
agree that symlinks and modifying $HOME isn't what I'd usually
recommend either.
And *when* I'm going to
do this? AND: I do not remember any notice anyway...

I don't know what the above is supposed to mean, but it doesn't really
matter, I'm not arguing with or disagreeing with you about anything
regarding symlinks or modifying $HOME. In fact, I posted previously in
response to say it might work, but it probably wasn't the best
solution. I guess it's been a long year???
 
W

Wanna-Be Sys Admin

l said:
Create a symbolic link for /usr/bin/perl to your non-standard location
and you should then be able to use the correct shebang in your Perl
scripts

Just to update a response on this, I believe I misread this post
earlier. It looks like the user is just a normal account level user on
the system (uid >= 500), so they couldn't modify the perl binary path
to be a symlink to somewhere else, and if they had that power to, they
may as well install the perl binary to just be _at_ /usr/bin/perl (or
whatever default path they use) and not use a symlink, etc. I believe
the issue was they had a unique perl binary built and located in
another path or mount or most likely in the account's own directory
that they upload their script to. It's actually not really clear about
the details of what they need or how it might work (or break), but
either way, it doesn't sound like they have super user access to change
the system installed perl binary or its path.
 
I

Ilya Zakharevich

As opposed to working on code you are responsible for.

You look sure this is what Randal had in mind... I'm not.

Ilya

P.S. Responsibility is transitive; Randal, surely, knows this. If
you decide to use a module, its bugs become your responsibility.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top