Mailing List Archive

Not that this is any help, but other kernels besides Linux don't
pass #! arguments in full generality. For example, the Irix
system I'm on right now is doing pretty much the same thing.

Part of this is the convention, apparent on both my Linux and
Irix boxes, to pass the name of the script file as argv[2],
which leaves argv[1] stuck with the entire trailing argument
list from the #! line.
--

=======================================================================
I won't rest till it's the best ... Software Production Engineer
Paul Jackson (pj@sgi.com; pj@usa.net) 3x1373 http://sam.engr.sgi.com/pj

Martin,

I'm not a big fan of the /usr/bin/env approach for Python scripts,
because at PARC many people run without having Python on their paths.
Many, many packages at PARC, including Python and ILU, are installed in
their own directory tree under either /project (/project/ILU/) or
/import (/import/python-1.5/). People enable or disable various
packages depending on what they're up to.

So I tend to depend on GNU configure when I'm installing a script. I
actually look for Python in the user's environment, then use sed to
hard-code that path into the scripts before installing them. Can this
be done with RPM?

Bill

>
> So I tend to depend on GNU configure when I'm installing a script. I
> actually look for Python in the user's environment, then use sed to
> hard-code that path into the scripts before installing them. Can this
> be done with RPM?

Sure, since RPM is just a series of sh scripts that run while installing a
package. You could put something in the %post section that did this.
Then the scripts would be set up for whoever ran the rpm command, but not
anyone who didn't have this same enviroment. This would imply multiple
rpm databases on a single system for different users. I'm not familiar
with using RPM in this way but I bet it could be done...

Travis

In article <cr5yCYgB0KGWFEglFo@holmes.parc.xerox.com>,
Bill Janssen <janssen@parc.xerox.com> wrote:
>
>I'm not a big fan of the /usr/bin/env approach for Python scripts,
>because at PARC many people run without having Python on their paths.
>Many, many packages at PARC, including Python and ILU, are installed in
>their own directory tree under either /project (/project/ILU/) or
>/import (/import/python-1.5/). People enable or disable various
>packages depending on what they're up to.
>
>So I tend to depend on GNU configure when I'm installing a script. I
>actually look for Python in the user's environment, then use sed to
>hard-code that path into the scripts before installing them. Can this
>be done with RPM?

Back when I was working at a software company with a real build
environment, we had a system where we used shell scripts to call Perl
and make scripts. You can do some pretty sophisticated parsing in a
shell script; up to you whether you want to do the perverse option of
installing a global python that system calls other python scripts....

I really loathe hard-coded paths unless they're truly global.

(Let me know if this isn't clear.)
--
--- Aahz (@netcom.com)

Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/
Androgynous poly kinky vanilla queer het

Sometimes, you're not just out of left field, you're coming in
all the way from outer space.

Bill Janssen wrote:

> Martin,

Hi,

> I'm not a big fan of the /usr/bin/env approach for Python scripts,
> because at PARC many people run without having Python on their paths.
> Many, many packages at PARC, including Python and ILU, are installed in
> their own directory tree under either /project (/project/ILU/) or
> /import (/import/python-1.5/). People enable or disable various
> packages depending on what they're up to.
>
> So I tend to depend on GNU configure when I'm installing a script. I
> actually look for Python in the user's environment, then use sed to
> hard-code that path into the scripts before installing them. Can this
> be done with RPM?

Actually I do use autoconf ... but when building a RPM file, you use
rpm -ba <specfile> ... then it creates RPMS and SRPMS by doing the
usualy configure;make;make install (when specified) ... on my own
machine every occurence of python is been replaced by
/usr/local/bin/python
and the RPM is built with that path ... and therefor the final
RPM requires /usr/local/bin/python ... and that's what I want to
avoid, so I thought about the /usr/bin/env solution ...

Martin

--
Martin Preishuber - Student, ECLiPt Core Member, SysAdmin
http://eclipt.uni-klu.ac.at,
mailto:Martin.Preishuber@stuco.uni-klu.ac.at

Badges? We don't need no stinking badges.

> (I need the -u for unbuffered output) but when creating RPM files the
> final rpms needs /usr/local/bin/python.

How about a hack like this:

import sys

class UnbufferedStdout:
def __init__(self, stdout):
self.stdout = stdout
def write(self, arg):
self.stdout.write(arg)
self.stdout.flush()

sys.stdout = UnbufferedStdout(sys.stdout)

--------------------------------------------
Adrian Eyre <mailto:a.eyre@optichrome.com>
Optichrome Computer Solutions Ltd
Maybury Road, Woking, Surrey, GU21 5HX, UK
Tel: +44 1483 740 233 Fax: +44 1483 760 644
http://www.optichrome.com
--------------------------------------------