--runx option for MS Windows

[mviereck]

I've added an experimental option --runx in 93c385d

@eine Could you please try this out? My Windows VM currently does not work at all, so I cannot check myself.

Option --runx allows you to run x11docker directely instead of the previous runx -- x11docker.

Especially a check is needed in Cygwin and WSL if the XAUTHORITY cookie works.
In MSYS2 you would run x11docker --runx --no-auth.

You can run x11docker without specifying --runx, x11docker will automatically choose --runx or --xwin.

[eine]

I'll try to test it during the weekend. Meanwhile, I'm not sure I understand the feature. Did you roll-back and runx is not required anymore? Or does x11docker call runx, so the latter needs to be available in the PATH?

[mviereck]

Did you roll-back and runx is not required anymore?

runx is still required. But now, x11docker calls it on itself. Your second assumption is right:

Or does x11docker call runx, so the latter needs to be available in the PATH?

[eine]

I needed a couple of weekends, but I'm ready to test this now. Unfortunately, the "old" syntax fails:

# /t/runx/runx --no-auth -- /t/x11docker/x11docker x11docker/xfce xfce4-terminal
runx note: Using random X display number :2738.
  If this display number is already in use, X server startup  will fail.
  You can specify a display number N with option '--display N'.
runx note: Windows firewall settings can forbid application access
  to the X server. If no application window appears, but no obvious error
  is shown, please check your firewall settings.
  Compare:   https://github.com/mviereck/x11docker/issues/108
runx WARNING: Option --no-auth: Cookie authentication is disabled!
      SECURITY RISC!
  Your X server vcxsrv listens on TCP connections without any protection.
  Others could try to access your system through network connections.
  Please use option --no-auth for debugging only.
DISPLAY=10.0.75.1:2738
x11docker WARNING: Your host X server runs without cookie authentication.
x11docker note: Using X server option --hostdisplay
x11docker note: Option --hostdisplay: You host X server seems to run
  without cookie authentication. Cannot set up a cookie for X access.
  Fallback: Enabling option --no-auth.
x11docker note: check_screensize(): Could not determine your screen size.
  Please improve this by installing one of xrandr, xdpyinfo or xwininfo.
  Or use option --size=XxY.
  You can look for the package name of this command at:
 https://github.com/mviereck/x11docker/wiki/dependencies#table-of-all-packages
x11docker WARNING: Option --no-auth: SECURITY RISK!
  Allowing access to new X server for everyone.
  Your X server is accessable over TCP network without any restriction.
  That can be abused to take control over your system.
x11docker WARNING: --hostdisplay: X server 10.0.75.1:2738 runs without cookie authentication.
x11docker ERROR: Startup of docker failed. Did not receive a container ID.
  Last lines of container log:
esourcein\docker.exe: Error response from daemon: file does not exist.
esourcein\docker.exe run --help'.er
  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be: /home/eine/.cache/x11docker/x11docker.log
  Please report issues at https://github.com/mviereck/x11docker

Is this expected?

Then, I added runx to the PATH, and tried to run runx -h. After the help, an unexpected message is shown:

...
Providing an X server in background all the time:
 - Create an entry in ~/.bashrc: source /usr/local/bin/runx
 - In future terminal session you can directly run GUI commands.
   E.g. just type:  'pcmanfm'  instead of 'runx -- pcmanfm'.

runx version v0.3.0
Please report issues and get help at:   https://github.com/mviereck/runx

runx note: Command not found: xauth

runx ERROR: Missing dependency: xauth
  Cannot create an authorization cookie for X server access.
  MSYS2 does not provide xauth. Rather use Cygwin or WSL instead.
  You can disable cookie authentication with discouraged option --no-auth.

Last, I tried /t/x11docker/x11docker --runx --no-auth x11docker/xfce xfce4-terminal:

x11docker note: Enabled X over TCP instead of sharing unix socket.

x11docker WARNING: Option --no-auth: SECURITY RISK!
  Allowing access to new X server for everyone.
  Your X server is accessable over TCP network without any restriction.
  That can be abused to take control over your system.


x11docker ERROR: Startup of docker failed. Did not receive a container ID.

  Last lines of container log:
esourcein\docker.exe: Error response from daemon: file does not exist.
esourcein\docker.exe run --help'.er

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be: /home/eine/.cache/x11docker/x11docker.log
  Please report issues at https://github.com/mviereck/x11docker

