[Bug]: /app/bin/easyterm.py: cannot execute: required file not found

Describe the bug

"Run in Terminal" does not work properly. It works fine if the option is not checked.

To Reproduce

1. Create a new bottle
2. Check the "Run in Terminal" option in the gear icon
3. Click "Run Executable" and select an executable file to run

Package

Flatpak from Flathub

Distribution

Fedora 41

Debugging Information

Official Package: true
Version: '51.21'
DE/WM: gnome
Display:
    X.org: true
    X.org (port): :0
    Wayland: true
Graphics:
    vendors: {}
    prime:
        integrated: null
        discrete: null
Kernel:
    Type: Linux
    Version: 6.13.9-200.fc41.x86_64
Disk:
    Total: 14591766528
    Free: 14591602688
RAM:
    MemTotal: 27.2GiB
    MemAvailable: 24.0GiB
Bottles_envs: null

Troubleshooting Logs

22:51:13 (INFO) Launching an executable… 
22:51:14 (WARNING) No GPU vendor found, keep going without setting VK_ICD_FILENAMES… 
22:51:14 (INFO) Command: easyterm.py -d -p "#00ffff #2b2d2e" -c 'bash -c '"'"'/var/home/hikari/.var/app/com.usebottles.bottles/data/bottles/runners/soda-9.0-1/bin/wine64 /var/home/hikari/path/to/executable.exe'"'"'' 
/bin/sh: line 1: /app/bin/easyterm.py: cannot execute: required file not found

Additional context

No response

Yep, stopped working today right after installing these Flatpak updates:

com.usebottles.bottles.Locale org.gnome.Platform.Compat.i386 com.usebottles.bottles

Which seems to point to about 2 weeks old (and last) commit (why it was offered as a Flatpak udpate only now?): https://github.com/bottlesdevs/Bottles/commit/8875b2b3c6a73d12d869d1106091876bf6eacf1b

Huh, I thought we canceled the build in https://buildbot.flathub.org/#/builders/6/builds/192819 - it was merged accidentally. I'll revert that right away.

@TheEvilSkeleton Just updated again, and it still doesn't work. Same error message as before.

Same issue, installed the exact build in that PR, opening any terminal within Bottles results in /bin/sh: line 1: /app/bin/easyterm.py: cannot execute: required file not found

The file begins with a #!python, which seems incorrect. It should probably be #!/usr/bin/python instead.

yep, I managed to get it working again by modifying the actual file (wich would have the in-sandbox-specifiic path) /app/bin/easyterm.py script by swapping the original shebang line with the most preferred way to get the actual environment using #!/usr/bin/env python3. Namely, the exact file that I have modified on my host fs as the actual workaround was ~/.local/share/flatpak/app/com.usebottles.bottles/current/active/files/bin/easyterm.py (which is the 1-of-2 hard-linked files).

NOTE: I'm assuming here that Bottles was a user installation, not system one.

Cheers!

@MithicSpirit solution fixed it for me :)

I do not have a ~/.local/share/flatpak/app folder on my system, but I do have a ~/.var/app. The directory you listed does not exist underneath the com.usebottles.bottles directory there.

I do not have a ~/.local/share/flatpak/app folder on my system, but I do have a ~/.var/app. The directory you listed does not exist underneath the com.usebottles.bottles directory there.

I did a system wide search with sudo find / | grep easyterm.py, made sure that it was the correct file, then did the change stated above

I do not have a ~/.local/share/flatpak/app folder on my system, but I do have a ~/.var/app. The directory you listed does not exist underneath the com.usebottles.bottles directory there.

Then it will be in /var/lib/flatpak/. ~/.local/share/flatpak/ is the directory for user installations.

@kode54:

I do not have a ~/.local/share/flatpak/app folder on my system, but I do have a ~/.var/app. The directory you listed does not exist underneath the com.usebottles.bottles directory there.

