I am trying to run gcc from a ruby script and it gives me an error which says Permission denied.
It works fine when running it right from the commandline and that makes me clueless why it won't work from ruby.
I can call other commands like "ls" from within Ruby.
I also tried setting the file permissions of gcc to 777 as well as making my user-account the owner of that file.
Here is my shell output:
Administrator#dominicgraec8aa ~
$ gcc
gcc: no input files
Administrator#dominicgraec8aa ~
$ irb
irb(main):001:0> `gcc`
Errno::EACCES: Permission denied - gcc
from (irb):1:in ``'
from (irb):1
irb(main):002:0> `ls`
=> ""
I hope anyone has an idea on this.
From my experience it doesn't matter what path separator you use in Ruby on Windows as they both should work (and as they both work on the command line as well). When working with two different environments (Native Windows and Cygwin) it is good to make sure that you know which version you are running, since they are not necessarily compatible with each other.
I've had no problems running the native Windows versions of the Ruby toolchain, even using Pik too (like RVM for Windows), and I find it much simpler than having to manage two environments.
Related
I'm trying to set up a Ruby dev environment on Windows. So far it's fairly "vanilla", that is, it pretty much only consists of Ruby (1.9.1), Bundler (1.3.5) and a few random gems.
Now, whenever I try to run Bundler, I get the following exception:
C:/Ruby19/lib/ruby/1.9.1/rubygems/user_interaction.rb:544:in `initialize': Permission denied - /dev/null (Errno::EACCES)
Checking the source code, I found that Bundler determines that you're running Windows by trying to access /dev/null and then rescuing Errno::ENOENT ("No such file or directory"). I tried patching it to also rescue Errno:EACCES ("Permission denied"), and voila - it seems to run just fine.
I tried running the shell in elevated mode, but it still threw Errno:EACCES.
My question is simply this: Am I missing something? Or is this a bug in Bundler?
(for reference, I'm running on Windows 8)
/dev/null is a special file and is typically used for disposing of unwanted output streams of a process, or as a convenient empty file for input streams in *nix operating systems. It's not there in Windows.
If bundler is not checking on which operating system it's trying to use /dev/null then surely it's a problem at their end. To get things working without moving much you can use Cygwin.
I'm running on Windows 7.
I'v observed the issue "Errno:EACCES ("Permission denied")" for c:/dev/null
The directory c:/dev created (no "null" file) and problem resolved.
I was having trouble getting jekyll to work with Ruby using cygwin on Windows 7 64-bit. I had better results using rubyinstaller + devkit. It would be really nice if I could use the rubyinstaller ruby inside of cygwin.
However, I get the following message when I try to execute rake.
$ rake page name="pages/about.md"
C:\Ruby193\bin\ruby.exe: No such file or directory -- /cygdrive/c/Ruby193/bin/rake (LoadError)
Is there any way to make rubyinstaller play nice with cygwin?
I just put a few of these in my .bash_profile:
alias gem=gem.bat
alias irb=irb.bat
alias rake=rake.bat
I never have any of the problems that Luis mentions.
The problem is cygwin converting all the scripts paths into cygwin paths (/cygdrive/...).
There is no solution for that since the invoke of the script is made from bash over rake scrip which invokes native Ruby.
There are a lot of other issues that cygwin will cause, and some are covered in RubyInstaller troubleshooting page
One alternative will be invoking rake.bat directly, skipping cygwin shebang detection.
But cygwin doesn't like batch files, which forces you to do cmd.exe /C rake.bat and that is a noisy command line.
The other alternative is install something like gem-exefy (gem install gem-exefy) and generate executables for your installed gems (rake.exe).
That way you invoke rake.exe instead of letting cygwin figure it out.
Another alternative is use MSYS Bash (included in DevKit) instead of cygwin, which plays way better than cygwin one, but you will still have issues with batch files.
As you can see, mixing non-native (cygwin) with native (RubyInstaller) have a lot of side-effects.
I wrote this script https://gist.github.com/1313611 to ease my installs for rvm. The whole script simply installs rvm, installs 1.9.2, rails and creates a default gemset. All of that works and I can verify that inside the .rvm folder. However after installing a I get:
bash: ~/.rvm/scripts/rvm: line 14: syntax error near unexpected token `do'
bash: ~/.rvm/scripts/rvm: line 14: ` do'
I've also tried using curl -sB. I'm guessing it has to do with my environment but can't seem to figure out the problem (obviously, ha).
Thanks for any input
CLARIFICATION: I'm on an Fedora 14 Desktop - I have it working with no edits to my script on a shared hosting account at Dreamhost.
Not sure it helps (planning to dig into a bit more) but the computer it fails on is managed by the school which means the Home dir I install to is on NFS. Another environment oddity is that the default shell (ypchsh won't let me change yet [working with boss to change]) is tcsh, but I always run bash when I open a terminal. I'm thinking this last bit is a problem.
BLAST - Apparently there was a script being loaded that is basically a universal bashrc for our school where someone set and alias to 'for' because it had something to do with fortran.
So I just copied that rc to my directory to fix up that alias and now reference that file rather than the universal rc.
Well we learned something today - when in this much doubt check all aliases.
Trying to figure out why I could not set up Heroku Gem and following this answer SO 2396004 (Heroku Gem Doesn't Work). I think I might have messed up my system.
Now I am typing heroku list and I get (-bash: heroku: command not found) and when I type in ruby -v I get (-bash: ruby: command not found)
BELOW IS THE MOST RECENT OUTPUT
zak$ export PATH=$PATHEXECUTABLE DIRECTORY: /Users/zak/.rvm/gems/ruby-1.9.2-p0#rails3tutorial/bin
-bash: export: `DIRECTORY:': not a valid identifier
-bash: export: `/Users/zak/.rvm/gems/ruby-1.9.2-p0#rails3tutorial/bin': not a valid identifier
ZKidds-MacBook-Pro:rails_projects zak$ export PATH=$PATH:/Users/zak/.rvm/gems/ruby-1.9.2-p0#rails3tutorial/bin
ZKidds-MacBook-Pro:rails_projects zak$ heroku list
-bash: heroku: command not found
ZKidds-MacBook-Pro:rails_projects zak$ cd ..
ZKidds-MacBook-Pro:~ zak$ export PATH=$PATH:/Users/zak/.rvm/gems/ruby-1.9.2-p0#rails3tutorial/bin
ZKidds-MacBook-Pro:~ zak$ heroku list
-bash: heroku: command not found
ZKidds-MacBook-Pro:~ zak$ echo $PATH
:/Users/zak/.rvm/gems/ruby-1.9.2-p0#rails3tutorial/bin:/Users/zak/.rvm/gems/ruby-1.9.2-p0#rails3tutorial/bin
-bash: GEM: command not found
ZKidds-MacBook-Pro:~ zak$ gem env
-bash: gem: command not found
ZKidds-MacBook-Pro:~ zak$ heroko list
-bash: heroko: command not found
When you set PATH to just one value, you lost all the other places to search, such as /bin and /usr/bin. Set your PATH incrementally:
export PATH=/new/place/bin:$PATH
You can be more elaborate than that, but that basic technique works.
Meantime, logout and login again - that will get you going most easily. Alternatively:
export PATH=$PATH:/bin:/usr/bin
Additionally, your first line was:
export PATH=$PATHEXECUTABLE DIRECTORY: /Users/zak/.rvm/gems/ruby-1.9.2-p0#rails3tutorial/bin
When you run export, it will export one or more variables, but the values must either be simple variable names, or must be variable assignments:
export SOMEVAR NOTHERVAR=new-value ...
The complaint -bash: export:DIRECTORY:': not a valid identifier` is telling you that 'DIRECTORY:' is not valid. It is not clear what you had in mind. And you got a similar complaint about /Users/zak/... not being an identifier.
You can set an environment variable for just one run of a command:
PATH=$EXECUTABLE_DIRECTORY:$PATH /Users/zak/bin/command
The environment of the command will include the value of PATH given; note, though, that the shell won't search for the command with that modified path.
...What I was trying to do was...
I'm not a user of either Ruby or Rails, but on my Mac (10.6.4), I can find:
Osiris-2 JL: ruby -v
ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]
Osiris-2 JL: rails -v
Rails 2.3.5
Osiris-2 JL: which ruby rails
/usr/bin/ruby
/usr/bin/rails
Osiris-2 JL:
So, on my machine, both Ruby and Rails are in /usr/bin. I don't have Heroku installed AFAIK (not on my PATH, anyway). Your first export clobbered PATH; the second one added your Ruby 1.9.2 directory to the empty PATH. Apparently, Heroku is installed somewhere else, or is not yet installed at all. You changed directory - a built-in operation that does not require a working PATH; you added the Ruby 1.9.2 directory to your PATH again (which didn't change anything usefully). Heroku is still not found. You echoed PATH (another built-in) - I'm not clear where the GEM: command not found message comes from. And the commands gem and heroko (sic) were not found. So, your first command set in train the problems.
Then you commented:
In terms of what I was trying to do, I was just trying to set-up my heroku account and got stuck when I tried to add my public ssh key. The heroko gem I had installed (thought) was not registering. That is when I read through the stackoverflow question referenced above that suggested my path was incorrect. I closed terminal and reopened. Running stuff like ruby -v outputs, but running rails -v does not. Is there something still to do? Why would rails -v not output?
Specifically on rails -v I get "/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems.rb:827:in report_activate_error': Could not find RubyGem rails (>= 0) (Gem::LoadError) from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems.rb:261:inactivate' from /System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/rubygems.rb:68:in `gem' from /usr/bin/rails:18 "
This suggests that you have rails installed in /usr/bin (like I do), but the installation has been altered somehow so it is self-inconsistent. Either that or the messed up environment (PATH) is causing trouble. But usually, software can find its own bits'n'pieces, so it suggests there is something up. Part of the trouble may be that you're using a Ruby 1.9.2 program with some Ruby 1.8 software.
My personal policy is to leave o/s provided software strictly alone; I let the Mac updates take care of that. If I want my own version of something, I build it and install it under my control - I do this with Perl, sometimes with GCC, and with Git or SVN or Mercurial or other such software.
I would look at ensuring you have the Ruby 1.9.2 environment working fully, and worry about whether you need to update your Rails environment in parallel. I suspect that using Ruby 1.9.2 with Rails built for Ruby 1.8.x is causing some of the trouble - but I'm not certain of that.
The fact I think is you misunderstand the doc you are reading.
When you read "$PATHEXECUTABLE DIRECTORY" it's a placeholder to be substituate with the real path of what you want to add.
To do it properly, follow what Jonathan Leffler said.
I'm trying to install some Ruby Gems so I can use Ruby to notify me when I get twitter messages. However, after doing a gem update --system, I now get a zlib error every time I try and do a gem install of anything. below is the console output I get when trying to install ruby gems. (along with the output from gem environment).
C:\data\ruby>gem install twitter
ERROR: While executing gem ... (Zlib::BufError)
buffer error
C:\data\ruby>gem update --system
Updating RubyGems
ERROR: While executing gem ... (Zlib::BufError)
buffer error
C:\data\ruby>gem environment
RubyGems Environment:
- RUBYGEMS VERSION: 1.2.0
- RUBY VERSION: 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32]
- INSTALLATION DIRECTORY: c:/ruby/lib/ruby/gems/1.8
- RUBY EXECUTABLE: c:/ruby/bin/ruby.exe
- EXECUTABLE DIRECTORY: c:/ruby/bin
- RUBYGEMS PLATFORMS:
- ruby
- x86-mswin32-60
- GEM PATHS:
- c:/ruby/lib/ruby/gems/1.8
- GEM CONFIGURATION:
- :update_sources => true
- :verbose => true
- :benchmark => false
- :backtrace => false
- :bulk_threshold => 1000
- REMOTE SOURCES:
- http://gems.rubyforge.org/
Found it! I had the same problem on windows (it appeared suddenly without me doing an update, but whatever):
It has something to do with multiple conflicting zlib versions (I think).
In ruby/lib/ruby/1.8/i386-msvcrt, make sure that there exists a zlib.so file. In my case, it was already there. If not, you may try to install ruby-zlib.
Then go to ruby/lib/ruby/site_ruby/1.8./i386-msvcrt and delete the zlib.so file there.
In ruby/bin, there should be a zlib1.dll. For some reason my Ruby version did not use this dll. I downloaded the most recent version (1.2.3) and installed it there. I had to rename it to zlib.dll for it to be used.
And tada! Rubygems worked again.
Hope this helps.
Firstly, I thank the person, who came up with the solution to the missing zlib problem. (It wasn't me. :-)
Unfortunately I lost the link to the original posting, but the essence of the solution on Linux is to compile the Ruby while zlib header files are available to the Ruby configure script. On Debian it means that zlib development packages have to be installed before one starts to compile the Ruby.
The rest of my text here does not contain anything new and it is encouraged to omit it, if You feel comfortable at customizing Your execution environment at UNIX-like operating systems. The following is a combination of a brief intro to some basics and step by step instructions.
------The-start-of-the-HOW-TO-------------------------
If one wants to execute a program, let's say, irb, from a console, then the file named irb is searched from folders in an order that is described by an environment variable called PATH. It's possible to see the value of the PATH by typing to a bash shell (and pressing Enter key):
echo $PATH
For example, if there are 2 versions of irb in the system, one installed by the "official" package management system, let's say, yum or apt-get, to /usr/bin/irb and the other one that is compiled by the user named scoobydoo and resides in /home/scoobydoo/ourcompiledruby/bin then the question arises, which one of the two irb-s gets executed.
If one writes to the
/home/scoobydoo/.bashrc
a line like:
export PATH="/home/scoobydoo/ourcompiledruby/bin:/usr/bin"
and restarts the bash shell by closing the terminal window and opening a new one, then by typing irb to the console, the
/home/scoobydoo/ourcompiledruby/bin/irb gets executed. If one wrote
export PATH="/usr/bin:/home/scoobydoo/ourcompiledruby/bin"
to the
/home/scoobydoo/.bashrc
,then the /usr/bin/irb would get executed.
In practice one wants to write
export PATH="/home/scoobydoo/ourcompiledruby/bin:$PATH"
because this prepends all of the values that the PATH had prior to this assignment to the /home/scoobydoo/ourcompiledruby/bin. Otherwise there will be problems, because not all common tools reside in the /usr/bin and one probably wants to have multiple custom-built applications in use.
The same logic applies to libraries, except that the name of the environment variable is LD_LIBRARY_PATH
The use of the LD_LIBRARY_PATH and PATH allow ordinary users, who do not have root access or who want to experiment with not-that-trusted software, to build them and use them without needing any root privileges.
The rest of this mini-how-to assumes that we'll be building our own version of ruby and use our own version of it almost regardless of what is installed on the system by the distribution's official package management software.
1)=============================
First, one creates a few folders and set the environment variables, so that the folders are "useful".
mkdir /home/scoobydoo/ourcompiledruby
mkdir -p /home/scoobydoo/lib/our_gems
One adds the following 2 lines to the
/home/scoobydoo/.bashrc
export PATH="/home/scoobydoo/ourcompiledruby/bin:$PATH"
export GEM_HOME="/home/scoobydoo/lib/our_gems"
Restart the bash shell by closing the current terminal window and opening a new one or by typing
bash
on the command line of the currently open window.
The changes to the /home/scoobydoo/.bashrc do not have any effect on terminal windows/sessions that were started prior to the saving of the modified version of the /home/scoobydoo/.bashrc
The idea is that the /home/scoobydoo/.bashrc is executed automatically at the start of a session, even if one logs on over ssh.
2)=============================
Now one makes sure that the zlib development packages are available on the system. As of April 2011 I haven't sorted the details of it out, but
apt-get install zlibc zlib1g-dev zlib1g
seems to be sufficient on a Debian system. The idea is that both, the library file and header files, are available in the system's "official" search path. Usually apt-get and alike place the header files to the /usr/include and library files to the /usr/lib
3)=============================
Download and unpack the source tar.gz from the http://www.ruby-lang.org
./configure --prefix=/home/scoobydoo/ourcompiledruby
make
make install
4)=============================
If a console command like
which ruby
prints to the console
/home/scoobydoo/ourcompiledruby/bin/ruby
then the newly compiled version is the one that gets executed on the command
ruby --help
5)=============================
The rest of the programs, gem, irb, etc., can be properly executed by using commands like:
ruby `which gem` install rake
ruby `which irb`
It shouldn't be like that but as of April 2011 I haven't figured out any more elegant ways of doing it. If the
ruby `which gem` install rake
gives the zlib missing error again, then one should just try to figure out, how to make the zlib include files and library available to the Ruby configure script and recompile. (Sorry, currently I don't have a better solution to offer.)
May be a dirty solution might be to add the following lines to the
/home/scoobydoo/.bashrc
alias gem="`which ruby` `which gem` "
alias irb="`which ruby` `which irb` "
Actually, I usually use
alias irb="`which ruby` -KU "
but the gem should be executed without giving the ruby the "-KU" args, because otherwise there will be errors.
------The-end-of-the-HOW-TO------------------------
I just started getting this tonight as well. Googling turned up a bunch of suggestions that didn't deliver results
gem update --system
and some paste in code from jamis that is supposed to replace a function in package.rb but the original it is supposed to replace is nowhere to be found.
Reinstalling rubygems didn't help. I'm reinstalling ruby right now.........and it is fixed. Pain though.
How about cd into rubysrc/ext/zlib, then ruby extendconf.rb, then make, make install.
After do that, reinstall ruby.
I did this on ubuntu 10.04 and was successful.
A reinstall of Ruby sorted this issue out. It's not what I wanted; I wanted to know why I was getting the issue, but it's all sorted out.
It most often shows up when your download failed -- i.e. you have a corrupt gem, due to network timeout, faulty manual download, or whatever. Just try again, or download gems manually and point gem at the files.
if gem update --system not works and rename ruby/bin/zlib1.dll to zlib.dll not helps try:
Open file RUBY_DIR\lib\ruby\site_ruby\1.8\rubygems.rb
And replace existed def self.gunzip(data) by this:
def self.gunzip(data)
require 'stringio'
require 'zlib'
data = StringIO.new data
# Zlib::GzipReader.new(data).read
data.read(10) # skip the gzip header
zis = Zlib::Inflate.new(-Zlib::MAX_WBITS)
is = StringIO.new(zis.inflate(data.read))
end
Try updating ZLib before you do anything else. I had a similar problem on OS X and updating Compress::Zlib (a Perl interface to ZLib) cured it - so I think an old version of ZLib (is now 1.2.3) may be where your problem lies...
install pure ruby zlib if all else fails