I feel that this might be the same issue as with the "old syntax" above. In case it might be relevant, I updated docker-for-win to 2.2.0.3 (stable). However, I think that the location of binaries didn't change. Anyway, this is the log: x11docker.log

[mviereck]

Thank you for the test!

Last lines of container log:
esourcein\docker.exe: Error response from daemon: file does not exist.
esourcein\docker.exe run --help'.er

The message is messed up with DOS newlines. Not sure why, x11docker removes the in function error(). In the log it is readable, but not really helpful:

C:\Program Files\Docker\Docker\resources\bin\docker.exe: Error response from daemon: file does not exist.
See 'C:\Program Files\Docker\Docker\resources\bin\docker.exe run --help'.

It does not say which file is missing. The Docker command has only one --volume.

  docker.exe run --tty --rm --detach \
  --name x11docker_X3178_x11docker-xfce-xfce4-terminal_11809315510 \
  --user 197609:197121 \
  --env USER=eine \
  --userns host \
  --cap-drop ALL \
  --security-opt no-new-privileges \
  --security-opt label=type:container_runtime_t \
  --init \
  --tmpfs /run --tmpfs /run/lock \
  --volume '/c/msys64//home/eine/.cache/x11docker/x11docker-xfce-xfce4-terminal-11809315510/share':'/x11docker':rw \
  --workdir '/tmp' \
  --entrypoint env \
  --env 'container=docker' \
  --env 'XAUTHORITY=/x11docker/Xauthority.client' \
  --env 'DISPLAY=10.0.75.1:3178' \
  --env 'XDG_RUNTIME_DIR=/tmp/XDG_RUNTIME_DIR' \
  -- x11docker/xfce  /bin/sh - /x11docker/containerrc

The // in the path is not intended, but should not hurt. Otherwise, --volume '/c/msys64//home/eine/.cache/x11docker/x11docker-xfce-xfce4-terminal-11809315510/share':'/x11docker':rw looks ok.

Or maybe the issue is here: --security-opt label=type:container_runtime_t. This enables a SELinux rule. So far the option did not hurt if SELinux is not installed at all. It can only be disabled in the code yet: https://github.com/mviereck/x11docker/blob/master/x11docker#L3944

A bit special I've not seen before:

DEBUGNOTE[01:10:16,860]: dockerrc:  Found docker environment variable: DOCKER_BUILDKIT=1

It might be worth to unset this variable like:

unset DOCKER_BUILDKIT
export DOCKER_BUILDKIT
/t/x11docker/x11docker --runx --no-auth x11docker/xfce xfce4-terminal

Overall, I am not sure what is going wrong.
It seems to be not a runx issue but a Docker issue, likely introduced with your update of Docker.

---

After the help, an unexpected message is shown:

Is fixed now.

[eine]

I tried both removing L3943-L3945 and unsetting DOCKER_BUILDKIT. Unfortunately, I get exactly the same result.

Overall, I am not sure what is going wrong.
It seems to be not a runx issue but a Docker issue, likely introduced with your update of Docker.

I'm not sure. On the one hand, I think there was an earlier update which might have broken it too. The one I mentioned is the latest. On the other hand, it seems that runx is correct but the failure is produced by x11docker, isn't it?

After the help, an unexpected message is shown:

Is fixed now.

I can confirm.

[eine]

Errors seem to have changed now:

# /t/runx/runx --no-auth -- /t/x11docker/x11docker x11docker/xfce xfce4-terminal
runx note: Using random X display number :104.
  If this display number is already in use, X server startup  will fail.
  You can specify a display number N with option '--display N'.

runx note: Windows firewall settings can forbid application access
  to the X server. If no application window appears, but no obvious error
  is shown, please check your firewall settings.
  Compare:   https://github.com/mviereck/x11docker/issues/108

runx WARNING: Option --no-auth: Cookie authentication is disabled!
      SECURITY RISC!
  Your X server vcxsrv listens on TCP connections without any protection.
  Others could try to access your system through network connections.
  Please use option --no-auth for debugging only.

DISPLAY=10.0.75.1:104
realpath: Files/Docker/Docker/resources/bin/docker: No such file or directory
x11docker WARNING: Your host X server runs without cookie authentication.

x11docker note: Using X server option --runx


