First of all, this is my first post, so I hope I'm following the proper guidelines and am stating the issue clearly.

I'm personally not too Linux-savvy, only using it to do some code on occasion, though I do most of that in Windows. To be more precise, I've run into the following issue while running Manjaro on a virtual machine.

Today, while using the PyQt5 library, I noticed a small annoyance. In general, Linux assumes all files ending with .py are python scripts. However, if I happen to have some code which imports PyQt AND has any sort of { brackets, then Manjaro immediately lists it as a "Qt Markup Language" file. Here's some dummy code that replicates the issue saved as "test.py"

#!/usr/bin/env python3
from PyQt5 import QtWidgets
some_dict = {}

Adding the shebang didn't do much. If I erase either the second OR the third line, the OS says its file type is "Python script", but if I keep both, then it infers it as a QML (Qt Markup Language file), because of the brackets (I assume). This also happens if I format strings with f'' or with .format(), so I know it's not just a dictionary issue.

This has no impact whatsoever on my code, but I still find it mildly annoying and I'd like to know how:

  1. Linux infers file types since it doesn't care much for extentions
  2. How I can change this if there's a quick solution

Like I said, this is no big deal, especially since I do my editing using the terminal, but it bothers me and makes me curious. Thanks for your help and have a great day!

UPDATE 1: I browsed the wiki and found this: https://wiki.archlinux.org/index.php/XDG_MIME_Applications#mimeapps.list

I can successfully replicate their example, but so far am having issues adapting this to .py files. Even after I set the new rules, it seems to still browse the configuration files in /usr/share/mime.

UPDATE 2: I'm still unable to write rules that successfully override what's considered a QML when the extention is .py. However, if I replace the import statement with

import PyQt5.QtWidgets as QtWidgets

then I'm able to "trick" the rules and it now successfully labels it as a "Python Script file". The "issue" itself wasn't solved, but I actually learned a lot from this.

  • 1
    In general, Linux assumes all files ending with .py are python scripts - no, it doesn't. OS says its file type is "Python script" - how are you checking it? Commented Apr 26, 2020 at 17:43
  • Oh it's just stated in the file manager. Like I said, it's no big deal and I only noticed when I was visually browsing the folder and noticed the different icons and such Commented Apr 26, 2020 at 17:52
  • What file manager are you using? Commented Apr 26, 2020 at 17:52
  • Oops forgot to specify about. I'm using thunar, which came with my Manjaro (xfce) installation. I guess it's something to do with that then? Commented Apr 26, 2020 at 17:55
  • I cannot reproduce with Thunar 1.6.10 - I go to Properties and it says Kind: Python script. Commented Apr 26, 2020 at 17:57

1 Answer 1


In general, Linux assumes all files ending with .py are python scripts

Linux as the kernel doesn't really care about file endings. It only checks whether a file starts with a shebang or some magic number such as 0x7F followed by ELF(45 4c 46) for ELF.

I can reproduce this issue with 1.8.14 (Xfce 4.12) on Slackware 64 -current. Thunar does not infer file types by itself but uses a MIME database that other programs use as well:

$ grep mime /proc/$(ps -C thunar -o pid:1=)/maps
7f2c3a709000-7f2c3a730000 r--s 00000000 08:01 1055508                    /usr/share/mime/mime.cache

You can use xdg-mime query filetype or a Perl program called mimetype from perl-file-mimeinfo to check a MIME type for a given file:

$ mimetype test.py
test.py: text/x-qml

And use -D with mimetype to check why was the given MIME type chosen:

$ mimetype -D test.py
> Data dirs are: /home/ja/.local/share, /usr/local/share, /usr/share
> Checking inode type
> Value "import Qt" at offset 3044 matches at /usr/share/mime/magic line 120
>> Value "{" at offset 3065 matches at /usr/share/mime/magic line 121
test.py: text/x-qml

As you see, in this case mimetype says that test.py is text/x-qml because it contains import Qt and curly braces. If test.py looked like that:

#!/usr/bin/env python3

from PyQt5 import QtWidgets

mimetype reports it's a Python script because even though it can find import Qt there are no curly braces:

$ mimetype -D test.py
> Data dirs are: /home/ja/.local/share, /usr/local/share, /usr/share
> Checking inode type
> Value "import Qt" at offset 3044 matches at /usr/share/mime/magic line 120
> Failed nested rules
> Checking globs for basename 'test.py'
> Checking for extension '.py'
test.py: text/x-python

What's funny, if test.py is renamed to test.pl then mimetype claims it's Perl script.

OTOH, file says it's a Python script even after renaming it:

$ file test.pl
test.py: Python script, ASCII text executable

See this answer to read about discrepancies between mimetype and file: 'file --mime-type' and 'mimetype' Commands Returning Different Results.

  • Thanks for the insight! The link doesn't seem to tell me how to fix the discrepancy, but I may have missed it. I'll do some research now that I know what the underlying issue is. I assume it's not a good idea to edit that file that's reading those values? Commented Apr 26, 2020 at 19:26
  • The link only describes why such discrepancies exist. I don't use graphical file managers, or any file manager for that matter preferring command line and mkdir/cp/mv/ls etc. and file so I have never needed to modify MIME database that programs use but I think you should feel comfortable editing them or ideally creating new files in ~ that would take precedence over them. Commented Apr 26, 2020 at 19:35
  • It's not that big a deal, and personally I tend to use the command line as well since I never do anything major and bigger projects I tend to make in windows anyway. It's just something that's really bugging me and I hate leaving issues (or non-issues even) unaddressed. If I do find the config file and find the right commands, I'll post the solution. Thank you very much for your valuable help! Commented Apr 26, 2020 at 19:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .