[Bug] Binary fixes only accepts the default PATH

[mazunki]

Situation: Some of the fixes can only be done through arguments to the command, as for example --config-directory ${XDG_CONFIG_HOME}/evil_app.

There are a few ways we can deal with this, and the most common one is probably to make an alias in your shell's runtime configuration file. We've opted out of this option because of mainly two reasons:

• Not all shells have support for aliases, and the syntax is not universal.
• Said configuration is not sourced in all cases. Some programs like dmenu may run with a clean environment, for instance.

The same logic applies for creating shell functions.

The current implementation consists of adding a binary with the same name early in PATH, so that it takes precedence over evil_app's original location.

This works fine... except when we apply the fixes and try to exec evil_app --config-directory=${XDG_CONFIG_HOME}/evil_app we'll run into a cyclic call, reaching a recursion limit eventually.

We've bypassed this problem by using command -p which cleans PATH to the system's default PATH. Not ideal, but it works provided PATH is not changed otherwise.

The other way to solve this problem would be to rename the original source command to _evil_app, and exec it instead, but that could cause permission issues, package manager issues, and potentially other problematic issues.

Lastly, using sed, or similar, to remove ${force_xdg_bin_home} from the PATH sounds like a potential solution, but I would like validation before implementing it. For now I think using a sane deafult PATH is ok, but not perfect.

[Fuseteam]

perhaps generate binary wrappers.dump them in ~/.local/share/evil_app and symlink them into ~/.local/bin

[mazunki]

perhaps generate binary wrappers.dump them in ~/.local/share/evil_app and symlink them into ~/.local/bin

Do you think said binaries should be dumped into evilapp's data dir?

[Fuseteam]

maybe? isn't that what cargo basically does?