Logo Computer scientist,
engineer, and educator
• Articles • Utility corner

wlsrun — a command-line utility for running Windows applications from the WSL Bash prompt

What is this?

Here is an example of the kind of problem that wslrun is intended to solve. I have the Windows Subsystem for Linux (WSL) installed on Windows 10, and spend a lot of time at the Bash command prompt. I would like to be able to run Windows utilities, as well as Linux utilities, from the command line, but the file pathnames are completely inappropriate. For example, I might like to run SMPlayer on a directory full of music files like this:
$ /mnt/c/Program\ Files/SMPlayer/smplayer media/audio/Bach/*.flac
This won't work, because SMPlayer won't be able to make any sense of the Linux pathnames it is presented with. It won't even know where /mnt is.

However, this will (should) work:

$ wslrun /mnt/c/Program\ Files/SMPlayer/smplayer media/audio/Bach/*.flac
Better still, I can create a script in, say, /usr/bin called smplayer, with the following content:
$ wslrun /mnt/c/Program\ Files/SMPlayer/smplayer "$@" 
Then I can just run SMPlayer like this:
$ smplayer media/audio/Bach/*.flac
This should work whether I specify a directory, a set of files, or a single file. It will also work if I specify an HTTP URI, because wslrun will not attempt to translate a server URI (and, of course, it can't).

wslrun is implemented in C, and has a binary size of only a few kB. The memory size at runtime is unknown, because that depends on technical details of WSL that are not available. It uses exec to replace itself in memory with the program being executed, and Windows seems to respect that. In any event, wslrun's memory overhead is likely to be much smaller than that of a solution using Perl or Python.

How it works

wslrun examines each argument on the command line and, if it can be converted to a well-formed, absolute pathname, it is converted. The converted pathname is then compared with the pattern /mnt/X/ where X is a drive letter, and the /mnt/X/ part converted to X:/. Other directory separators are converted from "/" to "\". Arguments that cannot be converted are passed as-is to the program being launched.

This whole process is pretty crude, but seems to work in a surprising number of cases. Windows applications don't usually take command-line switches but, where they do, there usually isn't a problem even if they start with a "/", as is conventional in Windows. Potentially these arguments could match directory names, but they are unlikely to do so in practice.


To build wlsrun you will need the GCC C compiler (e.g., sudo apt-get-install gcc,) and associated utilities, particularly make.
$ make
$ sudo make install
There are some sample scripts that use wslrun in the examples/ directory. These scripts should not normally be installed without checking their suitability.


wslrun should be invoked using the path to the executable to run, and any command-line arguments, in Unix format. In practice, the command will normally be used in a script, with the pattern "$@" to indicate passing all command-line arguments straight through.

Setting the environment variable WSLRUN_DEBUG (to anything) will cause the program to display the arguments it is processing, and what it makes of them. This can be useful for working out why things don't work as they should.


Fundamentally, wslrun is a kludge. It works on the assumption that anything on the command line which can be interpreted as a valid filename is, in fact, a filename. This is very often the case, but it can't be guaranteed.

wlsrun is designed to be used in an environment where files are shared between Linux and Windows. Where that isn't the case, there is perhaps no need for a utility of this kind. Needful or not, Microsoft has repeatedly warned us that Windows tools should not be used to edit files in the Linux filesystem itself, that this will lead to data corruption. In practice, directories under $HOME should normally be symlinks to directories under /mnt, if these files are to be shared. WSL does not expect these files to contain Linux-specific meta-data, so WSL will not break if Windows utilities damage any such meta-data. On the other hand, files in the Linux filesystem area do have Linux-specific meta-data, which needs to be kept intact.

Consequently, wlsrun will not attempt to re-write file locations whose real pathname — after resolving symlinks — does not refer to a location under /mnt.

Legal, etc

wslrun is copyright (c)2017 Kevin Boone, distributed according to the GNU Public Licence, version 3 The licensing terms mean in essence that you may do whatever you like with the software, at your own risk, provided that the original authorship remains clear. There is no warranty of any kind. I'm publishing this, as ever, in the hope that it will be of some small use to other people; but I make no promises that it won't be useless, or even dangerous.


The most recent source code can always be found in the github repository. I'm assuming that anybody who would be interested in a utility like this will have no problems building it from source.
Copyright © 1994-2015 Kevin Boone. Updated Sep 26 2017