I installed Ruby 1.8.2 from backports onto Debian woody (http://people.debian.org/~angdraug/). If I type ruby -v I get: ruby 1.8.2 (2004-07-29) [i386-linux].
If I type which ruby I get: /usr/bin/ruby
The backported packages create ruby1.8, irb1.8, ri1.8 and so forth. I created hard links to each of them without the 1.8 suffixes. There's no ruby1.6 stuff installed.
If I try to run instiki by typing 'ruby instiki' it works just fine. But if I ever try running it as ./instiki I get:
If I try to run instiki by typing 'ruby instiki' it works just fine.
But if I ever try running it as ./instiki I get:
: bad interpreter: No such file or directory
I have the same problem with my ubuntu installation at home, googling
leads me to info about trailing ^M characters at the end of the
"shebang" line(the "#!/usr/bin/ruby" line at the top of the script).
Haven't checked this, though. Try removing any such control characters
at the end of the shebang line and see if it works.
I have the same problem with my ubuntu installation at home, googling
leads me to info about trailing ^M characters at the end of the
"shebang" line(the "#!/usr/bin/ruby" line at the top of the script).
Haven't checked this, though. Try removing any such control characters
at the end of the shebang line and see if it works.
Yup, that's what it is in case of Instiki 0.9.2. My fault.
If I try to run instiki by typing 'ruby instiki' it works just fine.
But if I ever try running it as ./instiki I get:
: bad interpreter: No such file or directory
I have the same problem with my ubuntu installation at home, googling
leads me to info about trailing ^M characters at the end of the
"shebang" line(the "#!/usr/bin/ruby" line at the top of the script).
Haven't checked this, though. Try removing any such control characters
at the end of the shebang line and see if it works.
I think this issue will be fixed in the next Ruby release when you do #!/usr/bin/ruby -w (Might also not occur in it when you have a space after the "ruby", I'm not sure here, but "-w" is a good idea anyway.)
Thanks everyone. I had not touched on the problem until right now, thus the silence.
But you were all right. tr -d '\15\32' on the 'instiki' file and it all worked great.
Once again, thanks a bunch.
···
On Jan 19, 2005, at 2:44 AM, CT wrote:
If I try to run instiki by typing 'ruby instiki' it works just fine.
But if I ever try running it as ./instiki I get:
: bad interpreter: No such file or directory
I have the same problem with my ubuntu installation at home, googling
leads me to info about trailing ^M characters at the end of the
"shebang" line(the "#!/usr/bin/ruby" line at the top of the script).
Haven't checked this, though. Try removing any such control characters
at the end of the shebang line and see if it works.
I think this issue will be fixed in the next Ruby release when you do #!/usr/bin/ruby -w (Might also not occur in it when you have a space after the "ruby", I'm not sure here, but "-w" is a good idea anyway.)
It's not a Ruby problem at all. It's a kernel problem. The trailing ^M on the #! line is causing the part of the kernel's exec() routines that dispatches executable shell scripts to become confused.
The only solution (apart from propogating a kernel patch) is to remove the trailing ^M (carriage return) from the #! line.
I think this issue will be fixed in the next Ruby release when you do #!/usr/bin/ruby -w (Might also not occur in it when you have a space after the "ruby", I'm not sure here, but "-w" is a good idea anyway.)
It's not a Ruby problem at all. It's a kernel problem. The trailing ^M on the #! line is causing the part of the kernel's exec() routines that dispatches executable shell scripts to become confused.
The only solution (apart from propogating a kernel patch) is to remove the trailing ^M (carriage return) from the #! line.
I know what's happening. This can be handled by Ruby in most cases. (The kernel just passes along the trailing \r to Ruby's ARGV.) That's why I suggested adding the -w flag. (So that the Kernel would not try to run the script with an executable called "ruby\r")
I know what's happening. This can be handled by Ruby in most cases. (The kernel just passes along the trailing \r to Ruby's ARGV.) That's why I suggested adding the -w flag. (So that the Kernel would not try to run the script with an executable called "ruby\r")
That solves the "bad interpreter" problem nicely, but leaves ruby with a "-w\r" argument to deal with. As you suggested earlier, if a future version of Ruby handled stray carriage returns in its arguments, then the problem would be resolved.
I know what's happening. This can be handled by Ruby in most cases. (The kernel just passes along the trailing \r to Ruby's ARGV.) That's why I suggested adding the -w flag. (So that the Kernel would not try to run the script with an executable called "ruby\r")
That solves the "bad interpreter" problem nicely, but leaves ruby with a "-w\r" argument to deal with. As you suggested earlier, if a future version of Ruby handled stray carriage returns in its arguments, then the problem would be resolved.
Nobu has done a patch for exactly that when I requested this on ruby-core. So all this is indeed going to be quite a bit less problematic in the future. (I was bitten by this behavior by myself and while it's not Ruby's fault it can still try to help.)