I just shifted from a windows machine to a apple machine at work. I have no experience with apple and this is the first time I am using OSX.
I have a matlab script that I have to run on this machine but I cannot seem to get the path to my files.
My files are on a network drive. In windows its as simple as U:\Matlab Now I can access my files in the explorer but cannot seem to set them in Matlab using cd
To get the path of my files I right clicked on the folder and copied the where It provided me with this:
Volumes/home9/MATLAB/
Now to set these paths in Matlab I did this:
cd('Volumes/home9/MATLAB/')
But am provided with the error:
Cannot CD to Volumes/home9/MATLAB/ (Name is nonexistent or not a directory).
As you can tell I have no idea what I am doing. Some guidance would be appreciated.
Thank you
I think you meant to use which, not where. where doesn't exist in MATLAB! Now, your problem is probably due to the fact that you need to prepend your path with /. Therefore, your path should be: /Volumes/home9/MATLAB/. If you don't include the /, it assumes that the directory is local or where MATLAB has currently defined the working directory to be. Judging from the context, you want the absolute path of the directory, and that's why you need the / character as there is a Volumes directory in your root directory.
Try that and see if that works!
Related
My book states:
Every program that runs on your computer has a current working directory, or cwd. Any filenames or paths that do not begin with the root folder are assumed to be under the current working directory
As I am on OSX, my root folder is /. When I type in os.getcwd() in my Python shell, I get /Users/apple/Documents. Why am I getting the Documents folder in my cwd? Is it saying that Python is using Documents folder? Isn't there any path heading to Python that begins with / (the root folder)? Also, does every program have a different cwd?
Every process has a current directory. When a process starts, it simply inherits the current directory from its parent process; and it's not, for example, set to the directory which contains the program you are running.
For a more detailed explanation, read on.
When disks became large enough that you did not want all your files in the same place, operating system vendors came up with a way to structure files in directories. So instead of saving everything in the same directory (or "folder" as beginners are now taught to call it) you could create new collections and other new collections inside of those (except in some early implementations directories could not contain other directories!)
Fundamentally, a directory is just a peculiar type of file, whose contents is a collection of other files, which can also include other directories.
On a primitive operating system, that was where the story ended. If you wanted to print a file called term_paper.txt which was in the directory spring_semester which in turn was in the directory 2021 which was in the directory studies in the directory mine, you would have to say
print mine/studies/2021/spring_semester/term_paper.txt
(except the command was probably something more arcane than print, and the directory separator might have been something crazy like square brackets and colons, or something;
lpr [mine:studies:2021:spring_semester]term_paper.txt
but this is unimportant for this exposition) and if you wanted to copy the file, you would have to spell out the whole enchilada twice:
copy mine/studies/2021/spring_semester/term_paper.txt mine/studies/2021/spring_semester/term_paper.backup
Then came the concept of a current working directory. What if you could say "from now on, until I say otherwise, all the files I am talking about will be in this particular directory". Thus was the cd command born (except on old systems like VMS it was called something clunkier, like SET DEFAULT).
cd mine/studies/2021/spring_semester
print term_paper.txt
copy term_paper.txt term_paper.backup
That's really all there is to it. When you cd (or, in Python, os.chdir()), you change your current working directory. It stays until you log out (or otherwise exit this process), or until you cd to a different working directory, or switch to a different process or window where you are running a separate command which has its own current working directory. Just like you can have your file browser (Explorer or Finder or Nautilus or whatever it's called) open with multiple windows in different directories, you can have multiple terminals open, and each one runs a shell which has its own independent current working directory.
So when you type pwd into a terminal (or cwd or whatever the command is called in your command language) the result will pretty much depend on what you happened to do in that window or process before, and probably depends on how you created that window or process. On many Unix-like systems, when you create a new terminal window with an associated shell process, it is originally opened in your home directory (/home/you on many Unix systems, /Users/you on a Mac, something more or less like C:\Users\you on recent Windows) though probably your terminal can be configured to open somewhere else (commonly Desktop or Documents inside your home directory on some ostensibly "modern" and "friendly" systems).
Many beginners have a vague and incomplete mental model of what happens when you run a program. Many will incessantly cd into whichever directory contains their script or program, and be genuinely scared and confused when you tell them that you don't have to. If frobozz is in /home/you/bin then you don't have to
cd /home/you/bin
./frobozz
because you can simply run it directly with
/home/you/bin/frobozz
and similarly if ls is in /bin you most definitely don't
cd /bin
./ls
just to get a directory listing.
Furthermore, like the ls (or on Windows, dir) example should readily convince you, any program you run will look in your current directory for files. Not the directory the program or script was saved in. Because if that were the case, ls could only produce a listing of the directory it's in (/bin) -- there is nothing special about the directory listing program, or the copy program, or the word processor program; they all, by design, look in the current working directory (though again, some GUI programs will start with e.g. your Documents directory as their current working directory, by design, at least if you don't tell them otherwise).
Many beginners write scripts which demand that the input and output files are in a particular directory inside a particular user's home directory, but this is just poor design; a well-written program will simply look in the current working directory for its input files unless instructed otherwise, and write output to the current directory (or perhaps create a new directory in the current directory for its output if it consists of multiple files).
Python, then, is no different from any other programs. If your current working directory is /Users/you/Documents when you run python then that directory is what os.getcwd() inside your Python script or interpreter will produce (unless you separately os.chdir() to a different directory during runtime; but again, this is probably unnecessary, and often a sign that a script was written by a beginner). And if your Python script accepts a file name parameter, it probably should simply get the operating system to open whatever the user passed in, which means relative file names are relative to the invoking user's current working directory.
python /home/you/bin/script.py file.txt
should simply open(sys.argv[1]) and fail with an error if file.txt does not exist in the current directory. Let's say that again; it doesn't look in /home/you/bin for file.txt -- unless of course that is also the current working directory of you, the invoking user, in which case of course you could simply write
python script.py file.txt
On a related note, many beginners needlessly try something like
with open(os.path.join(os.getcwd(), "input.txt")) as data:
...
which needlessly calls os.getcwd(). Why is it needless? If you have been following along, you know the answer already: the operating system will look for relative file names (like here, input.txt) in the current working directory anyway. So all you need is
with open("input.txt") as data:
...
One final remark. On Unix-like systems, all files are ultimately inside the root directory / which contains a number of other directories (and usually regular users are not allowed to write anything there, and system administrators with the privilege to do it typically don't want to). Every relative file name can be turned into an absolute file name by tracing the path from the root directory to the current directory. So if the file we want to access is in /home/you/Documents/file.txt it means that home is in the root directory, and contains you, which contains Documents, which contains file.txt. If your current working directory were /home you could refer to the same file by the relative path you/Documents/file.txt; and if your current directory was /home/you, the relative path to it would be Documents/file.txt (and if your current directory was /home/you/Music you could say ../Documents/file.txt but let's not take this example any further now).
Windows has a slightly different arrangement, with a number of drives with single-letter identifiers, each with its own root directory; so the root of the C: drive is C:\ and the root of the D: drive is D:\ etc. (and the directory separator is a backslash instead of a slash, although you can use a slash instead pretty much everywhere, which is often a good idea for preserving your sanity).
Your python interpreter location is based off of how you launched it, as well as subsequent actions taken after launching it like use of the os module to navigate your file system. Merely starting the interpreter will place you in the directory of your python installation (not the same on different operating systems). On the other hand, if you start by editing or running a file within a specific directory, your location will be the folder of the file you were editing. If you need to run the interpreter in a certain directory and you are using idle for example, it is easiest to start by creating a python file there one way or another and when you edit it you can start a shell with Run > Python Shell which will already be in that directory. If you are using the command line interpreter, navigate to the folder where you want to run your interpreter before running the python/python3/py command. If you need to navigate manually, you can of course use the following which has already been mentioned:
import os
os.chdir('full_path_to_your_directory')
This has nothing to do with osx in particular, it's more of a concept shared by all unix-based systems, and I believe Windows as well. os.getcwd() is the equivalent of the bash pwd command - it simply returns the full path of the current location in which you are in. In other words:
alex#suse:~> cd /
alex#suse:/> python
Python 2.7.12 (default, Jul 01 2016, 15:34:22) [GCC] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>> os.getcwd()
'/'
It depends from where you started the python shell/script.
Python is usually (except if you are working with virtual environments) accessible from any of your directory. You can check the variables in your path and Python should be available. So the directory you get when you ask Python is the one in which you started Python. Change directory in your shell before starting Python and you will see you will it.
os.getcwd() has nothing to do with OSX in particular. It simply returns the directory/location of the source-file. If my source-file is on my desktop it would return C:\Users\Dave\Desktop\ or let say the source-file is saved on an external storage device it could return something like G:\Programs\. It is the same for both unix-based and Windows systems.
I'm working on the Mac Terminal with the program called QIIME. However, my question is more related to basic navigating in the terminal.
When I enter a command, and would like to refer to a file that is located in a directory/map inside my current working directory, how do I do this?
For example:
convert_fastaqual_fastq.py -f sequenceA.fastq
Now sequenceA is located in a map in my working directory, so I guess I'll have to add arguments before sequenceA.qual, or shouldn't I ?
from your working directory you should be able to access that file with:
the_directory_your_file_is_in/sequenceA.qual
else, you could use something like:
./the_directory_your_file_is_in/sequenceA.qual
A point stands for the directory your are currently in.
../the-directory-you-are-in/the_directory_your_file_is_in/sequenceA.qual
Two points stand for the directory above your current directory.
I am having difficulty installing something, and wanted to write a detailed list of what I did (including all paths, because I am new to Linux, and have problems reading things unless the full path is listed)
1) I am trying to run a program called "pslToBed". I downloaded it from here (http://hgdownload.cse.ucsc.edu/admin/exe/linux.x86_64/).
2) It downloaded a single file called "pslToBed". It looks like a binary file (all jibberish at least), and I saved to the directory /Users/MacOwner/Desktop/rnaseq/pslToBed
3) I did echo $PATH, and got the following
/usr/local/bin:/Users/MacOwner/anaconda/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/local/git/bin:/usr/texbin:/usr/X11/bin:/opt/local/bin:~/bin:/Users/MacOwner/Desktop/bedtools2-2.19.1
4) I selected one path from step (3), namely /usr/local/bin
5) I did: cp /Users/MacOwner/Desktop/rnaseq/pslToBed /usr/local/bin/
6) I added the same line to the bottom of both ~/.bashrc and ~./bash_profile:
export PATH=$PATH:/usr/local/bin/pslToBed
Then, I returned to /Users/MacOwner/Desktop/rnaseq/ and tried to run pslToBed but got an error -bash: /usr/local/bin/pslToBed: cannot execute binary file
I know this may be straightforward to experienced users, but I am stuck, even after searching the internet for several hours now. Do my paths and ideas look correct? And if not, what should I do to get this program running?
First, see what kind of file you have:
file plsToBed
This will print the kind of file (including details about the target architecture).
Next, there's no need to copy the file anywhere before trying to run it. If it's in a particular location and you have cd to that location, then simply:
./plsToBed
will execute it from the current directory.
You shouldn't have been able to copy to /usr/local/bin without being root (I hope you're not doing all this as root).
You don't want to add the name of the file itself to the PATH environment variable; the PATH is a list of directories, not files.
I used addpath(pwd) to get my .m files working in my projects directory. When I close the window and start a new window, the path I just added is gone. But the files still run.
Is it in my path or not? How do I see the directories I have added to my path?
Also, . is the first entry I see from path. Does that mean I don't need to add any directories because it will always search the current directory first?
Thanks.
Basically, yes.
You can add a directory to the search path using addpath(), but as you know, it only exists for the current session and is reset when you restart Octave. If you want a path to survive between sessions, add it to your octaverc, a script file that gets run whenever a new session gets started. Example path to octaverc file is:
C:\Octave\3.2.4_gcc-4.4.0\share\octave\site\m\startup
Since . is in your path by default, Octave will search your current directory for any function files that it needs. Using addpath(pwd) is somewhat useless if you're just going to stay in the same directory. However, there are some cases where it'd be useful, if for example you have a directory that contains your functions, and another one that has the data that you're working on: you could start in the functions directory, do addpath(pwd), and then cd to the data directory while still being able to use your functions.
You can create batch file, which will start Octave with your directory path. Please see example below:
octave-3.6.4.exe -p "C:\MyOctaveDiretory"
-p means addpath()
addpath(pwd); savepath();
Done.
I think there is a bug in Octave (I use version 4.0.3 on Windows). When I create a new file in current path, this can't be called by Octave ("error: 'foo' undefined near line 1 column 1"). If I restart Octave, it works. This addpath(pwd) trick helps me a lot (before I unsuccessfully tried rehash() and cd elsewhere and back again).
If you had the same problem, the reason for the symptom might be:
Start Octave.
Create newfile.m.
Call newfile - fails since Octave did not register its existence.
addpath(pwd) - causes Octave to register it.
Close Octave
Start Octave - now pwd is gone from path, but newfile.m is registered at startup.
call newfile - works
I faced a similar problem in adding path where the path was added by using addpath command directly in Octave GUI (Command Window). The path added was being shown in console window but none of the functions worked.
The problem was solved by changing the path directory from Windows directory to some other direction where OS is not installed.
I am trying to read in from a few files using something like this
IO.foreach("TeamFields.txt") { |line| fieldNames.push(line.chomp) }
It works fine when running the from the command line, but when I package to an .exe with shoes and run it can't find the file. Is there a way to specify a path relative the the .exe or do I have to provide the full filepath (e.g. "c:\files\TeamFields.txt")? Thanks for the help.
This is because your executable is not run with the correct current directory.
Either fix the current directory (for example in the shortcut) or modify your Ruby program to automatically set the working directory to the program directory with:
Dir.chdir(File.dirname($PROGRAM_NAME))
You need to set "Current Application Directory" correctly before going relative.
The user can execute your app with different start up dir, or system can call your app with different dir.
If files in question are in the folder of your app, the only thing you need to do is to get that folder, and set it to be current.
I don't program in ruby, but I do with windows, and odds are the relative path will be based on the location of the .exe file.
So, yes, you're probably better off passing a full path for the file name.
The constant __FILE__ will contain the full path to the currently executing file. You can then use methods of the File class to strip off the filename, append the relative path for whatever other file in your package it is you want and resolve the result.