Pantxo, your patch looks compact. However, the rehash may be quite slow, and it quite likely that user code would call "exist" often to see if a variable exists (without specifying that), which doesn't need the rehash.

A more invasive patch would be to store a flag recording whether any file has been created or destroyed since the last command prompt, and only rehash if that is the case.

That would require checking for all Octave functions that create or delete files, and possibly also setting the flag if an OCT/MEX file has been run, since they may create files directly.

I'm not sure if the increased complexity is worth it for the increase in speed.

I ran the attached testdelete2.m (besides base.m) in Matlab in order to see how Matlab handles the case of file deletion/modification.

Basically there are too functions "foo.m" and "foo/foo.m" in the loadpath (they print their mfilename). The first in the path ("foo.m") is deleted or modified:

It shows that:

matlab rehashes prior to search in "run", "which" or "exist". * if a file "foo.m" has been deleted since the last rehash, trying to run it using bare "foo" leads to an error (as in octave) even if another "foo.m" exits in the path.

I was wrong in comment #7 about octave behavior in case of file modification: the modified file is parsed in octave as in matlab

The attached simple patch brings octave in line with matlab except that the latters's message (in case of bare call "foo") is more explicit about the origin of the error.

Sorry for the late reply. I agree with you that there are many ways to make a function file disappear and we should not try to manage all of them individually.

The reason why the example works in the terminal and not in a script, is that the path is updated before parsing each input from the prompt (in octave_base_reader::octave_gets from input.cc).

For exist and which functions it seems reasonable to update the path before anything is done.

As it is not reasonable to update the path after each line of a script/function, a test is run (out_of_date_check) from various symbol_table::fcn_info::fcn_info_rep::find_xx functions.

Unfortunatly, the test only checks that the last time the function file was checked is ulterior to last prompt and last dir change.

As a consequence, not only deleted files, but also modified are affected : let's say I have a script toto.m that modifies a second script toto2.m and then runs it. The old version of toto2.m will be run because according to the criteria in out_of_date_check, it is up to date and doesn't even have to be parsed again.

The test should also check that the last time the file was modified is anterior to both last prompt and last dir change. Not sure this may be done fast enough (with stat?).

Because delete may not always be used to delete script files? It seems a little hackish to me to reload the path in a function that may or may not add or remove a function that's in the symbol table. What about unlink("script.m")? What about system("rm -f script.m")? Or what if script is never called again after the delete, why bother reloading the path?

It seems better to try to reload the path and look up again on demand when a symbol is actually used and can't be found.

The exist function ends up calling the static symbol_table::find function. Further down in the symbol_table class are a couple of calls to load_path::update(), which is what rehash does. It looks like there is some logic in place to attempt to reload the path if a find fails, but I haven't traced the symbol_table class enough yet to know under what conditions it's done.