Please note that this utility was developed for an early release of Windows 10. I no longer use Windows enough to fix it, if it doesn't work with later releases. So I'm afraid that, as of 2018, it has to be regarded as unmaintained. Sorry.
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:
#!/bin/bash $ 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.
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.
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.