44202 - Easily replace /usr/bonsaitools/bin/perl with your perl path

Status: VERIFIED DUPLICATE of bug 44659

(Bugzilla :: Installation & Upgrading, enhancement)

Description

[Andreas Franke (gone)]

Here is a shell script "setperl" that replaces /usr/bonsaitools/bin/perl with
the real location of perl in all executables in the bugzilla directory. This
makes the link obsolete, which is especially useful if you want to try out
bugzilla, but do not have root access to your machine. (You can compile and
install your own perl without being root).

Preconditions:
- /bin/tcsh
- setperl is located in the main bugzilla directory
- and executable

Usage:
> ./setperl /your/absolute/path/to/perl

Notes:
- "setperl" modifies itself, so that it can be used multiple times 
  (if the location of perl changes again)
- The script tries hard to prevent any data loss, but of course there is 
  NO WARRANTY of any kind. 
- I have no idea if this script introduces any security holes.

Maybe something like this could be included in the bugzilla distribution.
Any feedback is welcome.

Comment 1

[Andreas Franke (gone)]

Attachment: setperl -- change the path to perl in bugzilla scripts

Comment 2

[James Bercik]

the command 

/usr/bin/replace -v '/usr/bonsaitools/bin/perl'  '/your/path/perl' -- *.cgi

should work as well if run inside the bugzilla source directory

Comment 3

[Andreas Franke (gone)]

You are referring to the replace utility that comes with mysql?
Ok, if it's that easy, then the documentation should mention this example. 

Comment 4

[Tak]

Found this in the newsgroup:

From: [e-mail] (Abhinandan Jain)

Using the following incantation (instead of the hard-wired path to the
perl binary) at the top of each script will also do the trick.

: # -*- perl -*-
eval 'exec perl -S $0 ${1+"$@"}'
    if 0;

I believe this is described some place in the Perl docs. This lines
will cause the script to be run using the perl binary found in your path 
environment variable. This will avoid the hacks needed to update
all the scripts with the location of the perl binary.

Abhi

Comment 5

[Rémi Perrot]

the Makefile provide with the bug 44649 change the perl path to what ever you
want at install time

Comment 6

[Andreas Franke (gone)]

Yes, probably that's true. The Makefile bug is bug 44659, however.

Comment 7

[Chris Yeh]

consideration for 2.12

Comment 8

[Zach Lipton [:zach]]

I like the idea of using the 

: # -*- perl -*-
eval 'exec perl -S $0 ${1+"$@"}'
    if 0;

line because I don't think a makefile works on NT and we shouldn't make 
the NT process any harder. Also, We shouldn't add any new steps to the 
install, it is hard enough as it is. Also, this has no requirements while 
setperl requires tcsh and making it executable. I am uploading a patch 
that uses this line.

Comment 9

[Zach Lipton [:zach]]

Attachment: My patch

Comment 10

[Andreas Franke (gone)]

Zach, some remarks and questions:

- This bug is not about the makefile. That's bug 44659, and currently it has 20
votes, so it's better to discuss any possible issues with it in that bug. Of
course a makefile would make this RFE obsolete.

- Currently setperl indeed requires tcsh, but I'm sure that it is no problem to
rewrite it for sh which is standard on every unix system.

- Currently setperl has to be executable, but if this is something that would
prevent its usage then a special case can be added to work around that. One
would then call it instead as follows:
	source setperl /your/path/to/perl
I just don't want to spend any time on these things if its not used anyway.

- The "magic header" looks very interesting. Does it work on Windows?

- The "magic header" requires perl to be in the $PATH when the CGI scripts are
executed by the web server. I found that this is the case at our site, but is
there an agreement among administrators that this should be the case everywhere?

- The perl version that is in the $PATH at our site is 5.003, but bugzilla
requires 5.004 or greater. What should be done in this case where one has to
deal with different versions of perl in one and the same environment?

- Finally two questions about your patch: Is there a reason why you remove the
"indent-tabs-mode: nil" from various files? 

- Maybe the change of the accept/assigned-to stuff should be factored out?

Comment 11

[Zach Lipton [:zach]]

hmm. I think that it works on windows, but I am not sure about that. The 
accept stuff was stuck in my local tree and made it into the patch by 
mistake. After you mention those problems with the patch, I think we are 
better off using the makefile or the setperl script. Maybe we can embed 
the setperl script in checksetup.pl. Have users change the path to perl in 
that file, and have checksetup.pl prompt the user for the location of perl 
that they want to use.

Comment 12

[Dave Miller [:justdave]]

