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!
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 am running R on Windows, not as an administrator. When I install a package, the following command doesn't work:
> install.packages("zoo")
Installing package(s) into ‘C:/Program Files/R/R-2.15.2/library’
(as ‘lib’ is unspecified)
Warning in install.packages :
'lib = "C:/Program Files/R/R-2.15.2/library"' is not writable
To install a package, I have to specify a library location:
install.packages("zoo", lib="C:/software/Rpackages")
To load a package, I also have to specify the library location:
library("zoo", lib.loc="C:/software/Rpackages")
All of this is OK, but I wanted to see if I could add C:/software/Rpackages to the library path somehow and thus not have to type it each time.
As I searched online, I found that one way to do this is to edit the Rprofile.site file and to add the line
.libPaths("C:/software/Rpackages")
However, after doing this, and starting RStudio, this is the output that I get
> .libPaths()
[1] "C:/Program Files/R/R-2.15.2/library" "C:/Program Files/RStudio/R/library"
The .libPaths command that I added to the Rprofile.site doesn't seem to have had any effect! Why is this the case? Or more importantly, how can I fix the problem so that I can install and load packages without typing in the library location?
Note: if I start RStudio the .libPaths() command seems to work as it is supposed to
.libPaths("C:/software/Rpackages")
> .libPaths()
[1] "C:/software/Rpackages" "C:/Program Files/R/R-2.15.2/library"
Isn't that strange?
The proper solution is to set environment variable R_LIBS_USER to the value of the file path to your desired library folder as opposed to getting RStudio to recognize a Rprofile.site file.
To set environment variable R_LIBS_USER in Windows, go to the Control Panel (System Properties -> Advanced system properties -> Environment Variables -> User Variables) to a desired value (the path to your library folder), e.g.
Variable name: R_LIBS_USER
Variable value: C:/software/Rpackages
If for some reason you do not have access to the control panel, you can try running rundll32 sysdm.cpl,EditEnvironmentVariables from the command line on Windows and add the environment variable from there.
Setting R_LIBS_USER will ensure that the library shows up first in .libPaths() regardless of starting RStudio directly or by right-clicking an file and "Open With" to start RStudio.
The Rprofile solution can work if RStudio is always started by clicking the RStudio shortcut. In this case, setting the default working directory to the directory that houses your Rprofile will be sufficient. The Rprofile solution does not work when clicking on a file to start RStudio because that changes the working directory away from the default working directory.
I generally try to keep all of my packages in one library, but if you want to add a library why not append the new library (which must already exist in your filesystem) to the existing library path?
.libPaths( c( .libPaths(), "~/userLibrary") )
# obviously this would need to be a valid file directory in your OS
# min just happened to be on a Mac that day
Or (and this will make the userLibrary the first place to put new packages):
.libPaths( c( "~/userLibrary" , .libPaths() ) )
Then I get (at least back when I wrote this originally):
> .libPaths()
[1] "/Library/Frameworks/R.framework/Versions/2.15/Resources/library"
[2] "/Users/user_name/userLibrary"
The .libPaths function is a bit different than most other nongraphics functions. It works via side-effect. The functions Sys.getenv and Sys.setenv that report and alter the R environment variables have been split apart but .libPaths can either report or alter its target.
The information about the R startup process can be read at ?Startup help page and there is RStudio material at: https://support.rstudio.com/hc/en-us/articles/200549016-Customizing-RStudio
In your case it appears that RStudio is not respecting the Rprofile.site settings or perhaps is overriding them by reading an .Rprofile setting from one of the RStudio defaults. It should also be mentioned that the result from this operation also appends the contents of calls to .Library and .Library.site, which is further reason why an RStudio- (or any other IDE or network installed-) hosted R might exhibit different behavior.
Since Sys.getenv() returns the current system environment for the R process, you can see the library and other paths with:
Sys.getenv()[ grep("LIB|PATH", names(Sys.getenv())) ]
The two that matter for storing and accessing packages are (now different on a Linux box):
R_LIBS_SITE /usr/local/lib/R/site-library:/usr/lib/R/site-library:/usr/lib/R/library
R_LIBS_USER /home/david/R/x86_64-pc-linux-gnu-library/3.5.1/
I managed to solve the problem by placing the code in the .Rprofile file in the default working directory.
First, I found the location of the default working directory
> getwd()
[1] "C:/Users/me/Documents"
Then I used a text editor to write a simple .Rprofile file with the following line in it
.libPaths("C:/software/Rpackages")
Finally, when I start R and run .libPaths() I get the desired output:
> .libPaths()
[1] "C:/software/Rpackages" "C:/Program Files/R/R-2.15.2/library"
[3] "C:/Program Files/RStudio/R/library"
https://superuser.com/questions/749283/change-rstudio-library-path-at-home-directory
Edit ~/.Renviron
R_LIBS_USER=/some/path
I found what I think is a solution here (thank you Carl Schwarz at SFU) for adding a personal library that is permanently (you don't have to define it each session) recognized whether using R or Rstudio, and Rstudio treats it as the default on my Mac machine. I hadn't seen it laid out this explicitly on SO, so I summarized the steps they provided, for Windows and then for Mac.
For a Windows 7 OS:
Create a directory on the drive where you want to have your personal library, e.g. C:\User\Rlibs (or another that you have permissions to)
Search for/go to "Edit environment variable for your account" in the Windows search bar to edit control panel settings
Click "New..." in the middle of the "Environmental Variables" window
In the "New User Variable" window, type R_LIBS for the "Variable name", and the path to the personal library directory you created, e.g. C:\User\Rlibs
Click OK and you should see the Variable/Value pair in the User variables window
Click OK again
Now when you start R (or Rstudio) and type the command .libPaths() you should see the personal library you created as well as the R system library.
For Mac:
In your "Home" or "username" directory create a folder called Rlibs
Launch the Terminal application
Type: echo "R_LIBS=~/Rlibs" > .Renviron Make sure the spelling and case matches.
Type ls -a to see the full list of files in the directory, which should now include .Renvrion
Verify that the .Renviron file has been set properly: more .Renviron
Launch R/Rstudio and type .libPaths() and you should see the new path to your personal library.
If you do not have admin-rights, it can also be helpful to open the Rprofile.site-file located in \R-3.1.0\etc and add:
.First <- function(){
.libPaths("your path here")
}
This evaluates the .libPath() command directly at start
just change the default folder for your R libraries in a directory with no Administrator rights, e.g.
.libPaths("C:/R/libs")
On Ubuntu, the recommended way of changing the default library path for a user, is to set the R_LIBS_USER variable in the ~/.Renviron file.
touch ~/.Renviron
echo "R_LIBS_USER=/custom/path/in/absolute/form" >> ~/.Renviron
I've had real trouble understanding this. gorkypl gave the correct solution above when I last re-installed my OS & Rstudio but this time round, setting my environment variable didn't resolve.
Uninstallled both R and Rstudio, creating directories C:\R and C:\Rstudio then reinstalled both.
Define R_LIBS_USER user variable to your prefered directory (as per gorkypl's answer) and restart your machine for User variable to be loaded. Open Rstudio, errors should be gone.
You can also use Sys.setenv() to modify R_LIBS_USER to the path of your alternative library which is easier and does not need to restart your computer.
To see what R_LIBS_USER is set to:
?Sys.getenv()
Reading help(Startup) is useful.
If your default package library has been changed after installing a new version of R or by any other means, you can append both the libraries to use all the packages with the help of the commands below.
Get the existing library path :
.libPaths()
Now,set the existing and the old path :
.libPaths(c(.libPaths(), "~/yourOldPath"))
Hope it helps.
I read the readme. In that they mentioned use .libPaths() in command line to check which paths are there. I had 2 library paths earlier. When I used the command .libpath("C:/Program Files/R/R-3.2.4revised/library") where I wanted, it changed the library path. When I typed in .libPaths() at the command line again it showed me the correct path. Hope this helps
getwd()
# [1] "C:/Users/..../software/My R studio"
copy the above link with double inverted comma
.libPaths(new="C:/Users/..../software/My R studio")
Your default path will change for installing pakages
If you want to change your library path permanently (without calling .libPath() every time when entering in R, this works for me:
create .Rprofile under your home directory. (~/.Rprofile)
type
.libPaths(c( .libPaths(), "your new path" ))
in .Rprofile file, save.
open R (any directory) and check, just type .libPaths(), you can find your libaray path is updated!
Since most of the answers here are related to Windows & Mac OS, (and considering that I also struggled with this) I decided to post the process that helped me solve this problem on my Arch Linux setup.
Step 1:
Do a global search of your system (e.g. ANGRYSearch) for the term Renviron (which is the configuration file where the settings for the user libraries are set).
It should return only two results at the following directory paths:
/etc/R/
/usr/lib/R/etc/
NOTE: The Renviron config files stored at 1 & 2 (above) are hot-linked to each other (which means changes made to one file will automatically be applied [ in the same form / structure ] to the other file when the file being edited is saved - [ you also need sudo rights for saving the file post-edit ] ).
Step 2:
Navigate into the 1st directory path ( /etc/R/ ) and open the Renviron file with your favourite text editor.
Once inside the Renviron file search for the R_LIBS_USER tag and update the text in the curly braces section to your desired directory path.
EXAMPLE:
... Change From ( original entry ):
R_LIBS_USER=${R_LIBS_USER-'~/R/x86_64-pc-linux-gnu-library/4.0'}
... Change To ( your desired entry ):
R_LIBS_USER=${R_LIBS_USER-'~/Apps/R/rUserLibs'}
Step 3:
Save the Renviron file you've just edited ... DONE !!
I had the same problem and I run into this. If you want to create another location c("C:/Users/mynewlocation") should be working as well. As mentioned in here "You should be able to right-click on the Rstudio.exe icon, click Properties, and select an option to always run Rstudio as administrator. Be sure you use that same icon whenever you want to open Rstudio."
myPaths <- .libPaths() # get the paths
myPaths <- c(myPaths[2], myPaths[1]) # switch them
.libPaths(myPaths) # reassign them
I was looking into this because R was having issues installing into the default location and was instead just putting the packages into the temp folder. It turned out to be the latest update for Mcaffee Endpoint Security which apparently has issues with R. You can disable the threat protection while you install the packages and it will work properly.
I am trying to run a .run file in cygwin, but I always seem to get this error:
Unable to start '~.run': There is no application associated with the given file name extension.
I needed to be a superuser, so I tried using the command: cygstart --action=runas "$#"
I read somewhere that cygstart is for invoking registered Windows handler, so this may be the problem, but I am unsure. Is there any way that I can run my .run file as a superuser using cygwin?
Well, as has been said, no application is associated with .run files on your
system. So you can do that one of two ways
Call the file with the program, example
cygstart notepad.exe ~.run
Tell the registry what to do with unknown extensions
Windows Registry Editor Version 5.00
[HKEY_CLASSES_ROOT\Unknown]
#=""
[HKEY_CLASSES_ROOT\Unknown\shell\Open\command]
#="notepad.exe \"%1\""
This question is not related to Cygwin but rather to Windows. cygstart works the same as Windows' start. That means, if you use [cyg]start file.extension it works very similarly as if you double-click on that file in Windows Explorer.
Therefore if you configure Windows to do what you need when you double-click on your *.run file, cygstart will work fine too.
I think that easier is to use appropriate extension which Windows already knows. It depends on what you have inside your *.run file. If it's executable, use exe extension, if it's batch script, use cmd or bat, if it's JavaScript, use js etc.
If you use Linux or some derivation, you need to execute the .run file with an absolute path, even if you have already navigated to the appropriate directory containing the file. See here:
http://the-chronicon.blogspot.com/2011/08/execute-run-file-in-current-folder-from.html