What environment variables are passed to FSI when running a script with Run Script?

[somelinguist]

What environment variables are passed to FSI when running ascript with Run script?

Running the script below has different output via the Run script command vs dotnet fsi script.fsx in the integrated terminal. Testing with dotnet 8.0.100, Ionide 7.20.3, vscode 1.90.2 on macOS 14.5

open System.Collections

System.Environment.GetEnvironmentVariables()
|> Seq.cast<DictionaryEntry>
|> Seq.iter (fun e -> printfn $"{e.Key}: {e.Value}")

It seems like at least some variables exported from my .zshrc are passed when using Run script, but not all of them. Changes to to values in .zshrc that do show up with Run script don't always seem to be picked up on the next run, but some are after restarting vscode.

When running dotnet fsi script.fsx in the integrated terminal, variables exported from .zshrc are printed, and changes in .zshrc show up after starting a new session as expected.

Does the Run script command actually use my .zshrc? Does it filter out certain variables? Is there something I can do to make it consistent with the integrated terminal?

[MangelMaxime]

Hello @somelinguist,

Ionide does nothing special to run the code using Run script, it delegates the work to VSCode to spawn the terminal.

ionide-vscode-fsharp/src/Components/ScriptRunner.fs

Lines 40 to 44 in 37a241b

	let shellArgs = shellArgs |> ResizeArray |> U2.Case1
	let title = node.path.basename scriptFile
	let terminal = window.createTerminal (title, shellCmd, shellArgs)
	terminal.sendText (textToSend)
	terminal.show ()

In general, when updating your .zshrc you need to reload it. Either by running source .zshrc or re-starting / spawning a new terminal from your software.

With VSCode, it is a little tricky to have the terminal session refreshed because the parent process which handles VSCode keep running from the same state it was when spawned. From my experience, this is why you need to reload VSCode for it to pick up the changes. However this behaviour is not always consistent, for example if I create a new terminal instance from inside VSCode sometimes it has been refreshed sometimes not.

I can't give specific examples of this problem with VSCode because it didn't happen to me since sometime now as I moved to some other project which don't have this limitations.

[somelinguist]

@MangelMaxime Thanks for the info. Previously looking through the list it seemed like several were not being passed. However, I did some more thorough checking with my script and figured out that actually only one variable looks like it is being stripped, the one I need, of course!

The specific one I need is DYLD_FALLBACK_LIBRARY_PATH. Looking through vccode issues, it looks like they specifically don't pass DYLD_LIBRARY_PATH to plugins, but as far as I can tell, DYLD_FALLBACK_LIBRARY_PATH should be allowed.

What's really strange however, I fee like this might have actually been working last week, because I hadn't noticed it before yesterday.

[baronfel]

If it did work it had nothing to do with Ionide - we haven't changed the FSI invocation logic's process spawning (aside from direct CLI arguments) in forever.

[somelinguist]

@baronfel Thanks for the info. I tried downgrading both Ionide and vscode to a versions from a week or two ago, and still no go.

I can't find anywhere vscode or relevant extensions would remove it.

It looks like there had been an issue with entitlements for DYLD variables on Mac a few years ago microsoft/vscode#90479, but I just checked, and the entitlement is still there.

Who knows. Thanks again for the info!

[somelinguist]

They removed the macOS entitlement that allows DYLD variables to be passed to the main app last year.

The integrated terminal is able to get around it, however, and it sounds like extensions can use the same workaround. See microsoft/vscode#219806 (comment) for further details.

I'm not quite sure if I understood correctly, but it sounds like the integrated terminal might read the shell's .rc file directly to pass on the environment variables (see the link above).

Would it be possible to do something like that when using the Run script command or spawning fsi?

My use case is running scripts that rely on some third-party nuget packages that interact with native libraries that aren't always installed in DYLD_LIBRARY_PATH, and their recommended solution is setting DYLD_FALLBACK_LIBRARY_PATH.

[baronfel]

