I'm running OS X 10.5.8 with Ruby 1.9.3p194 (2012-04-20 revision 35410) [i386-darwin9.8.0]. I'm trying to log into Heroku from the shell. I upgraded Bash and ran heroku login with the following result:
/usr/local/heroku/vendor/gems/heroku-api-0.3.1/lib/heroku/api.rb:3:in `require': no such file to load -- securerandom (LoadError)
from /usr/local/heroku/vendor/gems/heroku-api-0.3.1/lib/heroku/api.rb:3
from /usr/local/heroku/vendor/gems/heroku-api-0.3.1/lib/heroku-api.rb:1:in `require'
from /usr/local/heroku/vendor/gems/heroku-api-0.3.1/lib/heroku-api.rb:1
from /usr/local/heroku/lib/heroku/cli.rb:7:in `require'
from /usr/local/heroku/lib/heroku/cli.rb:7
from /usr/bin/heroku:22:in `require'
from /usr/bin/heroku:22
I got as far as openssl is bad if anyone's traveling the same tortured path.
I've seen this a couple other times. The solution for them ended up being editing the #! line in the /usr/bin/heroku file (the first line in the file) to point to whatever which ruby would return for their machine. By default it points to system ruby instead of any installed version, in the hopes that this will lead to a more consistent experience (and it usually does). Hope that helps.
Related
I am trying to run the metal executable from my zsh terminal in order to meta-analyze GWAS data. I have the executable in the correct directory and have checked that it is not 0MB due to truncation.
Reproducible:
Download the Linux file from http://csg.sph.umich.edu/abecasis/metal/download/
In terminal:
PATH TO EXECUTABLE ./metal
zsh: exec format error: ./metal
You probably install wrong OS of go, for example, you might install go for MacOS in Linux
I solve this problem by installing go for correct OS
The executable has been pre-compiled on a certain distribution with libraries at a certain places at certain versions.
If you have a different distribution, libraries versions, it won't work and you better compile from the source.
Basically what you have to do is to download and extract the sources, go in the folder and execute make. (You will have probably to install make first.)
I think that's not your job at all so maybe you can find a geeky person to help you, because you may stumble upon problems, libraries to install, old versions not supported anymore, new versions not supported yet...
It happened to me when I emptied an executable by mistake.
~>true > a
~>wc -c a
0 a
~>./a
zsh: exec format error: ./a
I am learning to program in Python and Rust. On different versions of Ubuntu these programs compiled and ran perfectly. Now that I have a dedicated Fedora 30 KDE system, every time I try and build a program, I get a warning: Failed to load module "appmenu-gtk-module"
I have tried looking this up and have re/installed anything GTK on my system. The programs otherwise function well, but no menus are drawn. I was also trying things in GNOME and hit the same thing.
I am also using QT. Those programs also build and run fine, but again, no menu.
I'm going bonkers with this. Any help is appreciated.
The appmenu-gtk module is not packaged on Fedora. (GNOME doesn't support them anyway.)
The real questions are:
Why is it configured to load? Did you copy or share GTK config files from an Ubuntu system? You should remove this module from your settings.
Even with improper configs I don't believe this should result in menus not appearing. It should just fail to load and work as normal. How is your application using menus?
I finally got so fed up with getting this error that I went full nerd-diagnosis, and ran this command to find out which file contained the errant reference to the appmenu-gtk (the package that would provide this is not installable on my system either).
(Replace "dolphin" with the command that is giving you the error.)
strace -e openat,access dolphin 2>&1 |grep -v ENOENT |awk '/appmenu-gtk/ {exit} !/appmenu-gtk/ {print}'|cut -d '"' -f2 |sort|uniq|xargs grep appmenu-gtk 2>/dev/null
This will then give you a list of files which contain the line appmenu-gtk, and in my case it was ~/.config/gtk-3.0/settings.ini. From there I just commented it out, and that gets rid of the error message (not sure if this will fix your problem of not having any menus, but you might just be able to edit that line to fix it in another way if commenting it out doesn't work).
I have a script in Python that imports out of some other packages, the NLTK package.
The OS is Debian Stretch. Executing it directly on Linux everything works as should it be. But running the mentioned script with Sympony - Process, it returns the following error:
Traceback (most recent call last):
File \"/var/www/html/public/_import.py\", line 1, in <module>
import nltk
ModuleNotFoundError: No module named 'nltk'
If simply I just comment "import nltk", all the script works properly even with Symfony Process at all.
I could not leave this problem, as I have resolved it, without an answer for you that might be facing the same issue!
The problem at all was not caused by Symfony - Process, but, unfortunatly, by instalation behavior of the module named: "NLTK";
In my case, the user used to install things on Linux Debian Stretch was the root.
Try (now, you, before changes and check...) to use the following command in your terminal: pip show nltk.
The output is:
Name: nltk
Version: 3.4.5
Summary: Natural Language Toolkit
Home-page: http://nltk.org/
Author: Steven Bird
Author-email: stevenbird1#gmail.com
License: Apache License, Version 2.0
Location: /usr/local/lib/python3.7/site-packages
Requires: six
Required-by:
Take a look at Location. Now it is the right place. But, as default, pip install nltk will place it, in my case with user "root" installing things, at "/root/.local/lib/python3.7/site-packages/nltk" as the base path! So, when the user "www-data" tried to runing it... ModuleNotFoundError: No module named 'nltk'
No module named 'nltk' - because it was not there to the place should it be accessed!
So, as you might guess now, the problem as caused by permission issues! Unfortunatly, no error (logs) output happened that would drive me to mind that would it be related to permission issues!
The solution:
1) Not messing around with the system or executing unecessary changes was considered at first place;
2) Had uninstalled it with pip the module NLTK and I have seeked to find where the other modules were installed;
3) Installed it (NLTK) again, but now, placing it where I want, I mean, where it should be since the begening: among the others modules - as numpy -, that could be accessed easily and without issues!
The command used was:
pip install --target="/usr/local/lib/python3.7/site-packages"
--upgrade nltk
Now, NLTK resides at /usr/local/lib/python3.7/site-packages followed by all the other modules working properly like a charm!
I hope this helps you!
I am attempting to run a sass watch command on a new branch of code. when I run the normal command I get a permissions denied error.
Errno::EACCES: Permission denied - /me/atg/workspace/AA/dev_3.4.0
Here's my command:
sass --watch stores.scss:/me/atg/workspace/AA/dev_3.4.0/a_a/modules/estore/j2ee/AA.war/static/css/stores.css --style compressed
I ran the command using sudo, and it does seem to run. The watch picks up that changes have been made in the scss files, but the changes do not appear after refresh as they did previously using the watch command. I have to rebuild and start the server for the changes to actually show on my local site.
I think it is possibly a cache issue, but not sure. I am not using compass and most of the solutions I've read about seem to be related to compass.
Below is the trace when running the watch command without using sudo.
from /usr/lib/ruby/1.9.1/fileutils.rb:247:in `fu_mkdir'
from /usr/lib/ruby/1.9.1/fileutils.rb:221:in `block (2 levels) in mkdir_p'
from /usr/lib/ruby/1.9.1/fileutils.rb:219:in `reverse_each'
from /usr/lib/ruby/1.9.1/fileutils.rb:219:in `block in mkdir_p'
from /usr/lib/ruby/1.9.1/fileutils.rb:205:in `each'
from /usr/lib/ruby/1.9.1/fileutils.rb:205:in `mkdir_p'
from /var/lib/gems/1.9.1/gems/sass-3.4.16/lib/sass/plugin/compiler.rb:478:in `update_stylesheet'
from /var/lib/gems/1.9.1/gems/sass-3.4.16/lib/sass/plugin/compiler.rb:215:in `block in update_stylesheets'
from /var/lib/gems/1.9.1/gems/sass-3.4.16/lib/sass/plugin/compiler.rb:209:in `each'
from /var/lib/gems/1.9.1/gems/sass-3.4.16/lib/sass/plugin/compiler.rb:209:in `update_stylesheets'
from /var/lib/gems/1.9.1/gems/sass-3.4.16/lib/sass/plugin/compiler.rb:293:in `watch'
from /var/lib/gems/1.9.1/gems/sass-3.4.16/lib/sass/plugin.rb:108:in `method_missing'
from /var/lib/gems/1.9.1/gems/sass-3.4.16/lib/sass/exec/sass_scss.rb:384:in `watch_or_update'
from /var/lib/gems/1.9.1/gems/sass-3.4.16/lib/sass/exec/sass_scss.rb:51:in `process_result'
from /var/lib/gems/1.9.1/gems/sass-3.4.16/lib/sass/exec/base.rb:52:in `parse'
from /var/lib/gems/1.9.1/gems/sass-3.4.16/lib/sass/exec/base.rb:19:in `parse!'
from /var/lib/gems/1.9.1/gems/sass-3.4.16/bin/sass:13:in `<top (required)>'
from /usr/local/bin/sass:23:in `load'
from /usr/local/bin/sass:23:in `<main>'
For read-speed, Sass caches parsed documents for reuse, only parsing documents again when changed. By default, Sass writes these cached files to :cache_location. When you start having sudden Sass compile issues, a common culprit is your .sass-cache. Maybe you upgraded your IDE, made some directory structure changes, or sometimes an OS update (OSX is notorious for permissions headaches). Whatever the case may be, if Sass can't access the .sass-cache or something has gotten out of sync, things can get rather hairy with a quickness.
Assuming from your description that you're merely running sass watch from the command line and not using some IDE compilation tool, a good place to start looking for your .sass-cache is ./tmp/sass-cache or ./.sass-cache of your project, as detailed here. Keep in mind that the file is usually hidden by default. You can try manually deleting the folder and then running your sass watch command again. If all goes well, your .sass-cache should completely rebuild the next time you run sass watch, and you should be up and running again.
If, by chance, you've upgraded your OS recently and you're running OSX, there does seem to be an issue with Sass post-upgrade that sounds like what you are describing as well. A fix suggested in the comments that seems to solve the problem for everybody is to run sudo gem install -n /usr/local/bin sass.
Hope this helps!
So I am trying to install a program on my windows machine that required me to install Cygwin to install it. So I am working from a README file and assueme I have compiled the code previously correctly (its one line sh build.sh) and when actually trying to use the program I get the following error:
BabakP#Babak /cygdrive/c/Users/BabakP/Desktop/test
$ ./Runlock input.tst output.tst 1
./Ostrich: Exec format error. Binary file not executable.
I guess I am trying to figure out why I am getting this error so any suggestions on how to troubleshoot it would be great!
./Ostrich is a Mac executable. It can't be executed under Cygwin. (A MacOS emulator that runs under Windows or Cygwin is theoretically possible, but I don't know of any such thing.)
Without knowing the details of the software you're trying to install, it's hard to say how or whether you can fix it.
You may be able to rebuild Ostrich from source (if you have the source, and if it's not MacOS-specfic).