include(), read(), etc within a file use a different base directory when called from cmdline/MC VS interpreter

[Pieter12345]

This topic was discussed on Discord, this issue serves the purpose of not losing the results.

Desired behavior

• MC: Relative to script directory (no change).
• Cmdline: Relative to script directory.
• Interpreter/MC interpreter:
  • Functions entered directly into the interpreter use the directory set using cd() as base directory.
  • Included MS files (including the procedures defined within them) use their parent directory as base directory (same behavior as non-interpreter mode).
  • Procedures defined in the interpreter use the directory set using cd() at definition time for all calls to that procedure.

[PseudoKnight]

Regarding the change to cmdline. While I think relative to script directory is the far more desirable behavior, this is a problem because it will break some cmdline scripts (which is why I haven't moved on this myself). However, it occurred to me that we could add another script execution CommandLineTool or even a command argument that forces it to use the relative path behavior, keeping the current working directory behavior for existing cmdline scripts, since this can still be useful in some contexts.

[LadyCailin]

It would be nice to inventory various other languages. What does bash and powershell do? What about languages like python and node/js, which are often used as scripting languages? Having that inventory would be interesting, it may or may not influence anything, but perhaps that would reveal new options.

For instance, in powershell, if you do "$PSScriptRoot", that's the parent folder of the currently running script. I'm not sure what "." means though, I would assume that's the cwd, which may or may not be the same as the current executing script, but that's for sure ambiguous in a way that $PSScriptRoot isn't. Bash has several options: https://stackoverflow.com/questions/35006457/choosing-between-0-and-bash-source

In general in cmdline, there are 4 interesting defaults I can imagine: current file's directory, cwd, and directory the initial script was called from, directory the script was initially trigger from (i.e. cwd() at program start). It seems like different languages cover some of these options, but not others, and really only shell languages tend to have the concept of cwd anyways.

In any case, I think having a cmdline switch to determine "." behavior is fine, since we have options to disambiguate in all of the mentioned cases:

1. reflect_pull('dir')
2. cwd()
3. $0 + parsing
4. @cwd = cwd(); as the first line of the script

Depending on the needs of the script, any of these options could be used to disambiguate, but need a different default depending on the context can be modified via the cmdline switch.