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.


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

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

:~/demo$ which 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.


1 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


#!/usr/bin/env notepad.exe

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).

  • $\begingroup$ Thank you for the helpful comments. As stated earlier, using a symbolic link does not misbehave in Windows/Cygwin or Linux. I suppose that's because in the former(latter) case the 'symbolic link', the 'bash script', and the executable file 'wolframscript.exe'('wolframscript') are all really Windows(Linux) code under the hood. By contrast, in the WSL2/Ubuntu case, some components are Windows (wolframscript.exe) and others are Linux. It seems that WSL2 is not properly handling the hand offs between the two under the circumstances I have described. $\endgroup$
    – jjoIV
    Commented Mar 8, 2023 at 18:30
  • $\begingroup$ However it's close to working. For example, this modified test script #!/usr/bin/bash wolframscript -code '\ Print["2+2 = ", 2+2] ' actually works correctly under WSL2 whether called by name or via symbolic link. However, its also a bit uglier and probably less portable than the original test script. $\endgroup$
    – jjoIV
    Commented Mar 8, 2023 at 18:31
  • $\begingroup$ Installing the Linux version of Mathematica to run under WSL/Ubuntu is a interesting idea I hadn't thought of. It might work. If I had some other reason to install Mathematica for Linux on my local machine I would try it. Otherwise, it's not worth the cost in time and disk space just to get another cost-saving measure to work. $\endgroup$
    – jjoIV
    Commented Mar 8, 2023 at 18:31
  • $\begingroup$ @jjoIV Yes, if you are able to access the Windows version as wolframscript from WSL, it's probably calling a shell script anyway, since normally Windows applications need to be called with the .exe extension. Can you less "$(which wolframscript)"? If so, that might give some hints as to how it's calling the actual executable. That definitely is interesting that it is working when called through bash like that. If I get a chance, I'll try to install the Windows version and see if I can spot anything as well. $\endgroup$ Commented Mar 8, 2023 at 20:30
  • $\begingroup$ To your point, in order to make either of my test scripts work I had to create a symbolic link from wolframscript to wolframscript.exe. Here it is: ~/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' Note that /usr/bin shows up near the beginning of $PATH. ~/demo$ which wolframscript /usr/bin/wolframscript ~/demo$ which wolframscript.exe /mnt/c/Program Files/Wolfram Research/WolframScript//wolframscript.exe $\endgroup$
    – jjoIV
    Commented Mar 8, 2023 at 22:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.