Restore original path when DO of a script fails

[Siskin-Bot]

Submitted by: Lkppo

DO doesn't restore the original path if code being executed in a subfolder fails. This seems inconsistent.

It can be improved by trapping the error, restore the path and propagate the error to the caller.

This bug can be reproduced by creating a buggy script in a subfolder and launching it from a rebol interpreter where the current path is not the subfolder of the buggy script.

1. Create a folder "subfolder" and put a buggy script myscript.r in that folder with a code that make an error of execution
2. Launch an interpreter
3. Let's say if you >> pwd you will get something like == %mytopfolder/
4. If you >> do %subfolder/myscript.r the buggy script will raise an error
5. Running >> pwd gives == %mytopfolder/subfolder/

Now the current directory is the subfolder because the script crashed. The context of execution is not restored.

Maybe other things need also to be restored on recovery.

---

^{Imported from: metaeducation#2374}

Comments:

---

Hostilefork added the Type.wish on Apr 27, 2019

---

Gchiu commented on Apr 27, 2019:

this is an annoying issue so if we decide to fix it, then great.

---

Mark-hi commented on Apr 27, 2019:

NOTE: this comment applies to changes to the current directory that take place from inside the running script. Please see my further comment below for the real story of this issue!

The current directory is part of the process environment, like env-vars, open files, ports, etc.
You might as well ask for files that the script opened (before the error) to be closed, ports closed by the script to be (re-)opened, and environment variables changed by the script to be reset to their original values. Can't be done, and don't think about doing it, because it's wrong.
If you want to do what this issue says, use CALL to spawn another <redbol> process. It will inherit the current directory (among other things), but CDs inside it will not affect the calling environment.

---

Rgchris commented on Apr 27, 2019:

@Mark-hi makes a good point—though I'd say as a temporary change of directory is a feature of DO FILE, perhaps—if a failed script can be detected—it should revert unless the current path has been explicitly changed by that script.

---

Mark-hi commented on Apr 28, 2019:

Thank you for mentioning this @rgchris! My apologies to you and @lkppo, I misunderstood this issue report completely.
I thought it was the script itself that changed its current directory.
If DO changes the current directory before calling the script, that's a different story, and I totally agree that that is super not good.
Ever since Rebol 2 at least, scripts are supposed to have access to the directory they reside in (via system/script/path). If DO changes to that directory before running the script, that means that that would never be necessary, as it would always be the same as what WHAT-DIR returns at script startup.
I just tried it out and you are right, in both Rebol 2 and Rebol 3 Alpha, no matter how you call a script, system/script/path and what-dir are equal when it starts.
Clearly a big bad bug!

---

Lkppo commented on Apr 28, 2019:

No problem. I too have fallen a thousand times in this way. :-))

I was surprised that this bug is also in Rebol 2 (I'm learning the language and Ren-c). Not knowing the whole story I was wondering if the path is the only contextual data affected.

---

Hostilefork commented on Apr 28, 2019:

Technical point to bring into the discussion: the notion of "current directory" bears some scrutiny.

For instance: if you do http://example.com/some-script.reb, the desire has been to think of the execution "directory" as being http://example.com/ so that other scripts are fetched relative to that URL.

But the filesystem runtime (e.g. Windows SetCurrentDirectory() or POSIX chdir()) can't hold a state that's a URL path.

Ren-C was changed so that the "current directory" reported by WHAT-DIR is stored in a Rebol system variable. (well, @Mark-hi points out that there was a variable before, but it just was wired in somewhere you won't find in the source to WHAT-DIR in particular). Anyway, it is allowed to be a URL! or a FILE!. However, if you ask WHAT-DIR and it's a file path...it currently re-syncs that independent notion with whatever the filesystem happens to think it is. (If the filesystem "extension" is loaded...which it is not in the web build)

I'm not sure what this implies for the notion of rolling things back. But just mentioning it.

---

Mark-hi commented on Apr 28, 2019:

(The following are the meanderings of a mildly addled mind. None of this is canon, or written down anywhere else, yet.)
I like the way Rebol 2 separated two location notions, that of "current directory" and of "script source".
Current directory is a process concept, namely, "where I am executing", for locating (usually data) local files the script or module might read or write, and is exposed through what-dir.
Script source is a language concept, namely, "where I am stored", and is for locating related (usually code) local scripts or modules that might be run or imported, and is exposed through system/script/path.
The code/data distinction is actually unimportant; the important thing to note here is the access requirement, to wit, one may require write access while the other is explicitly limited to the read-only operations of "running" and "importing".
Slightly coincidentally, URLs are read-only.
Lastly, it is difficult for me to imagine a scenario requiring a script or module to be "executing in" a URL directory -- and that's not just considering that it must be read-only, or how easily such a location could be passed in as an argument. Barring a convincing example of such, it is certainly feasible that there be a current directory that is different (and is blank in network-only environments) and that any "related" read-only stuff be run or imported via the script source location.
With all this in mind, I respectfully suggest that system/script/path is the one that needs to be able to be URL! or FILE!, but that what-dir must always be a FILE! (or blank).

---

Oldes added a commit to Oldes/Rebol3 that referenced this issue on Apr 29, 2019:
FIX: Restore original path when DO of a script fails

---

Oldes commented on Apr 29, 2019:

In above commit the system/script and directory location is restored in all cases, including an error state.

---

Oldes added a commit to Oldes/Rebol3 that referenced this issue on Apr 29, 2019:
FIX: correctly handling case where result from script evaluation is u…

---