[Discussion] Improvements to distrobox-export --bin

[Scafir]

Hi,

Following the discussion with @fredizzimo in #651, I think that it is best to discuss how to tackle the exported binaries.

First of all, let me write down the goal (in my opinion) that we should strive for with binaries export:
"Exported binaries should produce the same result than the same command run from inside the distrobox"

To reach this goal, I suggest using a login shell by default, as not using it may only cause hard to debug issues, with no clear advantage.
I would also argue that using a login shell and executing the command within that also solve an issue raised in the original merge request: in what shell should the command be run?
There are three level to this:

1. What shell interprets the arguments given? (globbing, etc) -> the shell from which the exported binary is called
2. What shell actually executes the exported binary? -> ??
3. What is the $SHELL present while executing the exported binary? -> the default shell set inside the distrobox

I would argue that number 2 is not actually important, as no matter the shell, the end result should be the same.
This allows us to use a single shell for all use case inside the exported script. This is a big advantage over using $SHELL, as it allows us to avoid having to determine what syntax should be used (e.g: fish does not use $@).

Being careful avoiding issues with binary files that may not be executed with a simple sh -l myBinaryFile, we would get a end result along the lines of:

distrobox-enter ${rootful} -n  myDistrobox -- ${is_sudo} sh -lc 'path/to/command "$@"' command ${extra_flags} "$@"

I will most likely submit a merge request for this, do not hesitate to let me hear your thoughts.

[89luca89]

Thanks @Scafir for the issue!

I'm not completely sure that using the login shell solves all the escaping/globbing problems:

~$ sh -lc "ls *"

the glob is still resolved by the main shell before calling sh, you need to escape that glob anyway, and we're back to square one :)

the shell that calls the exec is known, and it's /bin/sh because that's what is in the shebang of the wrapper script in the bin

[fredizzimo]

One thing that the login shell helps with, is dealing with environment variables and isolated environments as described in this issue #656, towards the bottom of it.

[Scafir]

Hi @89luca89,

I believe that the current globbing mechanism is fine: when working inside a certain shell, I expect that globbing works the same across all input commands, even if those commands are forwarded to other shells later on. Do you agree?

Concerning escaping: in my proposition, the escaping problem is solved by using the somewhat strange sh -lc 'path/to/command "$@"' commandName "$@".
You may note that both $@ are fully enclosed in double quotes, which makes them resolve properly. I have been using this syntax for a while know and am confident it works. I documented myself with this resource . If you'd prefer, I could also use the same escaping algorithm used in distrobox-enter.

I should also thank you for all your work on this tool, I've been very happy using it and made a small presentation about it at CERN which was quite well received :)

[89luca89]

@Scafir I've just commented the PR, I think we can switch to an "always-login" mode, but I'd like to keep the current "globbing management"

I should also thank you for all your work on this tool, I've been very happy using it and made a small presentation about it at CERN which was quite well received :)

Saw that! Thanks to you for the presentation and suggesting it! 😄

[lakano]

Hi!
I still have a bad glob interpolation with version 1.6.0.1

I have "npx" program exported
I have some bash scripts that call npx and do a wrong glob interpolation ( the wildcard character )

A simple script:

#!/bin/bash
read -e 
npx ... --command "$REPLY"

When you launch it from the host, if you fill to the "read" command a query like SELECT * FROM, the wildcard character will have an interpolation with your files names.

Also, the problem is the same in command line, if you call this script like this: ./test.sh 'SELECT * FROM'

#!/bin/bash
npx ... --command "$1"

The single quote in command line should prevent glob interpolation, as the double quotes around the $1 in the bash script. I've also tried to uses "set -f" or "shopt" but this doesn't works.

If I enter inside the container, then the scripts works as expected.

[salim-b]

Hi @89luca89, first of all, thanks a lot for developing such a great tool!

I noticed that with latest Distrobox 1.8.1.2, distrobox-export generates an Exec command that uses a non-login shell again. Your original 8458c29 was fine I guess, but meanwhile the code changed to

distrobox/distrobox-export

Lines 267 to 282 in 71cf829

	# Command to execute
	container_command_suffix="'${exported_bin}' ${extra_flags} \"\$@\""
	# Check if exported application/binary should be run with sudo privileges
	if [ "${is_sudo}" -ne 0 ]; then
	sudo_prefix="sudo -S"
	# Edge case for systems without sudo
	if command -v su-exec > /dev/null >&1; then
	sudo_prefix="su-exec root"
	container_command_suffix="sh -l -c \"'${exported_bin}' ${extra_flags} \$@\""
	fi
	fi
	# Prefix to add to an existing command to work through the container
	container_command_prefix="${DISTROBOX_ENTER_PATH:-"distrobox-enter"} ${rootful} -n ${container_name} ${enter_flags} -- ${sudo_prefix} "

I'm not sure I fully understand all the code in there but I'm sure that if we don't specify --sudo and hence is_sudo=0, a non-login shell is used. Could this be changed to always use a login shell regardless of --sudo?