FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Debian > Debian User

 
 
LinkBack Thread Tools
 
Old 02-08-2008, 08:02 PM
ChadDavis
 
Default wrapper script issue

I've started using wrapper scripts to set environment variables that are required by individual applications, as per the debian policy manual.* I've encountered a problem that seems to arise out of some difference between using the wrapper script and hitting the binary directly.* It involves a ruby script, but I don't think that matters at all.* Its probably just a common sense scripting thing.* Here's the story. *


First of all, I have wrapped my ruby binary in wrapper script as just indicated.* the wrapper script is called "ruby1.8" and here's the contents:

#!/bin/sh
export RUBYOPT=rubygems

exec /etc/alternatives/ruby1.8 "$@"

I'm trying to execute the following ruby script, matz.rb

#!/usr/bin/ruby1.8
puts "Hello, Matz!"

If I execute this script with explicit command line use of the ruby wrapper script, such as:


me@myhost:~/temp/rubyTest$ ruby1.8 matz.rb

everything works fine!

The problem arises when I try to take advantage of the shebang notation to invoke the ruby script with out explicit command line invocation of the ruby binary, ala:


me@myhost:~/temp/rubyTest$ matz.rb

results in:

./matz.rb: line 2: puts: command not found


What am I missing here?

BTW, I originally posted this to the forums.debian.net but did not receive any response.* Does this count as cross posting?* If so, I apologize.
 
Old 02-08-2008, 08:40 PM
Ken Irving
 
Default wrapper script issue

On Fri, Feb 08, 2008 at 02:02:30PM -0700, ChadDavis wrote:
> First of all, I have wrapped my ruby binary in wrapper script as just indicated.
> the wrapper script is called "ruby1.8" and here's the contents:
>
> #!/bin/sh
> export RUBYOPT=rubygems
> exec /etc/alternatives/ruby1.8 "$@"

Do you really want to quote the argument list?

> I'm trying to execute the following ruby script, matz.rb
>
> #!/usr/bin/ruby1.8
> puts "Hello, Matz!"

Not likely the problem, but I'd suggest putting your wrapper into
/usr/local/bin/, or somewhere other than /usr/bin/, so that it doesn't
risk colliding with packaged software. I have a /usr/bin/ruby1.8
on my system, and it's clearly not your wrapper. Or maybe I'm just
misunderstanding something...

> If I execute this script with explicit command line use of the ruby wrapper
> script, such as:
>
> me@myhost:~/temp/rubyTest$ ruby1.8 matz.rb
>
> everything works fine!

My guess is that it would not work if matz.rb was given an argument, since
it would then look like

me@myhost:~/temp/rubyTest$ ruby1.8 "matz.rb arg".

> The problem arises when I try to take advantage of the shebang notation to invoke
> the ruby script with out explicit command line invocation of the ruby binary,
> ala:
>
> me@myhost:~/temp/rubyTest$ matz.rb
>
> results in:
>
> ./matz.rb: line 2: puts: command not found
>
> What am I missing here?

I don't know, but would suggest adding some simple debug statements
to your wrapper and other scripts to check and make sure you're doing
what you think you're doing.

--
Ken Irving, fnkci+debianuser@uaf.edu


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-08-2008, 08:58 PM
ChadDavis
 
Default wrapper script issue

> #!/bin/sh
> export RUBYOPT=rubygems

> exec /etc/alternatives/ruby1.8 "$@"

Do you really want to quote the argument list?

I got that directly from the debian policy manual example.* I didn't do it for any real reason.* I'm not scripter, so I'm unaware of how this would impact stuff.

*I'd suggest putting your wrapper into
/usr/local/bin/, or somewhere other than /usr/bin/, so that it doesn't

risk colliding with packaged software. *I have a /usr/bin/ruby1.8
on my system, and it's clearly not your wrapper. *Or maybe I'm just
misunderstanding something...


I did install ruby1.8 with apt, and it put the ruby1.8 binary in that location.* The wrapper, as I said, is suggested by the debian policy manual as the way to set a environment variable that you want set for that application.*

*
 
Old 02-08-2008, 09:27 PM
Ken Irving
 
Default wrapper script issue

