Check $PATH for executables

[pktiuk]

Currently, assigning executable to a button requires providing full path to used executable, it would be convenient to check also places like /bin/ to check if used executable exists instead of asking user about providing full path.

[gombosg]

True, but IMO this is a very minor nuisance with this pretty well-hidden function. Also, I can only open the "Advanced" window after setting some key, but this shouldn't be necessary, right?

[pktiuk]

I agree, I also think this name should be a bit more descriptive, like Advanced assignemnt (at least I had some problems with finding it)

[OlegPopow]

It would not be so convenient at all, I urge you to explain why. Firstly, different distributions have different standards. For example, Arch Linux:

Arch Linux follows the file system hierarchy for operating systems using the systemd service manager. In particular, /bin, /sbin, and /usr/sbin are symbolic links to /usr/bin, and /lib and /lib64 are symbolic links to /usr/lib.

Of course, there will be distributions where this may look different and will probably be distributions that do not use systemd only with openrc or runit. Contrary to appearances, there is no shortage of such distributions. In this case, a rigidly added option may not work very well or cause unnecessary perturbations.

If you want to establish such a path so much, in my opinion it should be /usr/local/bin and this option should be only one of the available options. Though, as long as I'm not mistaken, it may not be compatible with Debian standards [1] - as long as you can distinguish between installing scripts by apt and manually placing them there. Anyway, this confirms that each system has its own specific rules, and it is impossible to satisfy each of them.

A lot of users place such scripts in their home directory in directories with very different names - why deprive users of choice?

1.https://lintian.debian.org/tags/file-in-usr-local.html

[pktiuk]

Arch Linux follows the file system hierarchy for operating systems using the systemd service manager. In particular, /bin, /sbin, and /usr/sbin are symbolic links to /usr/bin, and /lib and /lib64 are symbolic links to /usr/lib.

Yes, and that's why PATH is used (and it is used not only in Linux).

How checking existence of executable in one of defined by PATH directories would deprive them of choice?
They could still use regular path to their scripts, only in case of not finding it PATH would be checked.

[OlegPopow]

If you retain the ability to manually place the script in any directory in the home directory plus what you are talking about, there is no problem.

Nevertheless, I know from experience that it would be better to do exactly the opposite. The first choice should be to place the scripts in the home directory (because that's what most users do) and an optional one should be searching in directories like /usr/local/bin. I assure you that a lot of users of this program are people who want to play and do not necessarily know about the system. For them it is much more convenient to place what they write in a directory like /home/user/Scripts.

[gombosg]

Basically, this is what shells are automatically doing (searching for commands in $PATH when you type something).

If there is a simple, native way to do that, then this could make sense, but if not, then I don't think that it would be worth the time and effort to replicate that functionality manually.

90% of binaries are either in (or symlinked to) /usr/bin. Most Linux users know this, and it's easier to put a tooltip in the app or the README describing how to use the which command if they don't know where their binary is.

Also, the $PATH that antimicrox sees in its environment may be different from what the user expects.

$PATH is messy because different shells parse and set it up differently.

For example, my preferred shell is Fish but it's not the system default (selected via chsh), so the $PATH in my terminal is not the same as $PATH for apps started from the GNOME GUI. Sandboxed Flatpak apps may not see any meaningful $PATH at all.

IMO we should close this, and concentrate on fixing the 'execute on key press' feature, and also making it more visible, advertising it to users, then maybe improving it if requested by them.

(Generally, this is how I approach most stuff: we should concentrate on code cleanup and fixing bugs as there are several; and only add new features if we see it as very useful and well worth the time and effort.)