| IDL 5.3 serious problem: save files sneakily restored [message #21391] |
Thu, 24 August 2000 00:00  |
kashyap
Messages: 26
Registered: April 1993
|
Junior Member |
|
|
IDL 5.3 appears to have a major hull breach.
If there is an idl save file named "<whatever>.sav" in the current
directory,
the contents of that file get restored whenever <whatever> is referenced as
a function within IDL.
<whatever> does not have to be a string.
It must have the ".sav" extension, and must be a valid IDL save file.
This is very dangerous, because there is no telling when local variables
will suddenly get overwritten.
I checked the online help documentation and didn't see anything about
this immediately. Even if it is a documented feature, it's a mistake.
This was discovered because we have a function called fitlines.pro
which wasn't being run because there was a goddammed savefile called
fitlines.sav in the current directory.
The log of a demonstration is appended below.
Comments?
Vinay
____________________________________________________________ __________
suppose, in the current directory, there are some IDL savefiles:
(which were made say, as follows:
idl
IDL> x=findgen(100)
IDL> save,file='whatever.sav'
IDL> y=x^2
IDL> save,file='kursk.sav'
IDL> exit
)
Then, when you start IDL and say
idl
IDL> print,!version
{ sparc sunos unix 5.3 Nov 11 1999}
IDL> help
% At $MAIN$
Compiled Procedures:
$MAIN$
Compiled Functions:
IDL> help,whatever()
% Restored file: WHATEVER.
% Attempt to call undefined procedure/function: 'WHATEVER'.
% Execution halted at: $MAIN$
IDL> help
% At $MAIN$
X FLOAT = Array[100]
Compiled Procedures:
$MAIN$
Compiled Functions:
IDL> tmp=kursk()
% Restored file: KURSK.
% Attempt to call undefined procedure/function: 'KURSK'.
% Execution halted at: $MAIN$
IDL> help
% At $MAIN$
TMP UNDEFINED = <Undefined>
X FLOAT = Array[100]
Y FLOAT = Array[100]
Compiled Procedures:
$MAIN$
Compiled Functions:
IDL>
--
____________________________________________________________ __________________
kashyap@head-cfa.harvard.edu 617 495 7173 [CfA/P-146] 617 496 7173 [F]
|
|
|
|
|
|
|
|
| Re: IDL 5.3 serious problem: save files sneakily restored [message #21452 is a reply to message #21391] |
Fri, 25 August 2000 18:36  |
Mark Hadfield
Messages: 783
Registered: May 1995
|
Senior Member |
|
|
"Martin Schultz" <martin.schultz@dkrz.de> wrote in message
news:39A639C7.3D01A75C@dkrz.de...
> When a file is specified by typing only the filename at the IDL
> prompt, IDL searches the current directory for filename.pro
> (where filename is the file specified) and then for filename.sav.
> If no file is found in the current directory, IDL searches in the
> same way in each directory specified by !PATH. If a file is
> found, IDL automatically compiles the contents and executes any
> functions or procedures that have the same name as the file
> specified (excluding the suffix).
>
> So, at least theoretically, pro should get executed before sav.
> And this makes all the sense in the world, because otherwise it
> would be hard for authors of compiled files to develop them -
> they would have to delete the sav file each time they modify the
> pro file and want to test changes.
In Python (which is many ways similar to IDL) the corresponding extensions
are .py (source code) and .pyc (compiled). When a .py file is compiled, a
.pyc file is created in the same directory. Thereafter Python loads the .pyc
unless the .py has a more recent modification date. This is one of those
ideas that is so clever it seems obvious once someone else has thought of
it. Why can't IDL do that?
---
Mark Hadfield
m.hadfield@niwa.cri.nz http://katipo.niwa.cri.nz/~hadfield/
National Institute for Water and Atmospheric Research
PO Box 14-901, Wellington, New Zealand
|
|
|
|
|
|
|
|
| Re: IDL 5.3 serious problem: save files sneakily restored [message #21798 is a reply to message #21452] |
Thu, 21 September 2000 00:00 |
Theo Brauers
Messages: 58
Registered: November 1997
|
Member |
|
|
Mark Hadfield wrote:
>
> In Python (which is many ways similar to IDL) the corresponding extensions
> are .py (source code) and .pyc (compiled). When a .py file is compiled, a
> .pyc file is created in the same directory. Thereafter Python loads the .pyc
> unless the .py has a more recent modification date. This is one of those
> ideas that is so clever it seems obvious once someone else has thought of
> it. Why can't IDL do that?
>
Because RSI wants you to write more IDL code :-) ! We had a similar problem with
reading large ASCII data files: you read the once ( file1.dat ) and save the data
using SAVE ( file1.dat.sav ). When we re-read the file we check the modification
date of both files and read the newer one. It works fine now but it was written
partly in C to get the modification date of each file also in windows. Anyway,
I read that IDL5.4 will have a full function FSTAT with it.
Theo
--
----------------------------------------------
Dr. Theo Brauers
Institut fuer Atmosphaerische Chemie (ICG-3)
Forschungszentrum Juelich
52425 JUELICH, Germany
Tel. +49-2461-61-6646 Fax. +49-2461-61-5346
http://www.kfa-juelich.de/icg/icg3/MITARBEITER/th.brauers.ht ml
|
|
|
|
comp.lang.idl-pvwave archive
Members
Search
Help
Login
Home
