How do I reset MATLAB to its launched state?

Is it possible to "reset" MATLAB? Sometimes I want to "restore" MATLAB to the way it is when it is launched (not the way it was when it is installed). Closing all the figures, resetting the path and clearing variables is relatively easy, but not as easy as:
close all; clear all; path(pathdef); clc;
You need extra flags since the "all" flag is not really all (e.g., a figure might be hidden or mfiles files might be locked).
Resetting non-persistent "default" values is harder. For example, if at some point the "DefaultFigurePosition" is modified:
set(0, 'DefaultFigurePosition', [100, 100, 100, 100])
that change needs to be identified and reversed.
The list of things to get a full reset seems long to me. There are also issues about do I want to restore MATLAB to the way it was when it started or the way it will be the next time it starts. At this point I would be happy with either (or a mix).

2 Comments

i am not getting >> ???
***** exit worked
its not working for me... I'm getting the same issue where there is no >> Are you entering exit it in the command window?

Sign in to comment.

 Accepted Answer

If you want it clean and simple:
!matlab &
exit

6 Comments

The more I/we play, the more I think this is the correct answer.
I'm very proud of finding out, that EXIT sets Matlab to a well defined status.
Unless you messed up paths so bad that it says XD
Unable to run the 'exit' function, because it is not supported for this product offering.
worked well
thanks
As much as the "big hammer" solution seems inelegant, at least for me in R2019b, exit() usually causes MATLAB to hang. As far as I'm concerned, the answer is a panel applet that runs a script to kill MATLAB (i.e. an even bigger hammer) :D

Sign in to comment.

More Answers (2)

The hidden figures are closed by "close all hidden". Clearing the locked M-files can be controlled by unlocking all files loaded into memory. The default properties are set to the factory values at first and then adjusted to their local values in MATLABRC.
Script file TotalReset.m (not as function!)
% Clear command window:
clc;
% Close figures:
try
close('all', 'hidden');
catch % do nothing
end
% Closing figures might fail if the CloseRequestFcn of a figure
% blocks the execution. Fallback:
AllFig = allchild(0);
if ~isempty(AllFig)
set(AllFig, 'CloseRequestFcn', '', 'DeleteFcn', '');
delete(AllFig);
end
% EDITED: Initialize the default rand stream:
s = RandStream('mt19937ar', 'seed', 0);
RandStream.setDefaultStream(s);
% Clear loaded functions:
% (I avoid "clear all" here for educational reasons)
clear('functions');
clear('classes');
clear('java');
clear('global');
clear('import'); % Not from inside a function!
clear('variables');
% Stop and delete timers:
AllTimer = timerfindall;
if ~isempty(AllTimer) % EDITED: added check
stop(AllTimer);
delete(AllTimer);
end
% Unlock M-files:
LoadedM = inmem;
for iLoadedM = 1:length(LoadedM)
% EDITED: Use STRTOK to consider OO methods:
aLoadedM = strtok(LoadedM{iLoadedM}, '.');
munlock(aLoadedM);
clear(aLoadedM);
end
% Close open files:
fclose('all');
% Reset the warning status EDITED:
warning('on', 'all');
lasterror('reset');
lastwarn('');
% Remove <Default>Properties from root:
prop = get(0, 'default');
propname = fieldnames(prop);
for iprop = 1:length(propname)
set(0, propname{iprop}, 'remove');
end
% EDITED: Change to 1st user path to find "startup.m":
cd(strtok(userpath, pathsep));
% Restore original <Default>Properties of root,
% load default PATH, run STARTUP.m:
matlabrc;
% EDITED: No PACK even in scripts
Limitation: I don't know how to unlock Mex files externally and start a memory cleaning by PACK inside a script or function
EDITED: I've moved my second approach to a new answer.

15 Comments

