I am running the following code:
DIRECTORY ='/Users/myfolder/output/cond';
saveF = '/Users/myfolder/output';
Ext = '*cond.mat';
cd(DIRECTORY)
Files = dir(Ext);
process = size(Files,1);
However, every time I try to run it, a previous Directory (DIRectory) appears in the workspace, in addition to the variables created in the script. This causes issues later on, because it tries to load files that are in the DIRectory, instead of DIRECTORY.
I tried to call clear all, clear, and to directly clear from the workspace, but with no success.
I also tried to close Matlab and to restart my computer, but it doesn't work. The previous deleted DIRectory appears again and again in the workspace.
I also thought that the same spelling may have caused the problem. However, even if I change the name DIRECTORY to 'folder', when I run the script, the variable DIRectory reappears....
Related
I've just created a script file in MATLAB, but can not run it. The name of my script is getEnvFiles.m. When I first tried to run it, I got the following result:
>> getEnvFiles
'getEnvFiles' is not found in the current folder or on the MATLAB path, but exists in:
\\wsl$\ubuntu\home\me
Change the MATLAB current folder or add its folder to the MATLAB path.
So, I added this directory (which is actually the current directory) to the search path, but still got the same result:
>> addpath('\\wsl$\ubuntu\home\me')
>> getEnvFiles
'getEnvFiles' is not found in the current folder or on the MATLAB path, but exists in:
\\wsl$\ubuntu\home\me
Change the MATLAB current folder or add its folder to the MATLAB path.
When I check the path, it looks like this directory is on the path:
>> path
MATLABPATH
\\wsl$\ubuntu\home\me
I can further verify that this directory is my present directory:
>> pwd
ans =
'\\wsl$\ubuntu\home\me'
and that getEnvFiles.m is in this directory:
>> ls
. .emacs.d HarborData
.. .emacs~ RawHarborData
.bash_history .landscape at
.bash_logout .motd_shown getEnvFiles.m
.bashrc .profile test.m
.bashrc~ .sudo_as_admin_successful
.emacs
Is the issue that I'm using wsl (Windows Subsystem for Linux), or do I have some other misunderstanding?
Type rehash and then try running your script again. Even though you have added the new directory to your path, you need to update the path cache so that it knows about the new scripts it can see.
The problem seems to lie in WSL's ability to add new files to the directory. When I create a new script within MATLAB, and try to run it, I get the problem discussed above. However, running already existing files is not a problem. For now, my only solution is to close MATLAB after creating a new script and reopen it. Then, I can run it. Although, oddly, I can't open it in MATLAB's editor.....
This may or may not help, but ...
Sometimes you have to prepend execution with .\ in order to run scripts in PowerShell or from within the command prompt (in Windows, I'm not sure about other operating systems).
I get this error quite often, especially when not in Admin mode.
Does this work?
% Get path of executing script.
filePath = matlab.desktop.editor.getActiveFilename; % Note that this isn't necessarily the same as the output of 'pwd()'.
% Or: filePath = mfilename('fullpath')
% Make sure all nested directories of filePath are on the path, then tell MATLAB where you're working.
addpath( genpath( filePath ) ); % If this fails, try one folder up the tree:
% addpath( genpath( fullfile( filePath, '.' ) );
cd( filePath );
Alternatively, it looks like you might have written and saved the script, and then typed it into the command window to execute. If it's not a special type of script (Function/Class/GUI/etc.) then you can simply click 'Run' in the Editor tab (or the F5 key) and MATLAB should prompt you with a 'Change Folder' option, to which you should acquiesce.
If you're running this script through the WSL terminal, try my suggested code.
in my startup.m-file I call a script init.m. In this init file I determine the folder containing this file, want to set the current directory to this folder and continue with some other initialization stuff.
But when I start Matlab, the file will be executed, but the cd command seems to be ignored and the directory won't get changed. Does somebody know why? I.e. the matlabpath variable is extended by the subfolders....
startup.m:
run 'D:\FloatingZone\mscrystalgrowth\trunk\MATLAB\FzKameradaten\FzCameraEvaluation\init.m';
init.m
% get path to folder containing this function
folder=mfilename('fullpath');
file=mfilename();
folder=folder(1:end-length(file));
% change folder
cd(folder);
% add subfolder to the top of the MATLAB path
addpath(genpath('Tools'));
MATLAB did exactly what you told it; there's nothing special about the startup scripts.
From the documentation for the run command:
run changes to the folder that contains the script, executes it, and resets back to the original folder. If the script itself changes folders, then run does not revert to the original folder, unless scriptname changes to the folder in which this script resides.
So your cd command didn't actually do anything, run had already changed the directory. And then changed it back, exactly as expected.
I'm not 100% clear on what you want your startup to do. As already pointed out run is working correctly.
Alternative startup.m
if isdeployed == false
cd 'D:\FloatingZone\mscrystalgrowth\trunk\MATLAB\FzKameradaten\FzCameraEvaluation\'
init();
end
function init.m stored in your FzCameraEvaluation\ folder.
function init
addpath ( genpath ( '../Tools' ) );
end
Does that work?
I'm using Sphinx on a Linux production server as well as a Windows dev machine running WampServer.
The index configurations in sphinx.conf each require a path setting for the output file name. Because the filesystems on the production server and dev machine are different, I have to have two lines and then comment one out depending on which server I'm using.
#path = /path/to/folder/name #LIVE
path = C:\wamp\www\site\path\to\folder\name #LOCALHOST
Since I have lots of indexes, it gets really old having to constantly comment and uncomment dozens of lines every time I need to update the file.
Using relative paths would be the ideal solution, but when I tried that I received the following error when running the indexer:
FATAL: failed to open ../folder/name.tmp.spl: Invalid argument, will not index. Try --rotate option.
Is it possible to use relative paths in sphinx.conf?
You can use relative paths, but its kind of tricky because you the various utilities will have different working directories.
eg On windows the searchd service, will start IIRC with a working directory of $WINDIR$\System32
on linux, via crontab, I think it has working directory left over from previously, so would have to change the folder in the actual command line
... ie its not relative to the config file, its relative to the current working directory.
Personally I use a version control system (SVN actually) to manage it. The version from Dev, is always the one commited to the repository, the 'working copy' on the LIVE server, has had the paths edited to the right location. So when 'update' to the latest file, only changes are merged leaving the local filepaths in tact.
Other people use a dynamic config file. The config file can be a script (php/python/perl etc) - but this only works on linux so wont help you.
Or can just have a 'publish' script. Basically, you edit a 'master' config file, and one that can be freely copied to all servers. Then a 'publish' script, that writes the apprirate local path. It could do it with some pretty simple search replace.
<?php
if (trim(`hostname`) == 'live') {
$path = '/path/to/folder/';
} else {
$path = 'C:\wamp\www\site\path\to\folder\`;
}
$contents = file_get_contents('sphinx.conf.master');
$contents = str_replace('$path',$path,$contents);
file_put_contents('sphinx.conf',$contents);
Then have path = $path\name in the master config file, which will get replaced to the proper path, when run the script on the local machine
Is there a way to change the current working directory to current script directory with running code just inside one block of script? Script folder is not added to path.
Redefined: Is there a way to to change the current working directory to script that's currently active in editor?
I found the solution (was looking in wrong direction before).
tmp = matlab.desktop.editor.getActive;
cd(fileparts(tmp.Filename));
You can use mfilename to get the current script name, cd(fileparts(mfilename)) should change to the correct directory.
If you frequently have to run scripts which need to be run in their script directory, you can use this function:
function varargout=run_in_dir(fun,varargin)
location=which(func2str(fun));
assert(exist(location,'file')~=0,'fun does not seem to be a m. file');
old_dir=pwd;
cd(fileparts(location));
try
if ~isempty(varargin)
[varargout{1:nargout}]=fun(varargin{:});
else
[varargout{1:nargout}]=fun();
end
catch ME
cd(old_dir)
rethrow(ME)
end
cd(old_dir)
end
To run sin(3) in the directory where sin is defined, use run_in_dir(#sin,3)
On all my Windows servers, except for one machine, when I execute the following code to allocate a temporary files folder:
use CGI;
my $tmpfile = new CGITempFile(1);
print "tmpfile='", $tmpfile->as_string(), "'\n";
The variable $tmpfile is assigned the value '.\CGItemp1' and this is what I want. But on one of my servers it's incorrectly set to C:\temp\CGItemp1.
All the servers are running Windows 2003 Standard Edition, IIS6 and ActivePerl 5.8.8.822 (upgrading to later version of Perl not an option). The result is always the same when running a script from the command line or in IIS as a CGI script (where scriptmap .pl = c:\perl\bin\perl.exe "%s" %s).
How I can fix this Perl installation and force it to return '.\CGItemp1' by default?
I've even copied the whole Perl folder from one of the working servers to this machine but no joy.
#Hometoast:
I checked the 'TMP' and 'TEMP' environment variables and also $ENV{TMP} and $ENV{TEMP} and they're identical.
From command line they point to the user profile directory, for example:
C:\DOCUME~1\[USERNAME]\LOCALS~1\Temp\1
When run under IIS as a CGI script they both point to:
c:\windows\temp
In registry key HKEY_USERS/.DEFAULT/Environment, both servers have:
%USERPROFILE%\Local Settings\Temp
The ActiveState implementation of CGITempFile() is clearly using an alternative mechanism to determine how it should generate the temporary folder.
#Ranguard:
The real problem is with the CGI.pm module and attachment handling. Whenever a file is uploaded to the site CGI.pm needs to store it somewhere temporary. To do this CGITempFile() is called within CGI.pm to allocate a temporary folder. So unfortunately I can't use File::Temp. Thanks anyway.
#Chris:
That helped a bunch. I did have a quick scan through the CGI.pm source earlier but your suggestion made me go back and look at it more studiously to understand the underlying algorithm. I got things working, but the oddest thing is that there was originally no c:\temp folder on the server.
To obtain a temporary fix I created a c:\temp folder and set the relevant permissions for the website's anonymous user account. But because this is a shared box I couldn't leave things that way, even though the temp files were being deleted. To cut a long story short, I renamed the c:\temp folder to something different and magically the correct '.\' folder path was being returned. I also noticed that the customer had enabled FrontPage extensions on the site, which removes write access for the anonymous user account on the website folders, so this permission needed re-applying. I'm still at a loss as to why at the start of this issue CGITempFile() was returning c:\temp, even though that folder didn't exist, and why it magically started working again.
The name of the temporary directory is held in $CGITempFile::TMPDIRECTORY and initialised in the find_tempdir function in CGI.pm.
The algorithm for choosing the temporary directory is described in the CGI.pm documentation (search for -private_tempfiles).
IIUC, if a C:\Temp folder exists on the server, CGI.pm will use it. If none of the directories checked in find_tempdir exist, then the current directory "." is used.
I hope this helps.
Not the direct answer to your question, but have you tried using File::Temp?
It is specifically designed to work on any OS.
If you're running this script as you, check the %TEMP% environment variable to see if if it differs.
If IIS is executing, check the values in registry for TMP and TEMP under
HKEY_USERS/.DEFAULT/Environment