Saga of Double-click my file name not running the script

Python Help
1

I have been writing programs (scripts?) on a Windoze 7 computer for years now with no problems double clicking my scripts and Windoze auto-magically opening a terminal window .

For my grandsons I copied off my entire Python sub-directory and copied it onto this Linux box. Most of my Python programs simply refused to run when double-clicked. My Tkinter programs, on the other hand seem to run very well.

One suggestion I ran across said to enable ‘Allow executing file as program’.

So, today I found that if I open ‘properties’ for the file, and select the Permissions tab there is a line with a checkbox ‘allow executing file as a program’. I check that and I get a dialog box asking if I want to ‘Run in Terminal’ and three other options. Run in terminal and (assuming no other errors in my code) the script executes and all is better in my world.

Not perfect, by any means. But better. But I’m pretty sure my little five year old entertainment can play ‘Squirrelly Whirly’ now. (Squirrel - Eat - Squirrel.)

Any new insights into this problem would be appreciated.

2 Likes
2

Hi Josh! I recall you mentioned this issue in an earlier post. I’m glad you figure out at least some kind of solution.

I wrote a chapter in Automate the Boring Stuff with Python about setting up Python scripts to run on Linux. I think your approach with the checkbox is probably better, but alternatively the chapter does mention several steps for being able to run Python scripts from Ubuntu Dash (which comes up when you press the Windows key in Ubuntu). Chapter 12 - Designing and Deploying Command Line Programs, Automate the Boring Stuff with Python, 3rd Ed

But again, I think probably your way of doing it by setting that checkbox for each file is probably the most direct way.

Just so I can possibly look into it more, what distro of Linux is your grandson using? Is it Ubuntu? Something else?

1 Like
3

Which distro of Linux?

osh@Calypso:~$ cat /etc/os-release
NAME=“Linux Mint”
VERSION=“20.3 (Una)”
ID=linuxmint
ID_LIKE=ubuntu
PRETTY_NAME=“Linux Mint 20.3”
VERSION_ID=“20.3”

The Python I’m using is 3.8

Something else I just finished studying on and finishing up . . . Somewhere I read about a thing called (I think) a ‘shebang’. Without it even with the Properties - Permissions - set to ‘allow executing file as program’ the script would not run.

#!/usr/bin/env python3.8
#
# Test of Python script creation inside Linux
#
print("")
print("   :     Hello KC.")
print("")
#
quit = input("   Press enter to Quit.")
#

That first line is the ‘shebang’. I’m pretty sure none of my windoze python scripts have it. (And my Windows 7 machine is running Python 3.8.3 - 32 bit - if that makes a difference.)

4

The shebang, shell-bang or hash-bang is a line at the beginning of
an executable text file (ie. a script) which tells Unix and
Unix-like operating systems how to execute the file. Unix and its
descendants (Linux, macOS, etc.) don’t use file extensions (like
.py, .png, etc.) to associate a file-type with an application.

Since there are many scripting languages, the OS needs a way to know
with which programming language interpreter that file should be
executed.

If a file “program.py” contains the hash-bang “#!/usr/bin/python”
then the operating system (the kernel) runs “/usr/bin/python
program.py”. The same is true if the program is simply called
“program” (without an extension).

Without the hash-bang, the kernel runs the file with the default
interpreter “/bin/sh” which is an entirely different scripting
language interpreter for shell scripts.

You’ve said that your Linux system is “Linux Mint 20.3”. What would
be more useful is to know the file-manager which you use? Nautilus?

I’m on Linux Mint 22.2 and am not sure if there are any difference.
On LM 22.2 Nautilus isn’t well configured to run Python scripts
directly, you have to setup this yourself:

  1. Go to “$HOME/.local/share/applications/” where “$HOME” is your
    user directory (like “/home/josh”) and create a file
    “python3.desktop” with the following content:
[Desktop Entry]
Version=1.0
Name=Python 3
Comment=Run with Python 3
Keywords=programming;code;development;python;
Exec=python3 %F
Icon=python
Terminal=true
Type=Application
StartupNotify=true
Categories=GTK;GNOME;Development;
MimeType=text/x-python;application/x-python;

  1. Go back to your file-manager, right-click on some Python script
    and choose “Open with”.

  2. Find the just created “Python 3” entry. If it is not there, log
    out and login again.

  3. Select that “Python 3” entry. At the bottom of the window, you
    should see a checkbox (switch) “Always use for this file type” and
    below that the file-type “Python-3-Script”. Enable this
    checkbox/switch and click “Open”.

After this, double-clicking a Python3 Script should always run the
script directly instead of opening it in a text-editor or ask you,
what to do.

5

If you use a .desktop file like MirkoK suggests, then the Linux distro and file manager are unlikely to matter since the .desktop file spec is well standardised.

The reason why non-tkinter programs appeared to not work before is that launching an executable (or Python script) through the desktop works but doesn’t create a new terminal window to read or write to. On Windows, whether an application is considered to be a console application or a GUI is decided by the how the application is compiled (hence why there’s both a python.exe and a pythonw.exe) but on Linux, it’s inferred from whether or not you’re launching it from the desktop. Depending on what your non GUI scripts were doing, they may have invisibly succeeded or silently hit a EOFError on trying to call input() with no console to read from. Your Run in Terminal option or the Terminal=true .desktop file will force all Python applications to be given a terminal – even if they were GUIs and didn’t need one.

File extensions are significant to the desktop, even if they’re ignored by the kernel. The association that a *.py filename implies a text/x-python mimetype is defined somewhere around /usr/share/mime/text/x-python.xml whose contents look roughly like:

<?xml version="1.0" encoding="utf-8"?>
<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="text/x-python">
  <comment>Python script</comment>
  <comment xml:lang="zh-Hant-TW">Python 指令稿</comment>
  <comment xml:lang="zh-Hans-CN">Python 脚本</comment>
  <-- a load more translations --/>
  <sub-class-of type="application/x-executable"/>
  <sub-class-of type="text/plain"/>
  <glob pattern="*.py" weight="60"/>
  <glob pattern="*.pyx" weight="60"/>
  <glob pattern="*.wsgi" weight="60"/>
</mime-type>

But in the absence of a file extension, the desktop respects shebangs. And the desktop knowing that the file it has is a Python file doesn’t do it any good if it still thinks that the way to open them is to run them with /bin/sh.

6

Thanks guys. For all the suggestions and explanations.

But as I said before, this Linux box is intended primarily for my grandsons (the little monsters they really are) to do strange, weird, and wonderful things on. The oldest one has said he wants to ‘learn to code’ . . . And with the shbang and the permissions figured out it should be no real problem for them to get started now. The oldest is ten. (Would that be too young?)

7

Dear Brénainn |

  • |

I think I’m good (for now). I thank you for the enlightened response. Regarding file extensions, Coming from the ‘DOS world’ I always thought the file extensions were how things worked. Then a stint in the Macintosh world . . where programs were in one neat package (with a data fork and a resource fork). Versus windows with dll files etc. etc. etc. strewed all over creation. Now I’m going to stick to Windows 7 till they pry it out of my cold dead hands.

But, for my grandsons and the opportunity to play with a real computer . . Linux seemed like a good way to go. Till I copied my python scripts over to the Linux box and things just didn’t go right. But, with the permissions and the shebang I ought to be able to get the boys started with Python - assuming they get really interested.

And, Thank You for the assistance.
Josh.

P.S. By any chance, do you know of a python tutorial (in pdf) specifically for a ten year old?

| Brénainn Woodsend bwoodsend
October 2 |

  • | - |

If you use a .desktop file like MirkoK suggests, then the Linux distro and file manager are unlikely to matter since the .desktop file spec is well standardised.

The reason why non-tkinter programs appeared to not work before is that launching an executable (or Python script) through the desktop works but doesn’t create a new terminal window to read or write to. On Windows, whether an application is considered to be a console application or a GUI is decided by the how the application is compiled (hence why there’s both a python.exe and a pythonw.exe) but on Linux, it’s inferred from whether or not you’re launching it from the desktop. Depending on what your non GUI scripts were doing, they may have invisibly succeeded or silently hit a EOFError on trying to call input() with no console to read from. Your Run in Terminal option or the Terminal=true .desktop file will force all Python applications to be given a terminal – even if they were GUIs and didn’t need one.

