0

I'm currently trying to install WolframEngine to Ubuntu 20.04.2 LTS which is Linux Subsystem on my Windows computer. This is a ultimately to be able to use wolframscript from within my WSL command line. I've downloaded the WolframScript from here, and installed it with no problems. However, when I try to test it, (e.g. running wolframscript -code 2+2) I'm prompted with this output:

A WolframKernel location could not be determined.

Use -configure to set WOLFRAMSCRIPT_KERNELPATH.
Alternatively, export WolframKernel=/yourpath/WolframKernel.

If you have no Wolfram product currently installed,
 the free Wolfram Engine for developers can be downloaded
 at https://www.wolfram.com/engine/.

I do in fact have a licensed kernal for Wolfram on my computer but since that runs off of Windows, I thought I would install the WolframEngine to my WSL. So I followed the link in the output prompt and downloaded the shell script titled: WolframEngine_12.3.1_LINUX.sh. I've tried running this script (from multiple locations in my system) but each time I run source WolframEngine_12.3.1_LINUX.sh. I always get the output

bash: source: WolframEngine_12.3.1_LINUX.sh: cannot execute binary file

I'm not sure why my system can't run the shell script. I'm running it using bash, as that is the shell interpreter for my Ubuntu distro. How can I get my system to run this file so I can start using wolframscript from my command line?

0
0

Short answer:

Not really a WSL issue, since the behavior is the same on a pure Linux installation. The installer script is designed to be executed rather than sourced:

chmod +x WolframEngine_12.3.1_LINUX.sh
sudo ./WolframEngine_12.3.1_LINUX.sh

You'll need sudo (per the installer message if you attempt to run it as a normal user).

Explanation:

The script contains two parts:

  • The first part is a script
  • The second part is the tarball including the binaries for the installation

The script at the beginning reads itself, extracts, and then executes the binary installer.

To see why this doesn't work when sourced, you can reproduce this scenario by creating your own script with both text and binary:

Create a file dont_source_me.sh with:

#!/usr/bin/bash
echo Hello
exit

Then:

> bash # start a subshell
> source dont_source_me.sh
Hello
# Note that the subshell has exited since sourcing causes all commands to be executed within the current shell
> cat /usr/bin/ls >> dont_source_me.sh
> source dont_source_me.sh
bash: .: dont_source_me.sh: cannot execute binary file
> chmod +x dont_source_me.sh
> ./dont_source_me.sh
Hello

Note that the shell did not exit when the script was executed this way (as it did when sourced). An executed script starts its own subshell. The exit command in this case simply caused the script to exit before getting to the binary payload.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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