pineflash doesn't find binaries (pkexec) because it overrides the PATH variable

[nydragon]

Hardcoding the PATH makes Command unable to find the pkexec binary on NixOS:

pineflash/src/submodules/flash.rs

Line 186 in 1cbe554

.env("PATH", "/usr/local/sbin:/usr/local/bin:/usr/bin:/bin:linux")

Removing this line (82605e4) fixes the issue, and as the hardcoded values are already contained in PATH by default, removing it should not break anything on other distros.

Can submit a PR if wished.

[acuteaangle]

I’m assuming you’re using the appimage?

Interestingly, the dfu-util version of this function had this this commented out in e263b0fc8 ‘appimage improvements’.

I wasn’t able to find the original reason that line was included.

[nydragon]

I am building the program from source as i wanted to make it run natively on my machine

[acuteaangle]

Were you able to run PineFlash without patching the binary with patchelf? In my testing for the Nixpkgs PR, patchelf was necessary to add libxkbcommon and libGL to rpath.

[nydragon]

I added the library paths to LD_LIBRARY_PATH using wrapProgram (link) and patched out the aforementioned line, but I'm not sure what is the better practice.

Also i think you don't need the patch you added to your PR, works fine without

[acuteaangle]

The patch was necessary in my testing, as otherwise it would find the unwrapped pkexec and fail complaining that it wasn’t SUID. I assume wrapProgram is related to the differing behavior.

[nydragon]

Ah alright then, but what about the issue ? Would removing the line break AppImage compat ?

[acuteaangle]

The appimage compat commit was making essentially the same change as proposed here but for the dfu-util path.
I’m not super familiar with the internals of appimages, but it seems like this was also causing some sort of problem there.

I don’t have a non-NixOS system currently to test if this would break anything elsewhere.
I’d really like it if PineFlash had an end-to-end test.