In what OS did the use of the '.' first mean 'the current directory' ?
In what OS did the use of the '.' first mean 'the current directory' ?
I think it was Unix (still trying to find the reference) Actually, it might be Multics (a project started in 1964), the first operating system to provide a hierarchical file system:
I think that Multics was the first to provide a hierarchical file system. The influence of that innovation can be found in virtually every modern operating system, including Unix, Mac OS, DOS and Windows. [JHS]
But I'm still trying to find the reference for the one period and two periods pointers.
i would guess dot = point = current target. but that's just my guess.
I believe its because '..' meant one directory up, so '.' was used for the current directory, which explicitly states to only look in the current directory, rather than the path.
Being the current point of reference?
Related
I have several Windows sourced p-files internally coded with the '\' file separator that I want to run on Matlab under macOS.
I get errors caused by the '\' because macOS uses '/'.
eg The pfile tries to call a file named "model\xyz' which causes a warning:
"Name is nonexistent or not a directory: model\ "
1) Is there code that I might insert somewhere to recognise the 'model\' call from the pcode file and change it to 'model/' before it is used by MATLAB addpath?
2) Is there a generic fix I could apply to the addpath code?
3) Or better still is there a way to modify the Windows p-file without access to its source code so that it will run under macOS?
There are several things you can do (none of which are particularly easy; listed here in increasing order of how nasty I think they are):
Contact the author of the code and ask them to fix it.
Install an older MATLAB version (R2007b <= ver < R2015b, I think) which allowed debugging (stepping into) p-files within MATLAB, then, assuming that there is some line in the original source code that does
filepath = ['model' '\' 'xyz.m'];
step until you see filepath appear in the workspace (having the wrong path in it), then simply edit the value to the correct path, and hope for the best.
(Essentially the same idea as before, but on newer MATLAB versions, VERY DIFFICULT to pull off) Obtain an external debugger, attach to the MATLAB process, run the p-file and scan the memory for the contents of filepath. When you discover it, change the value to the correct path and detach/disable the debugger.
If this code relies on some external (and open source) function to get (or use) the path, you can modify its behavior to output the string you want. This requires some knowledge about the source code.
Find/make a tool for decoding p-files and fix the resulting source code yourself.
For completeness I describe how my problem was solved:
As suggested by Dev-iL I was eventually able to locate the author and he modified his code. This is the best solution but it took some time and is not always possible.
Based on: https://au.mathworks.com/matlabcentral/answers/117110-dealing-with-and-windows-vs-unix-for-path-definition I located a module (I've forgotten its name) within the Matlab package which handles file calls and intercepted all incoming file path names containing the '\' Windows separator, and replaced them with the always acceptable '/'. This quick and dirty fix worked until solution 1. was obtained.
Thanks to all who responded so quickly to this question.
I am having this script to find a file and select it
set filePath to ("filePath.ext" as POSIX file)
tell application "Finder"
if (exists filePath) then
select filePath
activate
else
display alert "File " & filePath & " does not exist"
end if
end tell
it is working perfect well on Mac os x 10.6.x (LION) but when I try to run this script on Mac os x 10.5.x (snow-leopard) it is selecting file but taking too much time. Any suggestion how can I make this code work fine on both versions of Mac.
Thanks in advance :)
EDIT:
I am selecting file from a network drive and hostel system is having a Windows Os. All systems are located in the same network.
The reveal command may be of assistance to you. It simply locates a file in the finder, opens a new window if necessary, and then selects the file—all that using just one line of code:
tell application "Finder" to reveal path:to:some:file
The file must actually exist for this to work, of course. You know a particular file/directory exists when it is presented in alias form (I.e. Macintosh HD:Users:billybob:Desktop:howToHack.pdf). Attempting to coerce a nonexistent file into an alias will result in an error. If you are 100% certain that the file exists and know exactly where it is, congratulations! You have one less thing to worry about. If your certainty level is anything less than 100%, use a try-catch block. They have saved my life on multiple occasions. That way, if you distribute your applications via the Internet like I do, your clients are not presented with undecipherable error messages.
An example of this is demonstrated below:
set theFile to "/Users/billybob/Desktop/folder/subfolder/subfolder2/subfolder3/fineByMe.mp3"
try
set theFile to (theFile) as alias
tell application "Finder" to reveal theFile
on error
display alert "The file " & quoted form of theFile & "does not exist."
-- The variable 'theFile' couldn't be coerced into an alias.
-- Therefore, 'theFile' still has a string value and it can be used in dialogs/alerts among other things.
end try
Is this more efficient or less time consuming than what you've written? I'm not particularly sure, to be honest. However, I have written many scripts that have included the reveal command on Mac OS X 10.5.8 (Leopard), Mac OS X 10.6.8 (Snow-Leopard), and Mac OS X 10.7.3 (Lion), and the results have been satisfying.
You have errors in your code.
You forgot a period after "exists" in the display alert line.
You cannot display a posix file. It must be converted to string. Apple doesn't have this optimization.
The exists command will always return false the way you've used it because you didn't provide a full file path. Although java and c++ allow abbreviated file paths, apple does not.
I cannot comment, so I was forced to put this as an answer instead.
I have recently been working with Matlab. My question stems from my usage over a few months and is something that I can't seem to solve. I have an external SVM toolbox (OSU-SVM) that I would like to interface to with my project. I am able to get the entire system to work when I add the path of the toolbox manually (Right click -> Add to Path -> Selected Folders and Subfolders). What I would like to do is add the folder in a script. I've tried the "addpath" command but for some reason I can't get it to find the library relative to the m-file (script) that I run the command from. The following is an example of the code:
% Add OSU SVM system
addpath(genpath('./osu-svm/'));
The reason the I'd like to add the path using a relative folder to the M-file is that the code needs to run in a different environment that will not have the toolbox install. The code is also going to be executed in a different OS to the one I am developing on. That is, I am running a Windows Matlab to develop the code and need to run the finished system on a Linux machine. The process of running my files needs to be as painless as possible and shouldn't require much input from the user. That is why I'm specifically trying to avoid manual addition of the path.
On a side note a similar problem occurs when I wish to use "uigetfile" using a relative path. I believe there is something I am missing that will help me solve both of these simultaneously. Any help would be greatly appreciated.
Instead of './osu-svm/' alone use
fullfile('.','osu-svm')
The reason it does not work for you on windows is that you are using forward slash file separators. Full file will make a file string containing the correct file separator for each OS.
The genpath example in the matlab documentation also uses fullfile
http://www.mathworks.co.uk/help/techdoc/ref/genpath.html
Furthermore, the '.' is kinda unnecessary as it just means "relative to the current directory" and can be left out of the command. Perhaps you meant one directory up?
'..'
???
In solaris when open call to char special device file is made in user space, the driver's open call is called with only two parameters. 1. major and minor number and 2. flag that contains read/write etc.. Is there any way to the get the name of the opened device file in driver's open call. or Is there any way to get the name of the device file from major and minor number in driver code?
I doubt the OS has any way to retrieve the name of the device file. Actually, this file name is not enforced by the OS and can be any name created with the mknod command. The only things that matter are the major and minor device numbers.
You can go through the lists of entries in /dev or /devices and compare the numbers. But of course in general, the special file could have been created anywhere in the filesystem.
But you shouldn't try doing this. Which problem are you trying to solve by this?
I run MATLAB on both Linux and Windows XP. My files are synced among all of the computers I use, but because of the differences in directory structure between Linux and Windows I have to have separate import and export lines for the different operating systems. At the moment I just comment out the line for the wrong OS, but I am wondering if it is possible to write something like:
if OS == Windows
datafile = csvread('C:\Documents and Settings\Me\MyPath\inputfile.csv');
else
datafile = csvread('/home/Me/MyPath/inputfile.csv');
end
This is also a more general question that applies in cases where one wants to execute system commands from within MATLAB using system('command').
You can use ispc/isunix/ismac functions to determine the platform or even use the computer function for more information about the machine
if ispc
datafile = csvread('C:\Documents and Settings\Me\MyPath\inputfile.csv');
else
datafile = csvread('/home/Me/MyPath/inputfile.csv');
end
To follow up on Amro's answer, I was going to just make a comment but struggled with the formatting for the code.
I'd prefer to split the OS selection from the file read.
if ispc
strFile = 'C:\Documents and Settings\Me\MyPath\inputfile.csv';
else
strFile = '/home/Me/MyPath/inputfile.csv';
end
try
datafile = csvread(strFile);
catch
% setup any error handling
error(['Error reading file : ',strFile]);
end
That way if I need to change the way the file is read, perhaps with another function, it's only one line to change. Also it keeps the error handling simple and local, one error statement can handle either format.
Just to add a minor point to the existing good answers, I tend to use fileparts and fullfile when building paths that need to work on both UNIX and Windows variants, as those know how to deal with slashes correctly.
In addition to using the various techniques here for dealing with path and file separator differences, you should consider simply trying to avoid coding in absolute paths into your scripts. If you must use them, try to put them in as few files as possible. This will make your porting effort simplest.
Some ideas:
Set a fileRoot variable at some early entry point or config file. Use fullfile or any of the other techniques for constructing a full path.
Always use relative paths, relative to where the user is operating. This can make it easy for the user to put the input/output wherever is desired.
Parameterize the input and output paths at your function entries (e.g., via a system specific context object).
If the directory structures are within your home directory you could try building a single path that can be used on both platforms as follows (my Matlab is a bit rough so some of the syntax may not be 100%):
See here for how to get the home directory for the user
Create the path as follows (filesep is a function that returns the file separator for the platform you are running on)
filepath = [userdir filesep 'MyPath' filesep 'inputfile.csv']
Read the file
datafile = csvread(filepath)
Otherwise go with Amros answer. It is simpler.