I have installed an application called NWChem on Ubuntu on Windows Subsystem for Linux. I can access it directly from the Windows 10 command line using the built in WSL interoperability application wsl.exe by just entering 'wsl nwchem'. However I am trying to install a GUI front end called MoCalc2012 that requires absolute paths for the applications that it uses. If instead of entering an absolute path I put the command 'wsl nwchem' it produces the unhandled exception warning that: 'Path cannot be the empty string or white space'.
Instead of using 'wsl nwchem' is there a method within WSL interoperability to define a absolute path that will stop MoCalc2012 trying to close down because of an unhandled exception?
The path in Ubuntu is '/usr/bin/nwchem'.
I tried to solve this by making a symbolic link as follows:
mklink C:\Program Files\NWChem\nwchem.exe 'wsl nwchem'
but this gave a syntax error, as did putting /J in the command.
I'm the author of MoCalc2012. This does not work because it was never meant to work with WSL. You need to install NWChem to the Windows side of your system.
Related
I want to open a WSL directory in VS Code. What's the difference between the following two methods and which should I use?
First method, open WSL window. It's common.
Second method, directly open directory and select the directory in wsl$ path.
Visual Studio Code recognize better the Connection than opening it directly
In most cases, you'll want to use the "New WSL Window" (or its equivalent). This utilizes the "Remote - WSL" extension to connect to your WSL instance through a small server that it installs in your WSL user's home directory. You'll probably find it already installed in your case in ~/.vscode-server.
This server handles the "translation" between the Windows VSCode and the Linux files, folders, and processes.
An easy way to think about the difference between the two methods of opening a folder:
Using "New WSL Window" puts VSCode in "WSL/Linux" mode
Using "Open Folder" and opening \\wsl$\... directly keeps VSCode in "Windows mode".
Comparing the two techniques with a real file. I have a simple Python file in my WSL home directory that I wrote up for another answer a few days ago. If I:
Open my home directory through \\wsl$\ in VSCode, then the VSCode Python extension complains:
Python is not installed. Please download and install Python before using the extension.
Since I don't have the Windows version of Python installed, and VSCode is operating in "Windows mode", it can't find the Linux/WSL Python interpreter.
However, if I:
Open my home directory through "Remote-WSL: New WSL Window", then open my Python file, then VSCode finds my Python interpreter, and I can run and debug the file in WSL through VSCode.
Side note #1: There is another method that has the same effect as using the command palette's "New WSL Window" -- From inside a WSL directory, run code .
Side note #2: There may be times when you want to open a file that lives inside WSL in "Windows mode". You may want to run it in a Windows version of a tool (Python, Java, whatever) to check compatibility.
As a general rule of thumb, however, you should probably do your Linux development with files inside WSL using VSCode's "WSL Mode" and Windows development with files that live on a Windows drive using "Windows (a.k.a. normal) mode".
I followed llvm-clang install instructions but having issues with configure command line. I tried both MSYS2 64 bit and Windows mingw for the purpose but similar issues appear: cmake seems confusing between windows and unix paths.
Thus, when I try MSYS2 the following error message is thrown:
File /d/mylib/llvm/D:/mylib/llvm/utils/llvm-build/llvmbuild/main.py does not exist.
It seems that prefix /d/mylib/llvm/ is wrongly added to the path. Note that in this case am using cmake installed with pacman -S cmake
On the other hand, when using windows mingw64 (that comes with git windows), am getting this error
CMake Error: File /d/mylib/llvm/utils/TableGen/LLVMBuild.txt does not exist
though the path is correct... Note that I in this case am using cmake installed directly on windows (using windows gui).
Any ideas please?
I am trying to install the google protocol buffer in windows, the instructions first as me this:
cd' to the directory containing the package's source code and type
'./configure' to configure the package for your system. If you're
using 'csh' on an old version of System V, you might need to type
'sh ./configure' instead to prevent 'csh' from trying to execute
`configure' itself.
Running `configure' takes awhile. While running, it prints some
messages telling which features it is checking for.
When I do the './configure' command it tries to open the file label configure in the directory and if I use 'sh ./configure' it doesn't recognise sh as a term. Any ideas?
The instructions you're looking at are for Unix. On Windows, usually you'll want to follow the Windows installation instructions:
https://github.com/google/protobuf#c-installation---windows
As an exception, you'll want to follow the Unix instructions if you plan to use MinGW or Cygwin as your compiler (rather than Visual Studio). In these cases, you'll want to use the MSYS shell (for MinGW) or the Cygwin shell to run the commands in the instructions, not the regular Windows command prompt.
I went to the Chocolatey website and copied the text for installing it and pasted into the administrator cmd.exe (using Windows 7). When I run the command I get:
'powershell' is not recognized as an internal or external command, operable program or batch file.
This GitHub article with Chocolatey installation instructions says:
This really is the easiest method because it requires no configuration of PowerShell prior to executing it.
It turns out that #balint was right about the path being incorrect. The path variable at some point had gotten replaced instead of appended to. I was able to install Chocolatey successfully after appending all the paths that had been erased previously!
you have some faulty PowerShell installation, or it is missing from the Windows PATH variable. Run in an administrator cmd:
cmd> set PATH=%PATH%;%SYSTEMROOT%\System32\WindowsPowerShell\v1.0\
I've been trying to run a GAE Go project I developed on my Mac on my Windows machine with GoClipse after installing and configuring the appropriate SDKs and so forth. When attempting to run the project, I get this error:
Exception occurred executing command line. Cannot run program
"C:\GoogleAppEngine\dev_appserver.py" (in directory
"D:\Golang\workspace\Project\src\pkg"): CreateProcess
error=193, %1 is not a valid Win32 application
How can I fix that error in order to run my project?
While the below configuration works on the Mac as it has Python installed by default, Windows requires a different configuration.
On Mac the GoClipse External Tools Configuration would be:
Location: /GoogleAppEngine/dev_appserver.py
Working Directory: ${workspace_loc:/Project/src/pkg}
Arguments: .
The Windows configuration should look like:
Location: C:\Python27\Python.exe
Working Directory:
Arguments: C:\GoogleAppEngine\dev_appserver.py "${workspace_loc:/Project/src/pkg}"
Trying to run .py (Which IMO is a Python file?) wont work directly on windows. You will need to install Python and then pass the above filename to Python something like (I don't know Python so don't go by exact syntax, you might need to look around)
python "C:\GoogleAppEngine\dev_appserver.py
The reason it's working on Mac is because Python comes pre-installed on mac as cited here But on windows it doesn't. So you can install Python and add the Python's bin folder to path, and then run above script and it should run fine!