x11docker ERROR: Command 'xauth' not found.
      SECURITY RISK!
  Your X server would be accessable over network without authentication!
  That could be abused to take control over your system.
  Please install 'xauth' to allow X cookie authentication.
  You can disable cookie authentication with discouraged option --no-auth.

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be: /home/eine/.cache/x11docker/x11docker.log
  Please report issues at https://github.com/mviereck/x11docker

# /t/x11docker/x11docker --runx --no-auth x11docker/xfce xfce4-terminal
realpath: Files/Docker/Docker/resources/bin/docker: No such file or directory
x11docker note: Enabled X over TCP instead of sharing unix socket.

x11docker WARNING: Option --no-auth: SECURITY RISK!
  Allowing access to new X server for everyone.
  Your X server is accessable over TCP network without any restriction.
  That can be abused to take control over your system.

x11docker ERROR: Startup of docker failed. Did not receive a container ID.

  Last lines of container log:
esourcein\docker.exe: Error response from daemon: file does not exist.
esourcein\docker.exe run --help'.er

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be: /home/eine/.cache/x11docker/x11docker.log
  Please report issues at https://github.com/mviereck/x11docker

Note realpath: Files/Docker/Docker/resources/bin/docker: No such file or directory in both cases.

[mviereck]

I tried both removing L3943-L3945 and unsetting DOCKER_BUILDKIT. Unfortunately, I get exactly the same result.

Thank you for the test!
Unfortunately, I have no good idea now.
Two attempts:

• try with --cap-default
• try an older x11docker version without adjustments for WSL2, e.g. release 6.5.0. Though that does not have option --runx but needs the runx -- x11docker syntax.

A test with an older x11docker version that once worked for you could validate that the failure is introduced with the docker update.

/t/runx/runx --no-auth -- /t/x11docker/x11docker x11docker/xfce xfce4-terminal.
x11docker ERROR: Command 'xauth' not found.

You need --no-auth in x11docker, too. Did I change that once? I am not sure yet.

On the other hand, it seems that runx is correct but the failure is produced by x11docker, isn't it?

I agree.

Note realpath: Files/Docker/Docker/resources/bin/docker: No such file or directory in both cases.