This is very close, so I want to point out some bugs/typos if other people try this:
fclose('all); should be fclose('all');
stop(AllTimer);
delete(AllTimer);
should not be evaluated if AllTimer is empty
if ~isempty(AllTimer)
stop(AllTimer);
delete(AllTimer);
end
pack cannot be used in a script or from a shortcut.
Thank you for the answer. It is close to what I had. You deal with the default property names very nicely. I left closing files, fclose('all'), out of my script.
There are three obvious problems.
1. matlabrc does not reset the warning status, you need warning('on', 'all') to reset custom warning states.
2. If you are not at the prompt, but have entered "keyboard", this will fail. Something like:
try %#ok<TRYNC>
dbquit('all');
end
gets around that.
3. You do not change the directory. If I am working in a directory with a startup.m file, but MATLAB does not launch in this directory, startup.m is run, even though it would not be if I restarted MATLAB.
As you note, you do not reset the random number generators. I wonder if there are other things missing.
@Daniel: Thanks for crosschecking. Typos fixed.
Added: Reset LASTWARN and LASTERROR. RandStream is re-initialized now.
This is obvioulsy a cruel task. I cannot believe, that we've found all persistent data. The locked Mex files remain unresolved.
dbquit('all') stops the current function, and the TotalReset script also! "clear('import')" and "clear('variables')" is useful if TotalRest is called from the command line also. So I'd limit the use for a command line call and ignore problems originating from calling this script in debug mode.
You broke it again ...
By reseting the random stream you load something called RandStream.RandStream, into memory (inmem), but it unlocks with munlock('RandStream'). I also run into a problem if you try and unlock something that is not locked. Working with slightly different variable names leads to ...
LockedFilenameCellArray = inmem;
for iLockedFilename = 1:length(LockedFilenameCellArray)
LockFilenameString = LockedFilenameCellArray{iLockedFilename};
if mislocked(LockFilenameString)
munlock(LockFilenameString);
else
LockFilenameString = ...
LockFilenameString(1:(strfind(LockFilenameString, '.')-1));
if mislocked(LockFilenameString)
munlock(LockFilenameString);
end
end
end
I do not run into the same problem with the dbquit('all') command.
My usage is mainly based on a shortcut (in fact it is one of my only shortcuts) when I am debugging things. I am often deep into the debug environements/nested keyboards so the dbquit is important to me.
We are definitely not finding all the persistent data. I know analoginput creates persistent data like the timer, but these are easy to add.
Do you have an example of a locked mex file?
@Daniel: My FEX:Shuffle is locked, because some users urgently needed the RNG to be unaffected by "clear all". And graph2d\private\lineseriesmex.
Please try this: Create the script "disp('DBQUIT'); dbquit('all'); disp('READY')". Then set a breakpoint in any function, run until the breakpoint and call the script => "DBQUIT", but the 2nd DISP is not reached.
The timer is cleared already and I'll insert the safe unlocking of objects. MUNLOCK works on not locked files, but they must exist: "munlock plot" works, "munlock qqqqqq" fails.
Potential locked mex file solution:
[LoadedM, LoadedMex, LoadedJava] = inmem;
LoadedM = [LoadedM; LoadedMex];
It also finds the java items in memory which cannot be easily cleared.
@Daniel: You cannot unload a Mex-file with MUNLOCK. You need a method inside the Mex, which call mexUnLock().
I would have never found the following in the documentation, but it's very useful so thanks Jan:
set(0, propname{iprop}, 'remove');
The tic timer is not cleared yet. This does not show an error:
tic; TotalReset; toc
I don't think your script deletes objects of handle classes with circular references that slipped into a paralllel universe by deleting all handles to them.
@Nikolaus Koopmann: You are right. My weak script does not clear temporary and synchronized files on cloud services. It would be safer to disable the network connection also and to format the disk of the OS. The latter is not easy to implement for the different OS. Copying the kill code of the Nuke-Stick in the boot sector of the disk would be sufficient, but expensive.
lol.. i was being serious. We're honestly considering moving to another programming language after 4 years of trying with Matlab, mainly because Matlab's garbage collection of object handles is so ineffective and opaque that the software we've built gets bogged down the longer we use it. We have implemented delete() methods for all our classes that break up any references to other objects, but somehow Matlab's performance gets worse and worse the more we use our program.. We always have to kill the Matlab process at some point and load everything anew. The plan is to run our code on a production server eventually, where we won't be able to just restart Matlab via the frontend. Matlab was the choice initally for legacy reasons, but I am 100% sure that this client will not start another project with Matlab again. I would certainly not recommend doing anything OOP with ML after this.
I've misinterpreted the term "parallel universe" :-)
I made some OOP tests with tiny projects and decided to stay at functions and C-Mex. I maintain a program with > 300'000 lines of code for clinical decision making, which runs during the examination. The runtime is limited to 5 seconds to avoid stressing the patients and the staff. This was fine in Matlab 6.5 and R2009a, but opening new figures in HG2 since R2014b slows this down by seconds even on computers, which are 15 years younger. A lot of tricks support the speed limits again, e.g. creating the figures outside the visible area of the screen in advance and filling the individual curves only.
OOP would kick us. But of course OOP techniques are used like encapsulation. Instead of using the nice mechanisms provided by Matlab we use self written tools to control, which functions have read and write acccess to certain fields of structs. Meta-programming - brrr, but it works reliably and fast.
I agree that Matlab's OOP is too slow for some applications. The same argument was used against loops in Matlab 20 years ago. Currently I'm rewriting some simple core functions from vectorized code to loops to save time.

Sign in to comment.

Please see if MATLABRC is what you need MATLABRC doc
If it is not completely would you need, you can create a startup.m file and add commands that you need. MATLABRC calls STARTUP.

1 Comment

Yes, using matlabrc is a good way of restoring default things that have been cleared. It does not provide a clearing mechanism and is therefore not a full reset. Jan's answer attempts to clear everything and then use matlabrc to restore. Seems like a reasonable way to go.

Sign in to comment.

Categories

Products

Asked:

on 9 Feb 2011

Commented:

DGM
on 15 Jun 2024

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!