The problem with having two different Perl installations on the same machine is 
exactly the reason it has the weird path that it does now.  Because mozilla.org 
fits that situation, and it was originally written for them.  The Perl that's in 
their environment PATH isn't the one that they want to run it under, so it has 
the weird path to the correct one.

Comment 13

[Chris Yeh]

I agree with Dave. There have been situations where the native perl on a 
platform is screwed up and we have to use a different version of perl on a given 
system. Depending upon the implementation, you might not want to use the primary 
version of perl and you might want to tightly control the execution and perl 
modules that get installed.

I would be more inclined to provide a little script or something that goes and 
does the stupid thing and changes the path for each file. 

Dropping this from 2.12. Time to start dropping things that are non-essential. 
We can ship without this.

Comment 14

[Andreas Franke (gone)]

Chris,

> I would be more inclined to provide a little script or something that goes and 
> does the stupid thing and changes the path for each file.

This is exactly what this bug is about. See my attachment from 6/29 in this bug.
Of course we can ship without this, but I'm really interested to know if there
are any problems with the existing "setperl" script (besides that it requires
tcsh).

Comment 15

[Chris Yeh]

Sorry, I only looked at zach's patch. Let me take a look at yours.

Comment 16

[Jacob Steenhagen]

Just a couple of comments:
 1. Wouldn't this be better done in Perl.  Perhaps integrated into checksetup.pl
 2. Does the script really need to know the old perl path?  Unix will use
    whatever the first line of the script is (w/the #!) as the interpeter so
    just replace the first line of *.cgi w/$newperl.
 3. There should be some kind of warning about doing this will mess up any DIFFs
    if you plan to submit patches to Mozilla.org.

Comment 17

[Andreas Franke (gone)]

1. Probably this could be done in perl. Then you run it as "perl setperl.pl",
and you don't include any "#! ..." magic in setperl.pl. Correct?
2. Probably you're right. Using "sed -e 's/.../.../g'" just was the simplest
thing I could think of, and that required to know the old path.
3. Yes, the documentation should warn about messing up diffs.

Jake (and others), please feel free to write a perl version, or an improved
shell script version. I don't know enough perl to do this, and I don't have the
time anymore. Chris, can you comment whether a perl script would be better than
(or at least as good as) a shell script?

Comment 18

[Stephan Niemz]

Some comments:

The csh (and its derivatives) is really a bad shell for writing scripts. See
http://www.landfield.com/faqs/unix-faq/shell/csh-whynot/ for the reasons.

The eval exec perl trick has one disadvantage: the script is fist started with
some shell, then the shell execs perl to reparse the script.  This means one
excess exec and some additional overhead because the shell also needs to parse
the file, or at least the first few lines.  All in all, it slows everything
down, since these scripts are run really often on bugzilla.mozilla.org.

I think the right thing would be to let checksetup.pl do this. But then one
would get problems when using the Bugzilla scripts directly from a cvs checkout,
because after substituting the perl line, CVS would always consider them locally
modified when doing an update or diff.  Anyone who would like to submit patches
or do checkins wouldn't want these substitutions then.

Removing patch keyword because I think this should be rethought.

Comment 19

[Dave Miller [:justdave]]

Moving to real milestones...

Comment 20

[Andreas Franke (gone)]

If you do not like tcsh scripts, feel free to rewrite them in sh or perl.

Re-adding patch keyword. Please leave it to the Bugzilla module owner to remove
this keyword. After all, this is a _working_, possibly _useful_ script.
It's not the perfect solution, but as long as there's no better solution
available, I'd prefer the keyword to stay.

Comment 21

[Andreas Franke (gone)]

To use the setperl script on a fresh 2.12 checkout, do the following:

1. Download 'setperl' to your bugzilla dir and make it executable (if you don't 
   have wget, you have to download it manually):

cd /your/path/to/bugzilla
wget -O setperl 'http://bugzilla.mozilla.org/showattachment.cgi?attach_id=10795'
chmod u+x setperl

2. Prepare (and fix) bugzilla file permissions:

chmod u+w *
chmod u+x duplicates.cgi
chmod a-x bug_status.html

3. Run the script:

./setperl /your/path/to/perl

4. Reset bugzilla file permissions if you think that's necessary:

chmod u-w *

I have tested this with a current bugzilla checkout.

I belive the last two steps of part (2.) are bugs in bugzilla though.

Comment 22

[Hixie (not reading bugmail)]

In Bugzilla 3.0 there will only be one executable, so there will only be one
shebang line, so the whole point will be moot... good discussion here, though!
:-)

