WSL/Ubuntu breaks evaluation of WolframScript batch file via symbolic link

Question

I have a very useful bash script for pre-processing a Mathematica notebook before committing it to my local git repo. It works fine under Windows/Cygwin and under Linux. I like to keep one master copy of the script in the git directory for my project and create a symbolic link to this one copy in any other directory in which I want to run it.

I'd like to be able to do the same under WSL/Ubuntu but I can't get that to work.

The essence of the problem can be demonstrated from a Windows terminal running WSL/Ubuntu by means of the following highly simplified example:

Create an executable script file named test.sh containing the lines

#!/usr/bin/env wolframscript
Print["2+2 = ",2+2]

in ~/demo/subdir.

Create a symbolic link to it in ~/demo like this

ln -s ~/demo/subdir/test.sh ~/demo/test.sh

When I execute ./test.sh from ~/demo/subdir the resultant output is

2+2 = 4

So far, so good.

However, if I execute ./test.sh from ~/demo, WolframScript pops up in interactive mode instead and I see this

Wolfram Language 13.0.0 Engine for Microsoft Windows (64-bit)
Copyright 1988-2021 Wolfram Research, Inc.

In[1]:=

FWIW, the following results related to the name "wolframscript" obtain:

:~/demo$ alias wolframscript
-bash: alias: wolframscript: not found

:~/demo$ which wolframscript
/usr/bin/wolframscript

:~/demo$ whereis wolframscript
wolframscript: /usr/bin/wolframscript

:~/demo$ ls -l /usr/bin/wolframscript
lrwxrwxrwx 1 root root 69 Mar  1 11:21 /usr/bin/wolframscript -> '/mnt/c/Program Files/Wolfram Research/WolframScript/wolframscript.exe'

As stated previously, the above works fine in both cases when using Windows/Cygwin or Linux.

I'm looking to understand why this happens with WSL/Ubuntu and hoping for a workaround requiring relatively minor changes to my actual, already-working, multi-platform script.

Answer 1

This does appear to me to be due to a WSL issue with symlinks appearing as empty files or directories on the Windows side. This is being tracked as issue #5118.

It's my (untested) assumption that the Windows wolframscript opens in interactive mode based on this "bug" (unexpected behavior). It probably hits an error condition when attempting to open the symlink (e.g. file-not-found) and falls back to interactive mode.

I can reproduce similar, but not the exact behavior, with out-of-the-box PowerShell and Notepad tests.

I created scripts with:

#!/usr/bin/env -S pwsh.exe -ExecutionPolicy Bypass
ls

And:

#!/usr/bin/env notepad.exe
Hello

As with your example, the original files work fine, but the symlinked versions report:

ObjectNotFound: Could not find a part of the path '\\wsl.localhost\Ubuntu-22.04\home\ntd\temp\symlink-test.ps1'.

For PowerShell, and a basic "The system cannot find the file specified" for Notepad.

Since you cross-posted on Super User, where there appears to me to already be a question that covers this general behavior, I did mark that one as a duplicate, with the intention of providing any additional detail (and Wolfram-specific information) here on this one.

I can think of two possible work arounds:

• According to the original Github issue, installing Samba in the WSL distribution and sharing the filesystem that way to Windows works properly.

• Or assuming there is no platform-specific code in your Wolfram script (and I don't know if that's even possible, since I haven't done much with Wolfram, at least recently), you could install the Linux version of WolframScript into the WSL distribution itself. As long as the Linux version is before the Windows version in the WSL path (which it should be, by default) then you should be able to use the same shebang line to execute scripts on Windows/Cygin (using the Windows WolframScript) and on WSL/Ubuntu (using the Linux version).