WSL 2 changes the output of `uname -r`. For instance,
WSL 1: 4.4.0-18980-Microsoft
WSL 2: 4.19.67-microsoft-standard
Since WSL 2 lowercases the M, we can match for the rest of the string
which remains lowercase throughout both versions. Another option would
be to match for both upper- and lower-case Ms, like that:
$(uname -r) = *[Mm]icrosoft*
Fixed use of nohup in open_command where it was only necessary for
xdg-open (and actually harmful for cmd.exe in WSL 2). The current logic
is simpler and more future-proof.
- Add double quotes to command so that the next argument isn't
interpreted as the title for the start command.
- If the first argument is a valid path, convert it to Windows path
notation. If `wslpath` fails—because it's a path from inside WSL,
which cannot be converted to Windows path notation— fail with an
error code.
This last circumstance will show an error like so:
wslpath: path: Result not representable
This will work only on files and directories in a DrvFs mount, i.e.
that can be translated to a Windows drive path.
For example: /mnt/c/Users/user.
Files and folders inside the LXSS directory can't be handled in
Windows, they must be ONLY used by the WSL subsystem. That's why
you won't be able to open your $HOME directory, for instance.
See https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/
Otherwise `start` will confuse the first parameter as the title of
a new command prompt if the parameter contains whitespace. That is
because the command to be run will be:
start "abc def"
which opens a new command prompt window with the title "abc def".
With the added empty string we force the start command to interpret
the passed parameter as the file / command:
start "" "abc def"
which will be interpreted like `""` is the title and the rest is
the file or command to start.
-------
**NOTE:** this wouldn't be necessary if the start script in msys
was defined differently; that is, if it had the empty string
already incorporated in the script (/usr/bin/start), like so:
```diff
-cmd //c start "${@//&/^&}"
+cmd //c start "" "${@//&/^&}"
```
Notice however that this would make it impossible to use start
setting a different title, so it's probably best to leave it as is.
More info: http://sourceforge.net/p/msys2/tickets/14/
-------
The change `${(z)open_cmd}` is necessary to force zsh to split the
variable by the spaces and interpret it as separate words.
More info: http://zsh.sourceforge.net/FAQ/zshfaq03.html#l17
Apparently `nohup` is not needed in OSX, and using it has the side
that it may break under tmux with the error
nohup: can't detach from console: No such file or directory
For now, this commit only drops the use of `nohup` in OSX. But it
*may* not be necessary under other similar platforms.
Term window title and tab title are now skinable
Tab title can be different from window title (when supported by term)
Default theme is optimized of usuability (no %u@%m: $~ in a 10 char tab)
Cleanup code duplication and add comment for supported terms
On osX it works great on iterm, and is decent once you tweak Terminal pref
Tested under GNU screen, iTerm and Apple Terminal, need to be tested on linux
TODO implement Konsole support (via dbus)
On my linux virtual terminals, where TERM="linux", I was getting
annoying output that was messing up my prompt.
It turns out the title function was always matching on the elif
statement for xterm/rxvt no matter what and the linux vt doesn't know
what to do with the title special control sequence and thus was printing
out garbage.
Through experimentation I figured out that the || inside of the [[ ]]
did not work:
export TERM=linux
$ if [[ $TERM =~ "^xterm" || $TERM == "rxvt" ]]; then echo $TERM; fi
linux
$ if [[ $TERM =~ "^xterm" ]] || [[ $TERM == "rxvt" ]]; then echo $TERM; fi
Signed-off-by: Brandon Philips <brandon@ifup.org>
openSUSE running zsh 4.3.10
