Linux function name conflict MATLAB - linux

I'm currently using a MATLAB software suite which includes a function called "Swap". Running this code on my personal machine runs just fine, but when attempting to run on a Linux server, it seems to be trying to use the built-in "Swap" function on the Linux terminal.
Is there some way that I can force the terminal to ignore this built-in Swap and simply call the "Swap" function which is part of the MATLAB suite?
Thanks!

Assumptions: When you said built-in "Swap" function on the Linux terminal, I am assuming you are talking about running MATLAB on the linux terminal itself. I am also assuming that the built-in swap command is something from the MATLAB platform and not the linux environment and this answer is based on these assumptions.
In a general case, when you would like to add a function file whose name is identical to an already exisiting function, you have to move the path of the function file to be added to somewhere above the path of the existing function file in the list of MATLAB search paths. The way it works is that when you mention the use of a function, MATLAB starts looking for a match from the top until the bottom of the list.
One can view the MATLAB search paths by running -
path
So, to answer your question, just add the path of the suite to the top of MATLAB search paths by using addpath -
addpath(PATH_TO_SUITE);
If PATH_TO_SUITE has subdirectories, one of which has the swap function file, use genpath along with addpath -
addpath(genpath(PATH_TO_SUITE));
This could be interesting too for you to follow - Access m-files in a subfolder without permanently adding it to the path.

Related

PyCharm project path different from interactive session path