yeah no, the .var-based location isn't the same as the .local one, those seem serve different purposes, much like pkg-config would aid in finding the correct location of some components of a C/C++ library etc. if that analogy helps. To make it easier finding the file in question, just do the following => find ~/ /var/ -name easyterm.py -type f 2>/dev/null . This take into consideration then the 2 (most likely only) options of system and user installations while ignoring the "Permission denied" outputs from STDERR. Or instead of ~/ /var/ you can just as well put only a single front slash for the whole system, but beware; if you have a lot of (possibly as well network-) mounted drives, it might take a while...

@TheEvilSkeleton Are there any plans to repair it now?

Finding the easyterm.py 1 in the system installation is possible 2

Applying this solution against the system-wide installation of Bottles on Fedora Atomic; /var/lib/flatpak/app/com.usebottles.bottles/x86_64/stable/f0b7c973b932f10a37b71fca40208d578d8787ee3c2dca4a595442e132615116/files/bin/ Results in the new error of ;

23:49:10 (INFO) Command: easyterm.py -d -p "#00ffff #2b2d2e" -c 'bash -c '"'"'/var/home/testop/.var/app/com.usebottles.bottles/data/bottles/runners/soda-9.0-1/bin/wine64 cmd'"'"'' 
/bin/sh: line 1: /app/bin/easyterm.py: Permission denied

Testing on user-insalled Bottles by following the original instructions does cause the script to progress and hits a different problem for a different thread.

import: unable to grab mouse '': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9351.
import: unable to read X window image '': Success @ error/xwindow.c/XImportImage/4961.
import:  `os' @ error/import.c/ImportImageCommand/1289.
import: unable to grab mouse '': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9351.
import: unable to read X window image '': Success @ error/xwindow.c/XImportImage/4961.
import:  `gi' @ error/import.c/ImportImageCommand/1289.
import: unable to grab mouse '': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9351.
import: unable to read X window image '': Success @ error/xwindow.c/XImportImage/4961.
import:  `sys' @ error/import.c/ImportImageCommand/1289.
import: unable to grab mouse '': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9351.
import: unable to read X window image '': Success @ error/xwindow.c/XImportImage/4961.
import:  `shlex' @ error/import.c/ImportImageCommand/1289.
/app/bin/easyterm.py: line 6: syntax error near unexpected token `'Gtk','
/app/bin/easyterm.py: line 6: `gi.require_version('Gtk', '3.0')'

@TheEvilSkeleton Are there any plans to repair it now?

@D0735 No, sorry. I'm currently busy with other GNOME-adjacent projects, which leaves me with very little time for Bottles. I want to dedicate the majority of my time for https://github.com/bottlesdevs/Bottles/pull/3830 eventually, but in general I prefer not to fix every single bug in 51.X, so that I can work on other (frankly more important) projects, take care of myself, and in the future have the majority of the backend rewritten as soon as possible.

Not fixing? I thought that this issue came with a build that you merged accidentally? You said on Apr 12 that you'll revert the change right away.

Yes, I did revert that change – https://github.com/flathub/com.usebottles.bottles/pull/490 – but despite merging it, you reported that the issue persists – https://github.com/bottlesdevs/Bottles/issues/3843#issuecomment-2798803211

Hmm, then something else broke it. I just don't understand what, IIRC nothing else changed. Can't even check everything now becase buildbot.flathub.org seems to be down. Well, I hope someone is able to fix this, it's a needed feature. I'd have some time but I don't have the competence to tackle this project.

@TheEvilSkeleton Thank you for your efforts; I sincerely appreciate your work.

Unfortunately, the app still encounters a bug and fails to open the terminal.

The error message is: /bin/sh: line 1: /app/bin/easyterm.py: cannot execute: required file not found.

Several users have reported this issue, including multiple duplicate reports, indicating it's a widespread problem. This feature is critical for most of us.

Thanks again for your support.