Comment 23

[Hixie (not reading bugmail)]

Taking all Bugzilla 3.0 bugs -- congratulations to MattyT for the triage, it
really was spot on. Note: I may end up pushing some of these bugs back to 3.2,
we'll see. However, I believe all these bugs should just fall out of the 
redesign. Let's hope I'm right!

(Note: I'm also resetting the priority field to "---" so that I can retriage any
that I consider important or likely to be dropped.)

Comment 24

[Matthew Tuck [:CodeMachine]]

If there's only one executable, then we're going to break bookmarks.  Wouldn't
it be nice to have backwards compatibility cgis into the main stuff?

Comment 25

[Hixie (not reading bugmail)]

We are going to break a LOT more than bookmarks. ;-)

But seriously, bookmarks would be fixed by judicious use of HTTP redirects.
I expect the standard distribution will come with a default .htaccess file for
Apache servers, and similar configuration files for other servers.

Comment 26

[Matthew Tuck [:CodeMachine]]

How can a set of static redirects work in the face of parameters?  We can't
enumerate them all, so does that mean you're going to continue to support the
old parameters?

Comment 27

[Hixie (not reading bugmail)]

MattyT: Yes. If the input is in the Bugzilla 2.x form, then that will kick in a
different input module which will do translation into the new command set.

Comment 28

[Lilly]

Attachment: Changes perl paths in MS-DOS

Comment 29

[Lilly]

Please ignore the previous patch.. I'll clean it up and resubmit.. 

Comment 30

[timeless]

please consider perl :)
dir /s /b *.* | perl -i.bonsai -p -e "s#%oldpath%#%newpath%#"
[the preceding is untested]
then someone would just set oldpath and newpath.

Comment 31

[Lilly]

Attachment: Replaces oldpath newpath

Comment 32

[Lilly]

Attachment: Replaces oldpath newpath

Comment 33

[timeless]

reassigning to bugzilla classic because the work here is for classic.

Comment 34

[David D. Kilzer (ddk)]

See also Attachment 45265 [details] [diff] in Bug 44659 for another fix.

Comment 35

[Andreas Franke (gone)]

-> Bugzilla product, Installation component, reassigning.

Comment 36

[Andreas Franke (gone)]

Since all the patches here (and there are several) are for the 2.x version,
changing milestone from 3.0 to 2.16 to get it back on the radar.

Quoted from http://scarab.tigris.org/scarab-design.html#features :
> The problem [with Bugzilla] is that this has been done on top of a poorly
> designed base which is not only hard to setup and configure (the first thing
> you have to do is change the path to the Perl executable in each and every
> file!), but also hard to customize the look and feel of because much of the
> look and feel is hard coded in Perl code.
The exclamation mark is not from me, but from the author of the quoted document.

Comment 37

[Jacob Steenhagen]

The author of that file exagerates (it's much eaier to set up a sym-link than it
is to change every file, and the docs state that quite clearly.  Even if you
don't have direct control of the /usr directory [ie root access] to the machine
in question, you can still request that the server's admin set up this link for
you [it's not difficult to do, and create no security holes/problems]).

Also, I've dealt with a commercial perl application that suffers from the same
problem.  For every upgrade, you have to go into every .pl file and set the perl
path (unless you have perl installed at the location it defaults to). 
Furthermore, if you're running it on NT (which is officially supported by this
particular app), you have to go into *.pl and set a path for it to dump into a
"use lib" (IIRC) line.  Mind you, this is an app that we paid money for, and a
signifigant chunk of change at that.

Comment 38

[Andreas Franke (gone)]

Tell that to the scarap people :) You're completely right, although in my case I
didn't have root access, and maybe you know that sysadmins are often busy all
the time... (see e.g. mozilla.org's server admins: after 9 months they still
haven't been able to change the newsgroup structure). So when you are trying to
play with Bugzilla over the weekend, you have exactly this problem.

Comment 39

[Dave Miller [:justdave]]

This will be taken care of in bug 44659, which is the route we're going.

Comment 40

[Zach Lipton [:zach]]

This is 44659 since (as per dave's comment) the Makefile.pl will take care of
this. Please move all discussion over to 44659 about the makefile.

Move along, nothing to see here

*** This bug has been marked as a duplicate of 44659 ***

Comment 41

[Dave Miller [:justdave]]

clearing milestone for invalid/wontfix/worksforme/duplicate so they'll show up
as untriaged if they get reopened.

Comment 42

[Matt Perry]

Verified dupe