In Windows, using Cygwin: How can I get the shebang line in a shell file to load the PHP interpreter?
I am using the prggmr library.
By default, in the shell file this is what I have
#!/usr/bin/php
And it works if I type this into Cygwin:
php c:/path/to/file
I have PHP and this Library setup in my environment paths so I can just type prggmr. So by typing "prggmr" it should work, but i keep getting
/cygdrive/c/lib/prggmr/bin/prggmr: /cygdrive/c/wamp/bin/php/php5.4.3:
bad interpreter: Permission denied
I have tried these with no luck, the same error as above:
#!/c/wamp/bin/php/php5.4.3
#!/cygdrive/c/wamp/bin/php/php5.4.3
If I'm reading your Paths right you have a Win32 PHP installed that you want to use with PHP. Normally, I'd say don't do it this way as things are going to get confused. Better to install PHP in Cygwin directly imo. There are a few resources out there, check out
this one for a good starting point.
Related
Firstly, I am new to Linux so excuse me if any terminology is wrong; I'll try to phrase the problem as competently as possible.
I have installed Ruby (2.4.0) via Linuxbrew. The ruby command works fine; it installed correctly. However, when I try to use the gem command (which Ruby should have installed) I receive this error:
bash: /usr/bin/gem: No such file or directory
Now, because I installed this with Linuxbrew I know that this directory isn't correct. For example:
result of which gem : /home/me/.linuxbrew/bin/gem
result of which ruby : /home/me/.linuxbrew/bin/ruby
Therefore, it seems gem is installed but the gem command isn't linked to the correct path. I assume I need to direct the gem command to the path of which gem as opposed to /usr/bin/gem that bash is saying doesn't exist. How would I go about changing this? I tried in vain to change the bash_profile but I'm not sure what to do.
Again, excuse me if ruby and gem are not referred to as commands and if the problem isn't the "default directory" as stated in the title. I wasn't sure how to label it.
EDIT/TL;DR:
Basically, how can I make gem execute this: /home/me/.linuxbrew/bin/gem instead of looking for the program in /usr/bin/gem?
Instead of running gem, run /home/me/.linuxbrew/bin/gem, i.e. type the full path name (followed by any arguments you may need).
If this becomes too tiresome, you could change your PATH. Prepend your bin directory with
PATH=$HOME/.linuxbrew/bin:$PATH
First, the reason you get the error /usr/bin/gem not found, is that earlier in the same shell session, the file used to be there. Bash will cache this to speed things up when running the same command many times. Running hash -r will clear this.
Editing PATH you seem to have managed, hence the which command gives the result it does.
To answer my own question-
As I had previously installed and uninstalled Ruby via apt-get instead of Linuxbrew in the same Terminal window, Bash was looking for gem in usr/bin as opposed to the path specified in my bash_profile to Linuxbrew.
Therefore, Stian's answer above with hash -r would also work, I am sure.
Well the idea goes as followed,
I have a bash file for linux, there I obviously run it by making ./my_run.
The problem is I'm in windows so I downloaded and installed cygwin.
I added cygwin bin to the Enviromental Variables and check that at least "ls" works so I guessed I did it well.
When I try to run it with the cmd it displays:
'.' is not recognized as an internal or external command,
operable program or batch file.
As if the cygwin variables were not correctly installed (as I said I tried ls and works).
Then I tried it directly with cygwin and when doing the ./my_run I got it to work right.
So how is that I can use some commands like ls but when doing ./ it doesn't work on the cmd? How can I fix this?
Well, cygwin is only a shared library and a lot of stuff (the programs) using it (read Cygwin doc). cygwin.dll changes internally path resolution / chars to allow you to say ./my_script and converts it to .\my_script before doing the actual windows call, it also adds the proper extension to executables to allow it to execute windows binaries. This magic persists as long as you use it. cmd.exe is a Microsoft Windows command shell that is completely unaware of Cygwin's shared library and by that reason it doesn't use it, so it will not call it for path translation, even if you populate the environment of zetabytes of stuff. When you run in Cygwin terminal, you are running bash shell, which is a Cygwin executable, linked to cygwin.dll. It manages to use Cygwin library for all the unix system call emulations, so when you pass it e.g. to exec("./my_script", ...);, it internally converts that to try for ./my_script, then .\my_script, ./my_script.exe, ... and the same for .com and .bat extensions.
This fact often makes some people to say that Cygwin is not a good, efficient, environment. But the purpose was not to be efficient (and it is, as it caches entries and makes things best to be efficient) but to be compatible.
In your example ls is a Cygwin executable that mimics the /bin/ls executable from unix systems. It uses the Cygwin library, so all path resolution will be properly made (well, under some constraints, as you'll see after some testing) and everything will work fine. But you cannot pretend all your Windows applications to suddenly transform themselves and begin working as if they where in a different environment. This requires some try and error approach that you have to try yourself. And read Cygwin documentation, it is very good and covers everything I've said here.
If you open up Cygwin and run the command there you should be fine.
I have a script file that I was given to run in windows using Cygwin. When I try to use this file I get the following error
-bash: /sigdet/filename: cannot execute binary file: Exec format error.
sigdet is the folder within the Cygwin directory that I have the script. Rawdata is the name of the directory with the raw data files that the script is supposed to analyze.
To try and solve this, I have changed the file permissions, I have checked to make sure that it is on a 64 bit machine and the script appears to have compiled on a 64-bit machine. After these steps, I don't know what else the problem could be. Here are the commands I've entered:
I first changed the directory like so:
$ cd /sigdet/
Then I ran the script that is suppsed to work:
$ /sigdet/filename -i rawdata
Does the script file need to have an extension in windows? I've tried changing it to a .sh extension with no luck. I'm told that it just works on other windows machines just how it is.
Thanks to anyone that can help with this.
Your file is not an executable. It most probably contains ELF executable which is designed for Linux operating system, or it's corrupt.
If your file was a shell script, or in fact anything that contained plain text, you'd get different errors (such as, "expected command name" or "unknown command: XYZ" etc.)
Scripts are not supposed to have file extensions, like any executables. On the other hand, they should have shebangs: small text located in the first line that tells the system the path to the interpreter. For example, a Python executable script might be named whatever and have #!/usr/bin/python3 or similar in the first line. When you run it through ./whatever in the shell, it'll look for python3 in /usr/bin and run your file like this: /usr/bin/python3 ./whatever. (In fact, thanks to this you can also specify additional parameters that get passed to the interpreter.)
There is also a chance that your script is valid, but it contains a shebang pointing to bad interpreter. If that is the case, then most likely the path is correct, otherwise you'd get /whatever/interpreter: bad interpreter: no such file or directory error or similar. But then, all the other points apply to the interpreter (which is just another executable...)
If the script and/or interpreter was meant to be executed on Windows or Cygwin at least, it should either contain aforementioned shebang (#!/path in the first name) or it should be Windows executable (in which case the file data should begin with MZ letters, you can inspect it in notepad.) If it isn't, it means the files you were given can't run on Cygwin.
Had this same problem. Added the following at the top of makefile:
export ARCH = CYGNUS
What happened during the make process is that Linux and Windows versions of the executables were created. You just have to use ./.exe versions.
In my case, I got the error when I used a wrong command to compile my C program. When I used the right command:
gcc myprog.c -o myprog.exe
the error was resolved.
I have a Perl script which I want to run in Linux. I know about the plugins which we can use, but that's a limitation for me. I will have to use External Tools Configurations to run it. I searched on the internet, but there is no place where i could find the explanation.
I tried using external tools, but when I run it nothing is showing up on my screen. May be I did the wrong way.
The way I filled it was:
Name: I gave any random name
Location: I gave /usr/bin/perl
Working Directory: the path of the directory where my Perl script is located.
Arguments: Name of my Perl script.
I would also like to mention that my script calls an executable file (a C++ makefile) which runs rest of my program. Maybe that is the problem?
I am using Perl perspective. I am not an Eclipse expert, so I might be missing something important. Please advise.
I think the location would be your Perl script.
/usr/bin/perl /path/to/your/script.pl
/path/to/your/script.pl
Check these links, maybe useful:
http://wiki.eclipse.org/FAQ_How_do_I_add_my_own_external_tools%3F
http://help.eclipse.org/helios/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Ftasks%2Ftasks-exttools-running.htm
I'm attempting to load several modules for building a library on Linux but am told that the command 'module' doesn't exist. I've Googled around and discovered that the solution was to source a directory called "module" which I am unable to locate despite extensive searching.
I'm not quite sure what I should and any help would be appreciated (it might help to know that the makefile I'm working with uses csh while my default shell is bash). Thanks!
I tried to reproduce it and it turns out that for me sourcing
source /etc/profile.d/modules.sh
in th .sh script helps for bash and similar. For csh and tcsh, you have to add
source /etc/profile.d/modules.csh
to the script. Note, that this line must come first and then the
module load foo
line.
I got here as I was searching for ways to install multiple php versions in CentOS7 and https://blog.remirepo.net/post/2019/05/22/PHP-7.4-as-Software-Collection was one of the articles I tried to follow and encountered the same "module: command not found" issue.
Sourcing /etc/profile via command:
. /etc/profile
seems to make the "module load" work.
Credits to fadishei in https://forums.fedoraforum.org/showthread.php?262708-module-command-not-found
To make the version of php (e.g. php7.4) persist, append the following to file /etc/profile.d/custom.sh
source /etc/profile.d/modules.sh
module load php74
Reboot and run the php --version to cross-check that php 7.4 is the current version installed.
I think that you have to put this in your script to define the module command:
module () {
eval `/usr/bin/modulecmd bash $*`
}
This was working for me
#!/bin/bash -i // it will make this interactive