MirkoK:

Unix and its
descendants (Linux, macOS, etc.) don’t use file extensions (like
.py, .png, etc.) to associate a file-type with an application.

File extensions are significant to the desktop, even if they’re ignored by the kernel. The association that a *.py filename implies a text/x-python mimetype is defined somewhere around /usr/share/mime/text/x-python.xml whose contents look roughly like:

<?xml version="1.0" encoding="utf-8"?>
<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="text/x-python">
  <comment>Python script</comment>
  <comment xml:lang="zh-Hant-TW">Python 指令稿</comment>
  <comment xml:lang="zh-Hans-CN">Python 脚本</comment>
  <-- a load more translations --/>
  <sub-class-of type="application/x-executable"/>
  <sub-class-of type="text/plain"/>
  <glob pattern="*.py" weight="60"/>
  <glob pattern="*.pyx" weight="60"/>
  <glob pattern="*.wsgi" weight="60"/>
</mime-type>

But in the absence of a file extension, the desktop respects shebangs. And the desktop knowing that the file it has is a Python file doesn’t do it any good if it still thinks that the way to open them is to run them with /bin/sh.

8

MirkoK >
Unix and its
descendants (Linux, macOS, etc.) don’t use file extensions (like
.py, .png, etc.) to associate a file-type with an application.

Dear MirkoK,

I have a vague recollection of how the Macintosh actually used a four character word in the Resource fork for how to determine which program a file belonged to. (Long time ago now. Macintosh SE era.)

And, much more recently I had a problem on my Linux box getting Python and Pingus files to open with the correct program. I think I have that problem worked out now.

Not to mention that I am now a much happier camper now that I have that hash bang and the permissions ironed out and I can make the scripts run as expected.

I intend to continue doing most of my ‘work’ on this Windoze 7 box. But, if my grandsons want to try to learn computer programming at least I have a ‘safe place’ to turn them loose with it.

Thanks again, Josh.

| MirkoK
October 1 |

  • | - |

The shebang, shell-bang or hash-bang is a line at the beginning of
an executable text file (ie. a script) which tells Unix and
Unix-like operating systems how to execute the file. Unix and its
descendants (Linux, macOS, etc.) don’t use file extensions (like
.py, .png, etc.) to associate a file-type with an application.

Since there are many scripting languages, the OS needs a way to know
with which programming language interpreter that file should be
executed.

If a file “program.py” contains the hash-bang “#!/usr/bin/python”
then the operating system (the kernel) runs “/usr/bin/python
program.py”. The same is true if the program is simply called
“program” (without an extension).

Without the hash-bang, the kernel runs the file with the default
interpreter “/bin/sh” which is an entirely different scripting
language interpreter for shell scripts.

You’ve said that your Linux system is “Linux Mint 20.3”. What would
be more useful is to know the file-manager which you use? Nautilus?

I’m on Linux Mint 22.2 and am not sure if there are any difference.
On LM 22.2 Nautilus isn’t well configured to run Python scripts
directly, you have to setup this yourself:

  1. Go to “$HOME/.local/share/applications/” where “$HOME” is your
    user directory (like “/home/josh”) and create a file
    “python3.desktop” with the following content:
[Desktop Entry]
Version=1.0
Name=Python 3
Comment=Run with Python 3
Keywords=programming;code;development;python;
Exec=python3 %F
Icon=python
Terminal=true
Type=Application
StartupNotify=true
Categories=GTK;GNOME;Development;
MimeType=text/x-python;application/x-python;

  1. Go back to your file-manager, right-click on some Python script
    and choose “Open with”.

  2. Find the just created “Python 3” entry. If it is not there, log
    out and login again.

  3. Select that “Python 3” entry. At the bottom of the window, you
    should see a checkbox (switch) “Always use for this file type” and
    below that the file-type “Python-3-Script”. Enable this
    checkbox/switch and click “Open”.

After this, double-clicking a Python3 Script should always run the
script directly instead of opening it in a text-editor or ask you,
what to do.