It's certainly possible to do so for us, but it would add quite a lot of complexity - we currently don't really do anything OS or shell specific and I'd be concerned with doing it right. Do you know if there are any VSCode Node libraries that help work around this problem we could use? Would you be willing to contribute any enhancements here?

[somelinguist]

It looks like it might be more complicated than I thought. I thinking using Pseudoterminal wouldn't be too difficult, but it looks like they do a ton of stuff to resolve the system shell:

https://github.com/microsoft/vscode/blob/e86f5306cc8c64e2eb6a3f1db54f3a2c585f2fad/src/vs/platform/terminal/node/terminalEnvironment.ts#L108

I don't think I'd be able to pull off that.

I did think of trying one other things, however, I'm running into the error below when trying build Ionide locally following the instructions at https://github.com/ionide/ionide-vscode-fsharp/blob/main/CONTRIBUTING.md#first-time-build

Tool 'paket' (version '8.0.3') was restored. Available commands: paket
Tool 'fantomas' (version '6.2.1') was restored. Available commands: fantomas
Tool 'fable' (version '4.2.2') was restored. Available commands: fable

Restore was successful.
../.paket/Paket.Restore.targets(171,3): error MSB3073: The command "dotnet paket restore" exited with code 137. 

The build failed. Fix the build errors and run again.

I've tried running it a few times, but still the same.

If I run dotnet paket restore manuually, I get Failed to initialize CoreCLR, HRESULT: 0x80004005.

It's been a while since I've used paket, but searching for that error makes it looks like it might have been because I had old versions of the dotnet sdk installed in addition to the current.

However, I've since removed everything but 8.0.100 and restarted my system, but I still get the same errors.

Any ideas?

[somelinguist]

Ok, I'm still not able to build Ionide locally, but I tried my idea by editing the javascript of the installed extension, and it worked.

It turns out that DYLD_FALLBACK_LIBRARY_PATH is just not getting passed with Run script because it's hard-coded to run sh in the terminal created in non-Windows environments:

ionide-vscode-fsharp/src/Components/ScriptRunner.fs

Lines 30 to 38 in 37a241b

	| _ ->
	("sh",
	[||],
	sprintf
	"cd \"%s\" && clear && \"%s\" %s \"%s\" && echo \"Press enter to close script...\" && read && exit"
	scriptDir
	fsiBinary
	flatArgs
	scriptFile)

I changed it to run zsh instead, and DYLD_FALLBACK_LIBRARY_PATH was passed through just fine.

So I my new thought is: Would it be reasonable to just add a new setting to manually configure which shell to run? The defaults could still be the same.

[somelinguist]

Also, is something similar going on with sending code to FSI? The output from my test script makes it look like it might be running under sh as well? But as best as I can follow the code in https://github.com/ionide/ionide-vscode-fsharp/blob/main/src/Components/Fsi.fs, it's creating a terminal directly with dotnet fsi and parameters. Is that correct?

[baronfel]

Ah, the discrepancy you noted is because we have two ways of running scripts (which we should probably remove):

• ScriptRunner, which is used when a user triggers the 'F#: Run script' command
• The fsi.* commands in Fsi.fs, which trigger when a user uses the FSI: XXXX commands

The FSI: XXXX commands are the correct way forward IMO.

[baronfel]

The Paket thing I think is a problem with Paket on recent SDKs that I haven't gotten to the bottom of. Paket isn't necessary in this repo and I need to get around to removing it :(

[somelinguist]

The FSI: XXXX commands are the correct way forward IMO

I do end up using Run script quite a bit myself, probably more than the FSI commands. Part of the reason is that I end up running a lot of scripts that are meant to perform specific tasks. So I hope it doesn't get removed. ;)

[somelinguist]

The Paket thing I think is a problem with Paket on recent SDKs that I haven't gotten to the bottom of. Paket isn't necessary in this repo and I need to get around to removing it :(

Thanks for the info. Is it possible currently for me to build locally without using paket?