Finding the easyterm.py 1 in the system installation is possible 2

Applying this solution against the system-wide installation of Bottles on Fedora Atomic; /var/lib/flatpak/app/com.usebottles.bottles/x86_64/stable/f0b7c973b932f10a37b71fca40208d578d8787ee3c2dca4a595442e132615116/files/bin/ Results in the new error of ;

23:49:10 (INFO) Command: easyterm.py -d -p "#00ffff #2b2d2e" -c 'bash -c '"'"'/var/home/testop/.var/app/com.usebottles.bottles/data/bottles/runners/soda-9.0-1/bin/wine64 cmd'"'"'' 
/bin/sh: line 1: /app/bin/easyterm.py: Permission denied

Testing on user-insalled Bottles by following the original instructions does cause the script to progress and hits a different problem for a different thread.

import: unable to grab mouse '': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9351.
import: unable to read X window image '': Success @ error/xwindow.c/XImportImage/4961.
import:  `os' @ error/import.c/ImportImageCommand/1289.
import: unable to grab mouse '': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9351.
import: unable to read X window image '': Success @ error/xwindow.c/XImportImage/4961.
import:  `gi' @ error/import.c/ImportImageCommand/1289.
import: unable to grab mouse '': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9351.
import: unable to read X window image '': Success @ error/xwindow.c/XImportImage/4961.
import:  `sys' @ error/import.c/ImportImageCommand/1289.
import: unable to grab mouse '': Resource temporarily unavailable @ error/xwindow.c/XSelectWindow/9351.
import: unable to read X window image '': Success @ error/xwindow.c/XImportImage/4961.
import:  `shlex' @ error/import.c/ImportImageCommand/1289.
/app/bin/easyterm.py: line 6: syntax error near unexpected token `'Gtk','
/app/bin/easyterm.py: line 6: `gi.require_version('Gtk', '3.0')'

Whatever you did, you did not replace the first line in the easyterm.py with #!/usr/bin/env python3. You somehow eliminated the shebang (or the first line completely) and are running the first word of the file - import - as command in bash: https://linux.die.net/man/1/import

Trying that under root gives you the first Permission denied error, trying that in userspace actually starts import and runs into a bunch of other errors 😆

I just tried to debug this, fixed it on my machine but did not come up with a solution at the core. Just for triage, I will let everybody know what I found out.

1. The fix for me was to change the first line of /var/lib/flatpak/app/com.usebottles.bottles/x86_64/stable/f0b7c973b932f10a37b71fca40208d578d8787ee3c2dca4a595442e132615116/files/bin/easyterm.py from #!python to #!/usr/bin/env python
2. I have no idea how the #!python got inserted into that file. The correct shebang is in the easyterm source https://github.com/bottlesdevs/EasyTerm/blob/main/easyterm/easyterm.py#L1 Maybe the author of easyterm @mirkobrombin has an idea?
3. Again, just for triage, this bug is currently open in at least 5 other issues, maybe someone can close the others as duplicates:
   • https://github.com/bottlesdevs/Bottles/issues/3777
   • https://github.com/bottlesdevs/Bottles/issues/3875
   • https://github.com/bottlesdevs/Bottles/issues/3895
   • https://github.com/bottlesdevs/Bottles/issues/3875
   • https://github.com/bottlesdevs/Bottles/issues/3852

After some investigation, I don't think https://github.com/flathub/com.usebottles.bottles/pull/487 had anything to do with this bug except for having the side effect of triggering a build.

The error began occurring after the working build on March 17 with the build on April 10. This window is pretty close to Python setuptools 76.0.0 being released on March 9, which includes this notable change: https://github.com/pypa/setuptools/pull/4865 including

• Always rewrite a Python shebang to #!python.

which is exactly the issue being reported here. I suspect this change in setuptools was brought in during the rebuild due to the constantly updating (not pinned to a specific hash) underlying Flatpak SDK.

