0

I have a script that behaves differently when run by name compared to when it is run via a symbolic link. The problem is specific to WSL/Ubuntu. The same script, when used under Linux or Windows/Cygwin, behaves correctly in both cases. I'm trying to make it portable to all three systems.

A simplified demonstration of the problem is described here on Mathematica StackExchange.

Although my encounter with this problem is specific to wolframscript, I suspect it is actually more closely connected to WSL/Ubuntu than to Mathematica, which is why I have cross-posted it here. (That might have been unnecessary had I been able to apply a windows-subsystem-for-linux tag there.)

The use of env in the first line of the batch file,

#!/usr/bin/env wolframscript

is apparently essential for portability but is also hampering my ability to debug what is going wrong.

Is the problem specific to WSL/Ubuntu, my $PATH, my .bashrc file, or something else?

If you can help me understand and fix the problem it would be much appreciated.

jjoIV
  • 1
  • 1
  • 3
    Does this answer your question? [Symlinks made in the linux side of WSL2 do not appear in the windows side under \\wsl$\xxx](https://superuser.com/questions/1695779/symlinks-made-in-the-linux-side-of-wsl2-do-not-appear-in-the-windows-side-under) – NotTheDr01ds Mar 07 '23 at 23:44
  • I don't see how the suggested previous question/answer applies to my question. For one thing, I'm not at all interested in what the symbolic link looks like from the Windows side -- I never use it that way. More importantly, it is apparent that executing the script file via the link does start 'wolframscript', but it does so in interactive mode rather than running the rest of the script as expected. Are WSL symbolic links simply incapable of acting that way? – jjoIV Mar 08 '23 at 01:17
  • 1
    Apologies - I marked this one as a duplicate intending to immediately put more explanation on your Mathematica question, but then got pulled away for a bit. I've now completed that answer, and yes, the "shebang/script" version of the issue that you are seeing is, I believe, a side-effect of the core issue found in the proposed duplicate. And yes, WSL symbolic links are simply incapable of acting that way ;-). But I did propose a few workarounds in the other answer. – NotTheDr01ds Mar 08 '23 at 03:29
  • Just to be sure, are you using WSL1 or WSL2? They're substantially different (WSL2 is real Linux in a lightweight VM, but WSL1 is just NT with a Linux-compatible interface), so it could be that weird behavior in WSL1 is "just the way it works" while the same in WSL2 would need a different explanation. – u1686_grawity Mar 08 '23 at 13:17
  • I'm using WSL2. – jjoIV Mar 08 '23 at 17:25

0 Answers0