I am running Rebol on Debian Stable Linux and I have put rebol executable in /usr/local/bin. Then I have created following script file and also kept it in /usr/local/bin:
#! /usr/local/bin/rebol
REBOL []
print what-dir
quit
However, when I run this script from any directory, it only reports "/usr/local/bin/" and not current working directory. I want to get current working directory to perform operations from code.
Following code, using Linux shell command pwd (print working directory) also reports the same:
print call "pwd"
How can this problem be solved?
You can find your own directory where you are in system/options/path and if you want it to be your current working directory and what-dir to report your own directory as current directory, you have to add this line
system/script/path: system/options/path
or
change-dir system/options/path
before calling what-dir.
Even call "pwd" uses and shows now your own as current directory under Linux
I agree, this behaviour is quite unintuitive.
I came across the same situation a while ago, and I kept on making the same mistake over and over... I eventually placed that change-dir system/options/path in a more general routines script, which is loaded from my ~/.rebol/view/user.r.
Mind you though, one could also put that statement within the user.r.
Related
Quick background: I previously used a remote Linux server for a project. Here I was able to pull up the Linux command window in the directory where files from another program were located, and enter a command such as lspp c= example_file.cfile -nographics. LSPP in this case is short for LS PrePost - through this command I was able to call LSPP in the background and have it reference the given *.cfile which contains various commands to be executed, such as depositing a given *.csv file with results, its name, etc.
I recently managed to install LSPP for windows locally, and am now trying to essentially translate the functionality of the command I executed in Linux, to Windows. I should add that I have no experience with CMD or Windows PowerShell...
The first thing I tried was to use cd C:\.... to set the directory to where the *.cfile is located and then enter the same lspp c= example_file.cfile -nographics from Linux, however, the response was that "lspp" was either spelled wrong or could not be found.
Next I tried setting the directory to the LSPP program folder, and using start LS-PrePost-4.7-x64 to at least start the program, but this didn't work either.
I would really appreciate it if someone could point me in the right direction here - thank you!
I've been having a lot of trouble trying to set up a path to an executable file in linux. Sorry If it's a dumb question, but I'm new to linux and still figuring things out.
Anyways, the file I want to create a path to is located at:
/opt/gitools/gitools-2.3.1/gitools
So I created a path at the end of my .bashrc file:
export PATH=$PATH:/opt/gitools/gitools-2.3.1/
I've checked, and the file gitools as well as all parent directories are marked as executable. However, when I enter "gitools", it returns:
/bin/bash: /opt/gitools/gitools-2.3.1/gitools: Permission denied
And when I enter "sudo gitools", it returns:
sudo: gitools: command not found
There is nothing wrong with the program itself, because I can run it by going to its directory and entering "sudo ./gitools", however, I'm unsure of why I need sudo when it should be executable for all users.
Any help is greatly appreciated!
I finally figured out a solution that works.
I tried to give full read write execute permission to all files in the program, but that just created errors that prevented running the program at all.
However, I noticed that the owner of all of the files was set to root, so in a last ditch attempt to get it to work I decided to recursively change the ownership of all directories and files associated with the program by going to the /opt directory and entering:
sudo chown -R myUsername:myUsername gitools/
Hope that this might help someone with a similar problem!
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.
There is a program in the PATH variable installed by root, but I installed a more recent version in my local.
There is any way to make my program preferable instead of the root?
Sorry for my bad english.
export PATH="/path/to/my/local/directory:$PATH"
Set this in your shell's startup file (e.g., ~/.bash_profile or ~/.zshenv) and restart your shell (or just execute it in your terminal).
put the preferred directory in front of the other one. It will pick up the first one it finds.
export PATH=/this/path/is/searched/first:/this/one/is/second:$PATH
I am a newbie to Linux and I am only really using it to use a program for my final year thesis. I have got to grips with the language for the program but am having issues with actually running it in Linux. The program is called "CACTUS" and all documentation can be found here.
I have extracted the application file and I have made the executable as instructed in the install.txt file:
"Installation of CACTUS for Linux or Mac machines.
Unzip the directory and put in desired location. On terminal cd into the
correct directory (you should be able to see the makefiles).
Create the executable by typing:
$make
or
$make -f Makefile.gfortran
on the terminal. The executable will be called cactus and be located in the
directory one level above.You can add the executable's location to your path
so that you can call it by simple typing cactus on the terminal instead of
the complete path.
cd into the Test/RegTest directory
$cd ./Test/RegTest
and run the RegTest by executing runreg.py with the path to the CACTUS
executable as an argument (or just the name of the executable if you added it
to your path).
$./runreg.py ../../../cactus
or
$./runreg.py cactus
The output should say 'No differences' for all three tests. Note: if you have
Python 3 installed used runreg_p3.py instead.
CONGRATULATIONS! You have successfully installed CACTUS.
I have run this and I didn't get the "No Differences" returned on the runreg.py. I continued anyway as I did not know why or how I could fix this. (This may be a root cause of my overally problem here)
As I progressed I have been trying to open an input file "TestVAWT.in" from TestCase2 with the following command:
./TestVAWT.in ../../../cactus
From this I get the error in the title returned. Am I correct in assuming that it has tried to run the TestVAWT.in file on the command line without referring to the Cactus application which I presume would be able to read the '&' prefix of the code along with the rest of the input file. Or is it something else I am missing here.
I would appreciate any help as I have been banging my head against a wall for some time now.
Note: I am using Ubuntu 14.04 LTS.
Best Regards
Richard
Don't know the application, but looks kind of strange to me.
Please try adding the Input-File as a parameter:
cactus TestVAWT.in