filesystem: SCRIPTPATH and SCRIPTDIR

[abitrolly]

Interpreters are pure. In their raw form they don't know anything about system calls. Then it comes "standard library" that adds these system call. Now interpreter can "open files" and do some other immediately useful stuff. The interpreter becomes practical, like Python.

The drawback of batteries included and buried under the surface, is that it is not easy to decouple these things to fix them for specific cases. My case are scripts that work from script dir. Like installation, testing, data analysis. Most interpreters have some hacks to get the directory of the script.

import os 
dir_path = os.path.dirname(os.path.realpath(__file__))

https://stackoverflow.com/questions/5137497/find-the-current-directory-and-files-directory?noredirect=1&lq=1

#!/usr/bin/env bash

SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )

https://stackoverflow.com/questions/59895/how-do-i-get-the-directory-where-a-bash-script-is-located-from-within-the-script

This stuff is unreadable. It requires so much system knowledge to understand, that I doubt anybody from new generation will be able to learn it. That's why WASI can decouple and simplify this inheritance of hacks.

interpreter + filesystem = context

When you just add filesystem calls to interpreter, it is not enough. Interpreter can run file from filesystem. Can run string from command line parameter. Can run code piped to it from other process. In each of these three cases, the context for the code will be different. the context should be full path for file, parameter for cmdline, pipe for running from stdin, console for running stuff from interactive prompt. For file, the context should also include full dirname, because it is important.

Maybe call it running context, or maybe there is a better name, but it really helps to have some specification for that. Because it will help so many tool authors to get around this unspecified behavior in interpreters.

[sbc100]

This seems like maybe an issue for the WASI repository?

[abitrolly]

@sbc100 maybe. I don't remember by which link I got here. Can you move it?

[sbc100]

I don't have permission to do that. Perhaps @dschuff can do it?

[dschuff]

Are you suggesting some change to the spec, or some change to a particular interpreter, e.g. the reference interpreter? The core spec itself tries to separate out everything about the "context" by using an abstract embedding interface Interfaces to the filesystem would be on the "outside" of this interface. Practically speaking though, most interpreters (or the JS embedding) may or may not have an internal API that looks exactly like that, though; it's more a way to separate concerns.

[abitrolly]

@dschuff needed for all interpreters that run scripts from filesystem. It probably makes sense to try implement SCRIPTPATH and SCRIPTDIR in reference interpreter to see how to update the spec for all other interpreters to include this feature.

[sbc100]

The core spec doesn't specify anything to do with filesystems. Any discussion of filesystem APIs likely belongs in the WASI repo. I suggest we move this issue there.

[abitrolly]

@sbc100 I don't have privileges to move it. @dschuff can you move it?

[dschuff]

IIUC this isn't about the filesystem API though, it's about how interpreters work (but unrelated to how they actually implement the wasm language). But the spec doesn't actually say anything about how interpreters should work, aside from the language semantics. The reference interpreter has some functionality for convenience (in terms of text format extensions and whatever command line flags it has), but it's not normative, and I don't know if it's actually specified. So if I'm understanding correctly what you're asking for, I don't think there's a place to put it.