When running an interactive session, PyCharm thinks of os.getcwd() as my project's directory. However, when I run my script from the command line, PyCharm thinks of os.getcwd() as the directory of the script.
Is there a good workaround for this? Here is what I tried and did not like:
going to Run/Edit Configurations and changing the working directory manually. I did not like this solution, because I will have to do it for every script that I run.
having one line in my code that "fixes" the path for the purposes of interactive sessions and commenting it out before running from command line. This works, but feels wrong.
Is there a way to do this or is it just the way it is supposed to be? Maybe I shouldn't be trying to run random scripts within my project?
Any insight would be greatly appreciated.
Clarification:
By "interactive session" I mean being able to run each line individually in a Python/IPython Console
By "running from command line" I mean creating a script my_script.py and running python path_to_myscript/my_script.py (I actually press the Run button at PyCharm, but I think it's the same).
Other facts that might prove worth mentioning:
I have created a PyCharm project. This contains (among other things) the package Graphs, which contains the module Graph and some .txt files. When I do something within my Graph module (e.g. read a graph from a file), I like to test that things worked as expected. I do this by running a selection of lines (interactively). To read a .txt file, I have to go (using os.path.join()) from the current working directory (the project directory, ...\\project_name) to the module's directory ...\\project_name\\Graphs, where the file is located. However, when I run the whole script via the command line, the command reading the .txt file raises an Error, complaining that no file was found. By looking on the name of the file that was not found, I see that the full file name is something like this:
...\\project_name\\Graphs\\Graphs\\graph1.txt
It seems that this time the current working directory is ...\\project_name\\Graphs\\, and my os.path.join() command actually spoils it.
I user various methods in my python scripts.
set the working directory as first step of your code using os.chdir(some_existing_path)
This would mean all your other paths should be referenced to this, as you hard set the path. You just need to make sure it works from any location and your specifically in your IDE. Obviously, another os.chdir() would change the working directory and os.getcwd() would return the new working directory
set the working directory to __file__ by using os.chdir(os.path.dirname(__file__))
This is actually what I use most, as it is quite reliable, and then I reference all further paths or file operations to this. Or you can simply refer to as os.path.dirname(__file__) in your code without actually changing the working directory
get the working directory using os.getcwd()
And reference all path and file operations to this, knowing it will change based on how the script is launched. Note: do NOT assume that this returns the location of your script, it returns the working directory of the shell !!
[EDIT based on new information]
By "interactive session" I mean being able to run each line
individually in a Python/IPython Console
By running interactively line-by-line in a Python console, the __file__ is not defined, afterall: you are not executing a file. Hence you cannot use os.path.dirname(__file__) you will have to use something like os.chdir(some_known_existing_dir) to reference a path. As a programmer you need to be very aware of working directory and changes to this, your code should reflect that.
By "running from command line" I mean creating a script my_script.py
and running python path_to_myscript/my_script.py (I actually press the
Run button at PyCharm, but I think it's the same).
This, both executing a .py from command line as well as running in your IDE, will populate the __file__, hence you can use os.path.dirname(__file__)
HTH
I am purposely adding another answer to this post, in regards the following:
Other facts that might prove worth mentioning:
I have created a PyCharm project. This contains (among other things)
the package Graphs, which contains the module Graph and some .txt
files. When I do something within my Graph module (e.g. read a graph
from a file), I like to test that things worked as expected. I do this
by running a selection of lines (interactively). To read a .txt file,
I have to go (using os.path.join()) from the current working directory
(the project directory, ...\project_name) to the module's directory
...\project_name\Graphs, where the file is located. However, when I
run the whole script via the command line, the command reading the
.txt file raises an Error, complaining that no file was found. By
looking on the name of the file that was not found, I see that the
full file name is something like this:
...\project_name\Graphs\Graphs\graph1.txt It seems that this time
the current working directory is ...\project_name\Graphs\, and my
os.path.join() command actually spoils it.
I strongly believe that if a python script takes input from any file, that the author of the script needs to cater for this in the script.
What I mean is you as the author need to make sure you know the following regardless of how your script is executed:
What is the working directory
What is the script directory
These two you have no control over when you hand off your script to others, or run it on other peoples machines. The working directory is dependent on how the script is launched. It seems that you run on Windows, so here is an example:
C:\> c:\python\python your_script.py
The working directory is now C:\ if your_script.py is in C:\
C:\some_dir\another_dir\> c:\python\python.exe c:\your_script_dir\your_script.py
The working directory is now C:\some_dir\another_dir
And the above example may even give different results if the SYSTEM PATH variable is set to the path of the location of your_script.py
You need to ensure that your script works even if the user(s) of your script are placing this in various locations on their machines. Some people (and I don't know why) tend to put everything on the Desktop. You need to ensure your script can cope with this, including any spaces in the path name.
Furthermore, if your script is taking input from a file, the you as the author need to ensure that you can cope with changes in working directory, and changes of script directory. There are a few things you may consider:
Have your script input from a known (static) directory, something like C:\python_input\
Have your script input from a known (configurable) directory, use ConfigParser, you can search here on stackoverflow on many posts
Have your script input from a known directory related to the location of the script (using os.path.dirname(__file__))
any other method you may employ to ensure your script can get to the input
Ultimately this is all in your control, and you need to code to ensure it is working.
HTH,
Edwin.

AppleScript Replace File

I'd like to write an AppleScript for replacing three system files with ones I've modified. I'd like to do this with an AppleScript instead of manually replacing them because I'll have to replace three files every time there's an OS X update. Specifically, I'll be replacing stock graphics drivers with ones I've modified to support a graphics card which is connected via Thunderbolt. Is it possible to write an AppleScript for replacing one file with another? I ask because I know that when you replace a file, a dialog pops up with three options, and I don't know how to address that.
You can do this with Finder:
set freshFile to choose file
tell application "Finder"
move freshFile to desktop replacing yes
end tell
All you need to do is work out the source and destination paths to completely automate the script.
Many scripters do not like working with Finder, for a variety of reasons. If you want something that is incredibly fast, you would use the do shell script inside of your AppleScript:
do shell script " mv -f ~/Desktop/ArlandaTilUppsala.pdf ~/Documents/Employ.pdf"

Detect OS and change the path appropriately in R

I have two operating systems installed on my computer - windows and linux. When I write my scripts in windows and then I try to run them on linux, I have to change every path.
For example, to set my working directory in windows, I have to type setwd("d://MyStatistics").
However, in linux, this command is setwd("/media/55276F9D5951EC83/MyStatistics").
Is it possible to automatically detect current operation system and change the path if it is from the other system?
Use an if condition which tests R.version$platform or .Platform$OS.typ.
# It's as simple as...
path <- "/media/55276F9D5951EC83/MyStatistics"
if( .Platform$OS.type == "windows" )
path <- "d:\\MyStatistics"
setwd( path )
This link would be helpfull.
Sys.info() returns details of the platform R is running on
You could potentially achieve your "one path fits all" aim easily if both systems have the same sets of folders in one place (edit: just re-read the question, and since your talking about one computer, this should be the case). You could then either set that location as the working directory at the beginning of your script, using a method like Roland's answer, or make it the default directory that R opens with by adding it to Rprofile.site in each OS. You could then just set working directories by pasting to the initial directory.
Something like:
#add line to Rprofile.site for both OS
setwd("/path/to/folder/containing/data/folders")
then in the script:
starting.directory = getwd() #at beginning of script
setwd(paste0(starting.directory, "/MyStatistics"))
You could also add "starting.directory" as an object in Rprofile.site instead:
#add line to Rprofile.site for both OS
starting.directory <- "/path/to/folder/containing/data/folders"
then use the same paste0 as above.
You could also alter Rprofile.site in both OS to contain objects with names of various working directories, which point to the same folder with OS specific paths so that they can just be referred to as "setwd(myStatsDirectory)", and pasted to as above. Maybe the best way is to do something like that for every drive you'd like to be able to use with both systems, so you could do something like:
setwd(D.Drive)
setwd(paste0(D.Drive, "/folder1/folder2/etc"))
(edit: this is a similar method to Simon O'Hanlon's comment on Roland's answer, using tilde with the home directory)

File script searching for versioning

I need to search through all sub directories of a directory and find all files containing a "VERSION" string including a number.
I need to increment this number, so 1.1.2 will be incremented to 1.1.3 etc. and save it in the file again.
I need to run this on Windows machines only, if it makes any difference.
Can I do this with cmd commands or do I need to use a program for this ?
I would like to run this without installing anything if possible.
I ended up writing a Java program to go through the entire structure.
I found that using CMD commands was too complicated for me to structure, and using a Java program I could also easily reuse parts of the program in different but similar structures elsewhere in my file system.
The CMD usage could my the files for me, but extract a single line, manipulating it and putting it back inside the file was not easy using CMD commands, where as using Java was much easier.

Executing an Expect script from different locations

I am trying to run my Expect script from two different locations and it will work with the following Expect executables referenced:
My linux home directory (#!/usr/bin/expect)
A clearcase view on another server (#!/clearlib/vobs/otherdir/bin/expect)
The problem is that I cannot run the script in both places unless I change the reference of the Expect executable location to the first line of the file.
How can I get the correct instance of the Expect executable for the corresponding directory?
If your path is correctly set on both servers, you could use /usr/bin/env:
#!/usr/bin/env expect
That would use the expect as found in the PATH (/usr/bin in one case, /clearlib/vobs/otherdir/bin in the other)
By instead using env as in the example, the interpreter is searched for and located at the time the script is run.
This makes the script more portable, but also increases the risk that the wrong interpreter is selected because it searches for a match in every directory on the executable search path.
It also suffers from the same problem in that the path to the env binary may also be different on a per-machine basis.
And if you have issue with setting the right PATH, then "/usr/bin/env questions regarding shebang line pecularities" can help.

Resources