~~So, I suspect the necessary fix here would be to somehow get setuptools to stop messing with the shebang line in the EasyTerm script. I found some advice here: https://github.com/pypa/setuptools/issues/4883#issuecomment-2718691335 but I'm not very knowledgeable in Python packaging, so I'm not confident in my ability to properly apply or test that change promptly.~~ See edit below.

Edit: it looks like the change in setuptools may have been reverted? https://github.com/pypa/setuptools/pull/4974 Apparently, setuptools 80.2.0 contains the revert: https://setuptools.pypa.io/en/latest/history.html#v80-2-0 That may explain why I wasn't able to reproduce the issue in my testing with the latest GNOME 47 SDK, which uses setuptools 80.3.1... In other words, it could be that the only "fix" required at this point is to just trigger yet another build of the Flatpak in Flathub.

• Always rewrite a Python shebang to #!python.

Slightly off topic: I really tried, but I found almost nothing about #!python and before yesterday had never seen that shebang. Where does that come from? Why would they want to replace (the generally recommended?) #!/usr/bin/env python?

Slightly off topic: I really tried, but I found almost nothing about #!python and before yesterday had never seen that shebang. Where does that come from? Why would they want to replace (the generally recommended?) #!/usr/bin/env python?

See pypa/distutils#332. Basically, installers might not want to use the python in the PATH, so it just defaults to #!python, and the installer is supposed to directly replace that (presumably with something that walks the directories, looking for files beginning with #!python\n and replacing that with whatever they want). I guess this means that the "correct" solution here would've been for flatpak to update their builders to do this.

@TheEvilSkeleton As ianprime0509 stated, can you try trigger a build?

As the non flatpak version is unsupported and I needed the terminal I reverted to the March build where the terminal still works (2025-03-17).

Just in case anyone needs it

sudo flatpak update --commit=7e040371dd682e1af61af0fda41c20d5d487e452eacc3401475eff3a895854d7 com.usebottles.bottles

and prevent updating

sudo flatpak mask com.usebottles.bottles

add --remove to undo the mask

I edited the shebang to #!/usr/bin/env python but now I get a different error, related to os.getcwd() (File not found). I'm running the flatpak version of Bottles on a Steam Deck, both on their respective latest stable releases.

I edited the shebang to #!/usr/bin/env python but now I get a different error, related to os.getcwd() (File not found). I'm running the flatpak version of Bottles on a Steam Deck, both on their respective latest stable releases.

Did you happen to change the bottle directory from default? Since flatpaks run in a sandbox, you'll have to grant the program access to that directory first.

https://docs.usebottles.com/flatpak/expose-directories

It's been 3 months and no fix for this rather important feature. What's the situation with the Bottles development? Recently there were an automatic closing of open issues too... hopefully Bottles isn't dying...

I haven't moved the bottle after creating it, but I did set my own default bottles directory, which is where all my bottles get installed. I'm pretty sure the paths are exposed to bottles, but ai'll have to double check later

I haven't moved the bottle after creating it, but I did set my own default bottles directory, which is where all my bottles get installed. I'm pretty sure the paths are exposed to bottles, but i'll have to double check later.

UPDATE: Just checked my Deck, indeed I enabled all options under Filesystem in Flatseal. Access restrictions should not be an issue. Is there something I can do to test?

17:37:12 (INFO) Command: easyterm.py -d -p "#00ffff #2b2d2e" -c 'bash -c '"'"'/home/deck/.var/app/com.usebottles.bottles/data/bottles/runners/ge-proton10-4/files/bin/wine64 cmd'"'"'' 
Gtk-Message: 17:37:12.968: Failed to load module "canberra-gtk-module"
Traceback (most recent call last):
  File "/app/bin/easyterm.py", line 13, in <module>
    CONF_DEF_CWD = os.getcwd()
                   ^^^^^^^^^^^
FileNotFoundError: [Errno 2] No such file or directory