Is fixed now. (Introduced in #223). Though, does not affect the Windows setup, does no harm here

[eine]

I updated to master and now the logfiles (/home/eine/.cache/x11docker/x11docker.log) are empty. They are updated, but empty. I can see a folder being created for the container, and then removed. I get the same result with or without --cap-default.

With v6.5.0 and v6.4.0 the error is different and the logfile is not empty: x11docker.log x11docker.log

v6.3.0 and v6.2.0 start the X server but then seem to hang waiting for something. None of them writes any content to the log.

No container is created with any of them.

Anyway, I tried /mnt/t/runx/runx --no-auth -- /mnt/t/x11docker/x11docker --no-auth x11docker/xfce xfce4-terminal and /mnt/t/x11docker/x11docker --runx --no-auth x11docker/xfce xfce4-terminal with runx master and x11docker master on WSL, and it works. Hence, I believe this is not an issue with Docker, but with path mangling in MSYS2.

 /mnt/t/x11docker/x11docker --runx --no-auth x11docker/xfce xfce4-terminal
realpath: '': No such file or directory
'\\wsl$\Debian\home\eine'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
Failed to connect to bus: No such file or directory
x11docker note: Enabled X over TCP instead of sharing unix socket.

x11docker note: Per default x11docker stores its cache files on drive C:.
  docker setup may not allow to share files from drive C:.
  If startup fails with an 'access denied' error,
  please either allow access to drive C: or specify a custom folder for cache
  storage with option '--cachebasedir D:/some/cache/folder'.
  Same issue can occur with option '--home'.
  Use option '--homebasedir D:/some/home/folder' in that case.

'\\wsl$\Debian\home\eine'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
x11docker WARNING: Option --no-auth: SECURITY RISK!
  Allowing access to new X server for everyone.
  Your X server is accessable over TCP network without any restriction.
  That can be abused to take control over your system.


(xfce4-terminal:130): dbind-WARNING **: 03:51:11.657: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
/mnt/t/x11docker/x11docker: line 869: 15484 Terminated              watchmessagefifo

You need --no-auth in x11docker, too. Did I change that once? I am not sure yet.

Maybe I misunderstood #165 (comment) and #165 (comment) ? Or the implementation details changed since then? See also command examples in #165 (comment)

[mviereck]

None of them writes any content to the log.

Odd. Do you get output with --verbose?

All logs that are created down to 6.4.0 show:

C:\Program Files\Docker\Docker\resources\bin\docker.exe: Error response from daemon: file does not exist. 
See 'C:\Program Files\Docker\Docker\resources\bin\docker.exe run --help'.

Anyway, I tried [...] runx master and x11docker master on WSL, and it works. Hence, I believe this is not an issue with Docker, but with path mangling in MSYS2.

Good investigation! So probably something changed in MSYS2. At least one of the older x11docker versions must have worked for you previously.
For comparison: Does x11docker work in Cygwin?

Maybe disabling MSYS2 path mangling at all makes a difference:

env MSYS2_ARG_CONV_EXCL='*' /t/runx/runx --no-auth -- /mnt/t/x11docker/x11docker --no-auth x11docker/xfce xfce4-terminal

I'll also try to avoid the double slash although it should not hurt. I need to look close at the related code again why/where it is generated.

Maybe I misunderstood #165 (comment) and #165 (comment) ? Or the implementation details changed since then?

Likely I changed something and can't remember ... the latest master works again with --no-auth in runx only.

[eine]

Odd. Do you get output with --verbose?

No. Actually, with --verbose I get even less output. The logfile is empty and no x11docker content is shown in the terminal:

# /t/runx/runx --no-auth -- /t/x11docker/x11docker --verbose x11docker/xfce xfce4-terminal
runx note: Using random X display number :3249.
  If this display number is already in use, X server startup  will fail.
  You can specify a display number N with option '--display N'.

runx note: Windows firewall settings can forbid application access
  to the X server. If no application window appears, but no obvious error
  is shown, please check your firewall settings.
  Compare:   https://github.com/mviereck/x11docker/issues/108

runx WARNING: Option --no-auth: Cookie authentication is disabled!
      SECURITY RISC!
  Your X server vcxsrv listens on TCP connections without any protection.
  Others could try to access your system through network connections.
  Please use option --no-auth for debugging only.

DISPLAY=10.0.75.1:3249

All logs that are created down to 6.4.0 show:

C:\Program Files\Docker\Docker\resources\bin\docker.exe: Error response from daemon: file does not exist. 
See 'C:\Program Files\Docker\Docker\resources\bin\docker.exe run --help'.

That directory and file do exist. The error must be produced by some of the arguments (volumes?) passed to docker (run).

Good investigation! So probably something changed in MSYS2. At least one of the older x11docker versions must have worked for you previously.
For comparison: Does x11docker work in Cygwin?

Yes, it works in Cygwin.

Maybe disabling MSYS2 path mangling at all makes a difference:

env MSYS2_ARG_CONV_EXCL='*' /t/runx/runx --no-auth -- /mnt/t/x11docker/x11docker --no-auth x11docker/xfce xfce4-terminal

It seems to make no difference at all. If we could have the log saved to some other location (say cwd/pwd), that would help us understand which commands are being passed. However, it's odd because a folder is properly created and removed in ~/.cache/x11docker/*. Hence, x11docker is partially correct when managing paths.

[mviereck]

Let's discuss in a new ticket #225 because this is an MSYS2 related issue, not a --runx one.

As for --runx: Could you please try without --no-auth?
E.g. in WSL:

/mnt/t/x11docker/x11docker --runx  x11docker/xfce xfce4-terminal

In Cygwin:

/cygdrive/t/x11docker/x11docker --runx  x11docker/xfce xfce4-terminal

[eine]

In WSL, the X server is started, but the container fails. The container is automatically removed, but the X server is not.

 /mnt/t/x11docker/x11docker --runx  x11docker/xfce xfce4-terminal
'\\wsl$\Debian\home\eine'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
Failed to connect to bus: No such file or directory
x11docker note: Enabled X over TCP instead of sharing unix socket.

x11docker note: Per default x11docker stores its cache files on drive C:.
  docker setup may not allow to share files from drive C:.
  If startup fails with an 'access denied' error,
  please either allow access to drive C: or specify a custom folder for cache
  storage with option '--cachebasedir D:/some/cache/folder'.
  Same issue can occur with option '--home'.
  Use option '--homebasedir D:/some/home/folder' in that case.

'\\wsl$\Debian\home\eine'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
Authorization required, but no authorization protocol specified
Unable to init server: Could not connect: Connection refused

(xfce4-terminal:119): Gtk-WARNING **: 11:53:01.916: cannot open display: 10.0.75.1:2645
/mnt/t/x11docker/x11docker: line 869: 19157 Terminated              watchmessagefifo

There is no logfile in ~/.cache/x11docker.

In Cygwin, everything works as expected, and a non-empty logfile is generated.

[mviereck]

The container is automatically removed, but the X server is not.

runx should terminate after x11docker terminates. Could you check with a host application, too? E.g. runx -- xterm.

In WSL, the X server is started, but the container fails.
no authorization protocol specified

The transmission of the cookie seems to fail. Surprisingly it works in Cygwin. Could you please run with --debug? Alternatively provide me the logfile. (See below)

There is no logfile in ~/.cache/x11docker.

With MobyVM x11docker creates the cache in your Windows home, something like C:/Users/eine/x11docker/cache.
The latest commit copies the log into WSL to ~/.cache/x11docker/x11docker.log, too.
Also there is now a symlink to the cache in ~/.cache/x11docker/symlink.

Storing the cache outside of WSL is a workaround for easier/safer sharing of files with MobyVM.

[eine]

runx should terminate after x11docker terminates. Could you check with a host application, too? E.g. runx -- xterm.

With a host application, it works. It didn't at first, but I then executed it 4-5 times and it worked as expected.

However, /mnt/t/x11docker/x11docker --runx x11docker/xfce xfce4-terminal fails to start the app inside the container. Currently, the X server is started, the container seems to be created, but it prints (xfce4-terminal:123): Gtk-WARNING **: 05:53:04.282: cannot open display: 10.0.75.1:3273. Then, both the container and the X server are properly removed. Fortunately, I can provide a logfile now: x11docker.log

With MobyVM x11docker creates the cache in your Windows home, something like C:/Users/eine/x11docker/cache.
The latest commit copies the log into WSL to ~/.cache/x11docker/x11docker.log, too.
Also there is now a symlink to the cache in ~/.cache/x11docker/symlink.

Storing the cache outside of WSL is a workaround for easier/safer sharing of files with MobyVM.

In understand why is it. However, is it documented elsewhere? I tried to look at ~/.cache/x11docker because that's where logfiles are saved in every other environment (Linux, MSYS2, Cygwin). If this is different, maybe an explicit note needs to be shown. This is the current output:

/mnt/t/x11docker/x11docker --runx  x11docker/xfce xfce4-terminal
'\\wsl$\Debian\home\eine'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
ln: /home/eine/.cache/x11docker/symlink: cannot overwrite directory
Failed to connect to bus: No such file or directory
x11docker note: Enabled X over TCP instead of sharing unix socket.

x11docker note: Per default x11docker stores its cache files on drive C:.
  docker setup may not allow to share files from drive C:.
  If startup fails with an 'access denied' error,
  please either allow access to drive C: or specify a custom folder for cache
  storage with option '--cachebasedir D:/some/cache/folder'.
  Same issue can occur with option '--home'.
  Use option '--homebasedir D:/some/home/folder' in that case.

'\\wsl$\Debian\home\eine'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
Authorization required, but no authorization protocol specified
Unable to init server: Could not connect: Connection refused

(xfce4-terminal:123): Gtk-WARNING **: 05:53:04.282: cannot open display: 10.0.75.1:3273
/mnt/t/x11docker/x11docker: line 874: 24742 Terminated              watchmessagefifo
/mnt/t/x11docker/x11docker: line 637: ::: command not found

[mviereck]

Currently, the X server is started, the container seems to be created, but it prints (xfce4-terminal:123): Gtk-WARNING **: 05:53:04.282: cannot open display: 10.0.75.1:3273.

I found the issue in the log: x11docker has overwritten XAUTHORITY too early; it needs to copy the one created by runx first. Is fixed now.

With a host application, it works. It didn't at first, but I then executed it 4-5 times and it worked as expected.

It makes sense to run runx --cleanup from time to time. For unknown reasons the cookie file can be corrupted sometimes.

However, is it documented elsewhere? I tried to look at ~/.cache/x11docker because that's where logfiles are saved in every other environment

x11docker now creates a text file in cache to explain this:

echo "x11docker: With MobyVM x11docker cache in WSL is stored in 
$Cachebasefolder
to allow file sharing with containers.
A symbolic link is created in WSL at
$Hostuserhome/.cache/x11docker/symlink
" >> "$Hostuserhome/.cache/x11docker/symlink/symlink.txt"

The log file is copied to ~/.cache/x11docker now. This is the documented location. Otherwise the cache (location or content) is not documented.

x11docker note: Per default x11docker stores its cache files on drive C:.

I've adjusted the message to appear only for the combination WSL+MobyVM.

[mviereck]

@eine Could you please run a new test in WSL if you find some time?

/mnt/t/x11docker/x11docker --runx x11docker/xfce xfce4-terminal

[eine]

I pulled latest x11docker and runx, and it does not work:

/mnt/t/x11docker/x11docker --runx x11docker/xfce xfce4-terminal
Failed to connect to bus: No such file or directory
x11docker note: Enabled X over TCP instead of sharing unix socket.

x11docker note: With MobyVM and WSL x11docker stores its cache files on drive C:
  to allow cache file sharing.
  Your Docker setup might not allow to share files from drive C:.
  If startup fails with an 'access denied' error,
  please either allow access to drive C: or specify a custom folder for
  cache storage with option '--cachebasedir D:/some/cache/folder'.
  Same issue can occur with option '--home'.
  Use option '--homebasedir D:/some/home/folder' in that case.

Authorization required, but no authorization protocol specified
Unable to init server: Could not connect: Connection refused

(xfce4-terminal:119): Gtk-WARNING **: 17:42:56.318: cannot open display: 10.0.75.1:1844
/mnt/t/x11docker/x11docker: line 874:  3047 Terminated              watchmessagefifo
/mnt/t/x11docker/x11docker: line 637: ::: command not found

x11docker.log

[mviereck]

Thank you for the test!
It was a rather stupid bug: x11docker tried to copy '$XAUTHORITY' with single quotes instead of double quotes.
Could you please try again?

[eine]

It seems to work now!

$ /mnt/t/x11docker/x11docker --runx x11docker/xfce xfce4-terminal
'\\wsl$\Debian\home\eine'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
Failed to connect to bus: No such file or directory
x11docker note: Enabled X over TCP instead of sharing unix socket.

x11docker note: With MobyVM and WSL x11docker stores its cache files on drive C:
  to allow cache file sharing.
  Your Docker setup might not allow to share files from drive C:.
  If startup fails with an 'access denied' error,
  please either allow access to drive C: or specify a custom folder for
  cache storage with option '--cachebasedir D:/some/cache/folder'.
  Same issue can occur with option '--home'.
  Use option '--homebasedir D:/some/home/folder' in that case.

'\\wsl$\Debian\home\eine'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.

(xfce4-terminal:119): dbind-WARNING **: 04:10:04.967: Error retrieving accessibility bus address: org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not provided by any .service files
Failed to connect to session manager: Failed to connect to the session manager: SESSION_MANAGER environment variable not defined
/mnt/t/x11docker/x11docker: line 874:  6357 Terminated              watchmessagefifo
/mnt/t/x11docker/x11docker: line 637: ::: command not found

x11docker.log

However:

• Note the "command not found".
• I don't know why when x11docker is used the font type and size of the terminal change.

[mviereck]

It seems to work now!

Great! I'll publish release v6.6.1 now with the latest fixes.

Note the "command not found".

Fixed: Has been :: instead of ;; in a case...esac.

I don't know why when x11docker is used the font type and size of the terminal change.

I have no idea why this happens. Does it happen, too, if you run runx only?

[eine]

Fixed: Has been :: instead of ;; in a case...esac.

I can confirm.

I don't know why when x11docker is used the font type and size of the terminal change.

I have no idea why this happens. Does it happen, too, if you run runx only?

Yes, it happens if I run runx only. However, it does not happen with x11docker.

[mviereck]

Yes, it happens if I run runx only. However, it does not happen with x11docker.

runx and x11docker use some escape codes for colored output. Maybe that causes the font changes on MS Windows? However, than it should happen with both of them.

You could try:

  # Terminal colors used for messages and --verbose=c
  Esc="$(printf '\033')"
  Colblue="${Esc}[35m"
  Colyellow="${Esc}[33m"
  Colgreen="${Esc}[32m"
  Colgreenbg="${Esc}[42m"
  Colred="${Esc}[31m"
  Colredbg="${Esc}[41m"
  Coluline="${Esc}[4m"
  Colnorm="${Esc}[0m"

echo "Hello previous world $Colgreen Hello green world $Colnorm Hello normal world"

[mviereck]

Closing here because the core issues and tests of option --runx are done.
Continuing the terminal/font size issue in #244