On Fri, Feb 08, 2008 at 02:58:04PM -0700, ChadDavis wrote:
>
> > #!/bin/sh
> > export RUBYOPT=rubygems
> > exec /etc/alternatives/ruby1.8 "$@"
>
> Do you really want to quote the argument list?
>
> I got that directly from the debian policy manual example. I didn't do
> it for any real reason. I'm not scripter, so I'm unaware of how this
> would impact stuff.

Maybe it's ok, then. I guess exec will see "$@" as a single string (with
any/all whitespace preserved), but ruby1.8 will see the unquoted args.
Quoting command line arguments is one thing that drove me away from
MSDOS years ago to Linux, where it's done more sensibly, but I still
get confused...

> I'd suggest putting your wrapper into
> /usr/local/bin/, or somewhere other than /usr/bin/, so that it doesn't
> risk colliding with packaged software. I have a /usr/bin/ruby1.8
> on my system, and it's clearly not your wrapper. Or maybe I'm just
> misunderstanding something...
>
> I did install ruby1.8 with apt, and it put the ruby1.8 binary in that
> location. The wrapper, as I said, is suggested by the debian policy
> manual as the way to set a environment variable that you want set for
> that application.

Then I probably am not following what you're doing. You don't show the
shebang lines in this message, but I thought you wanted your application
to use a custom wrapper script, and not run the packaged ruby1.8 directly.
On my system /usr/bin/ruby1.8 is a binary, and not a shell script as I
thought you were showing.

Ken

--
Ken Irving, fnkci+debianuser@uaf.edu


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-08-2008, 09:31 PM
ChadDavis
 
Default wrapper script issue

Then I probably am not following what you're doing. *You don't show the

shebang lines in this message, but I thought you wanted your application
to use a custom wrapper script, and not run the packaged ruby1.8 directly.
On my system /usr/bin/ruby1.8 is a binary, and not a shell script as I

thought you were showing.


I replaced the ruby1.8 binary, in /usr/bin, with a wrapper script that sets an environment variable and then invokes the binary, which I moved to /etc/alternatives ( perhaps not exactly the way alternatives is meant to be used, but I'm kind of a noob )


Here's the wrapper script:

#!/bin/sh
export RUBYOPT=rubygems

exec /etc/alternatives/ruby1.8 "$@"


This script is at /usr/bin/ruby1.8*

Let me know if I'm doing something bizarre.* It's actually my effort at doing things the *right* way, so any advice would be accepted and welcomed.*
 
Old 02-08-2008, 09:41 PM
Bob McGowan
 
Default wrapper script issue

Ken Irving wrote:

On Fri, Feb 08, 2008 at 02:02:30PM -0700, ChadDavis wrote:
First of all, I have wrapped my ruby binary in wrapper script as just indicated.
the wrapper script is called "ruby1.8" and here's the contents:


#!/bin/sh
export RUBYOPT=rubygems
exec /etc/alternatives/ruby1.8 "$@"


Do you really want to quote the argument list?


Yes, he does. If the wrapper is run as:

ruby1.8 myscript "this is a test" 'a variable named $one'

The arguments need to be passed 'as is' to the script. Without the
quotes, both $@ and $* present the full argument list, _without_ any
quoting:


this is a test a variable named $one

Which means at least 8 arguments, one of which is a variable that may
now expand into nothing, or another list of one or more items.


Quoting $* passes a single long argument, which is what I think you're
thinking of:


"this is a test a variable named $one"

In this case, one long argument, with the $one being expanded.

Quoting $@ passes the arguments _with the same quoting as used
originally_, so:


ruby1.8 myscript "this is a test" 'a variable named $one'

executes:

/etc/.../ruby1.8 myscript "this is a test" 'a variable named $one'

Which is exactly what is needed with a wrapper. Two arguments and $one
is left alone.





I'm trying to execute the following ruby script, matz.rb

#!/usr/bin/ruby1.8
puts "Hello, Matz!"


Not likely the problem, but I'd suggest putting your wrapper into
/usr/local/bin/, or somewhere other than /usr/bin/, so that it doesn't
risk colliding with packaged software. I have a /usr/bin/ruby1.8
on my system, and it's clearly not your wrapper. Or maybe I'm just
misunderstanding something...


If I execute this script with explicit command line use of the ruby wrapper
script, such as:

me@myhost:~/temp/rubyTest$ ruby1.8 matz.rb

everything works fine!


My guess is that it would not work if matz.rb was given an argument, since
it would then look like


me@myhost:~/temp/rubyTest$ ruby1.8 "matz.rb arg".


Actually, putting arguments in made no difference when I tried it, the
puts worked in the one case and not the other.


ruby1.8 matz.rb arg

Printed the string and seems to ignore the argument value.




The problem arises when I try to take advantage of the shebang notation to invoke
the ruby script with out explicit command line invocation of the ruby binary,
ala:

me@myhost:~/temp/rubyTest$ matz.rb

results in:

./matz.rb: line 2: puts: command not found

What am I missing here?


I don't know, but would suggest adding some simple debug statements
to your wrapper and other scripts to check and make sure you're doing
what you think you're doing.



Breaking down the processing being done may help. You type:

$ matz.rb

Which then becomes:

/usr/bin/ruby1.8 /path/to/script/matz.rb

The question then is, what is /usr/bin/ruby1.8? On my system, it looks
like the binary ruby executable (with ruby set up as a symlink to it).


So, what is the file /etc/alternatives/ruby1.8? Everything in
/etc/alternatives on my system (except for README) is a symlink pointing
back to /usr/bin/... or /usr/share/man/.../... or ...


So, I guess the questions are:

1. Do you have a /usr/bin/ruby1.8 and is it a binary file (about 3336
bytes)?


2. Does /etc/alternatives/ruby1.8 exist and what type of file is it?

3. Where is your wrapper script ruby1.8 located?

4. And, if both the wrapper ruby1.8 and /usr/bin/ruby1.8 exist, in
different places, and your wrapper is executable, which of the two is
being found in the PATH search?


--
Bob McGowan
Symantec, Inc.
 
Old 02-08-2008, 09:47 PM
Bob McGowan
 
Default wrapper script issue

ChadDavis wrote:



Then I probably am not following what you're doing. You don't show the
shebang lines in this message, but I thought you wanted your application
to use a custom wrapper script, and not run the packaged ruby1.8
directly.
On my system /usr/bin/ruby1.8 is a binary, and not a shell script as I
thought you were showing.



I replaced the ruby1.8 binary, in /usr/bin, with a wrapper script that
sets an environment variable and then invokes the binary, which I moved
to /etc/alternatives ( perhaps not exactly the way alternatives is meant
to be used, but I'm kind of a noob )


Here's the wrapper script:

#!/bin/sh
export RUBYOPT=rubygems
exec /etc/alternatives/ruby1.8 "$@"


This script is at /usr/bin/ruby1.8

Let me know if I'm doing something bizarre. It's actually my effort at
doing things the *right* way, so any advice would be accepted and
welcomed.


Putting the original executable in /etc/alternatives is not a good idea.
The script you put in /usr/bin may get overwritten at some point, with
a security update, but still be at version 1.8, so you'd end up without
your wrapper, at least, and perhaps still running the binary you moved,
without the fix.


I'd also ask, which I forgot in my first response to your question, is
this something that needs to be done for all users on your system or is
it a personal script?


I think the Debian policy in this case would guide you only if what
you're doing is for all users of the system. If you're doing this for
yourself, most UNIX/Linux users I know would create an alias or function
to do it, in their own work space (~/bin, ~/.aliases, etc).


--
Bob McGowan
Symantec, Inc.
 
Old 02-08-2008, 09:58 PM
Ken Irving
 
Default wrapper script issue

On Fri, Feb 08, 2008 at 03:31:54PM -0700, ChadDavis wrote:
>
> Then I probably am not following what you're doing. You don't
> show the shebang lines in this message, but I thought you wanted
> your application to use a custom wrapper script, and not run the
> packaged ruby1.8 directly. On my system /usr/bin/ruby1.8 is a
> binary, and not a shell script as I thought you were showing.
>
> I replaced the ruby1.8 binary, in /usr/bin, with a wrapper script that
> sets an environment variable and then invokes the binary, which I
> moved to /etc/ alternatives ( perhaps not exactly the way alternatives
> is meant to be used, but I'm kind of a noob )
>
> Here's the wrapper script:
>
> #!/bin/sh
> export RUBYOPT=rubygems
> exec /etc/alternatives/ruby1.8 "$@"

> This script is at /usr/bin/ruby1.8
>
> Let me know if I'm doing something bizarre. It's actually my effort at doing
> things the *right* way, so any advice would be accepted and welcomed.

It sounds bizarre to me. I think you mentioned following some directions
somwehere, so maybe you missed something? I don't have /etc/alternatives/ruby1.8
on my system; what does it point to? It's probably a symlink, or maybe a chain
of several, and it wouldn't suprise me if it pointed back to /usr/bin/ruby1.8.

I'd say that any time you're messing around in /usr/bin/ replacing things
you ought to know what you're doing, or you're there's a good chance
you're going to break your system. If you want a viable system, then
leave that and other system directories alone, and put your customized
stuff in /usr/local/bin/ or equivalent, perhaps ~/bin/, etc. But I'm
repeating myself...

--
Ken Irving, fnkci+debianuser@uaf.edu


--
To UNSUBSCRIBE, email to debian-user-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
 
Old 02-08-2008, 10:08 PM
Bob McGowan
 
Default wrapper script issue

Bob McGowan wrote:

Ken Irving wrote:

On Fri, Feb 08, 2008 at 02:02:30PM -0700, ChadDavis wrote:
First of all, I have wrapped my ruby binary in wrapper script as just
indicated. the wrapper script is called "ruby1.8" and here's the


< elided stuff >


So, I guess the questions are:

1. Do you have a /usr/bin/ruby1.8 and is it a binary file (about 3336
bytes)?


2. Does /etc/alternatives/ruby1.8 exist and what type of file is it?

3. Where is your wrapper script ruby1.8 located?

4. And, if both the wrapper ruby1.8 and /usr/bin/ruby1.8 exist, in
different places, and your wrapper is executable, which of the two is
being found in the PATH search?




So, my questions got answered, even as I was sending them. What you
have, then, is this:


$ matz.rb
generates:
/usr/bin/ruby1.8 /path/to/script/matz.rb # wrapper
generates
/bin/sh /usr/bin/ruby1.8
does:
export variable
exec /etc/alternatives/ruby1.8 /usr/bin/ruby1.8

The only place the original file gets mentioned is at the very
beginning, it does not pass through to the real ruby1.8 command.


So, what does ruby do when it sees a file with "#!/bin/sh" at the
beginning, let alone the 'exec' line?


I really can't say what exactly is letting things get back to the 'puts'
in the original script file, what I can say is this setup looks to me
like it won't work. Of course, this assumes my analysis is correct.


I'll be mulling this over, I'm sure, I can't let a good problem like
this rest So, hopefully sooner than later, it will get solved.


--
Bob McGowan
Symantec, Inc.
 
Old 02-08-2008, 10:09 PM
ChadDavis
 
Default wrapper script issue

Putting the original executable in /etc/alternatives is not a good idea.

*The script you put in /usr/bin may get overwritten at some point, with
a security update, but still be at version 1.8, so you'd end up without
your wrapper, at least, and perhaps still running the binary you moved,

without the fix.

I'd also ask, which I forgot in my first response to your question, is
this something that needs to be done for all users on your system or is
it a personal script?

I think the Debian policy in this case would guide you only if what

you're doing is for all users of the system. *If you're doing this for
yourself, most UNIX/Linux users I know would create an alias or function
to do it, in their own work space (~/bin, ~/.aliases, etc).


Looks like I have more than one issue.* I'd like to get this issue of the best way to create and locate the wrapper script out of the way first.*


>From you are saying, I guess I would leave the /usr/bin/ruby1.8 alone, as installed.* Then, in order to make sure that the environment variable I want set get's set every time ANYONE in the system invokes ruby, I'd make a wrapper script and place it where?* In /usr/local/bin* ?* This seems like a great idea.* I was only referring to debian policy's recommendations on how to handle the application specific environment variable with a wrapper script, not the location of the wrapper script, about which I read nothing in the policy manual.* Perhaps because anyone with experience would know where to put it.* Anyhow, does this scenario seem like a good idea, as far a the location of the wrapper script goes, considering i want the env variable set for all users invoking ruby?
 

Thread Tools




All times are GMT. The time now is 08:59 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org