4

I have a bash script that runs to create emails. I do not wish to modify it for now since it is pretty critical in my current project. One command does not run the same on the operational machine and on mine:

xdg-mime query filetype <file>

It's running on a simple us-ascii encoded text file (with a custome file extension). The thing is, on the operational machine where the script works, it returns plain/text (expected behavior). Debug mode of xdg-mime shows that it is actually running a file -i command on the operational machine. On my machine though, it returns application/octet-stream and runs a gnomevfs-info command. It appears to have something to do with the desktop environment (both machines are running on gnome).

Is there a way to force xdg-mime to run file -i? Or to make gnomevfs-info return the correct mime type ? I tried unsetting GNOME_DESKTOP_SESSION_ID but here is what xdg-mime does:

detectDE()
{
    if [ x"$KDE_FULL_SESSION" = x"true" ]; then DE=kde;
    elif [ x"$GNOME_DESKTOP_SESSION_ID" != x"" ]; then DE=gnome;
    elif `dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.gnome.SessionManager > /dev/null 2>&1` ; then DE=gnome;
    elif xprop -root _DT_SAVE_MODE 2> /dev/null | grep ' = \"xfce4\"$' >/dev/null 2>&1; then DE=xfce;
    fi
}

The third elif is the one that leads to xdg-mime using gnomevfs-info over file -i, because the command returns 0 and DE is set to gnome. I've tried looking at man pages, but that command dbus-send --print-reply --dest=org.freedesktop.DBus /org/freedesktop/DBus org.freedesktop.DBus.GetNameOwner string:org.gnome.SessionManager > /dev/null 2>&1 is jibberish to me.

  • Does gnomevfs-info produce an expected result when run in a "slow MIME mode" (`gnomevfs-info --slow-mime my.file) ? – zeppelin Apr 11 '17 at 20:24
2
+50

If you know your custom text file extension(s) in advance, you can simply register a new MIME entry for them, as a workaround.

E.g. if your files have an extension of ".list":

Prepare the descriptor file: zeppelin-list.xml

<?xml version="1.0"?>
<mime-info xmlns='http://www.freedesktop.org/standards/shared-mime-info'>
  <mime-type type="text/plain">
    <comment>List file type</comment>
    <glob pattern="*.list"/>
  </mime-type>
</mime-info>

Register a new MIME entry:

%xdg-mime install zeppelin-list.xml

Query:

%xdg-mime query filetype my.list
text/plain
  • This answers the question exactly, providing a work-around without changing the command. Thank you ! – Valentin B. Apr 18 '17 at 7:26
  • After implementing it, I can confirm that this solution does work like intended ! – Valentin B. Jun 23 '17 at 12:43
  • xdg-mime on my Mint system was incorrectly identifying PGP keys as Apple Keynote files (file gave correct results). This helped me to fix it, many thanks! – Wes Toleman Sep 22 '18 at 2:50
1

xdg-mime is a core component of your desktop environment and you shouldn’t try to change its behavior. I understand your fears to break your mission-critical script, but if it produces different results on the operational machine and on the test machine, it is already broken and it has to be fixed. Basically,

file -b --mime-type <file>

is a drop-in replacement of

xdg-mime query filetype <file>

and changing it should be painless, especially if your preferred behavior is the output of file -i.

The xdg-* commands depend by design on the desktop environment you are running in (remember that the prefix stands for X Desktop Group) and, in principle, they shouldn’t be used at all in scripts not meant for user interaction.

If you want exactly the same behavior on all systems, use commands like file, which are meant to behave always in the same way (OK, they might be small version differences, but that is inevitable).

If you want the “most sensible” behavior for each system, use those wrapper commands like xdg-mime and be prepared to adapt to their idea of “most sensible” on each system.

The wrong thing to do is to try to change each environment so that the environment-dependent programs behave the same.

  • While your answer is probably the "most correct" in regards to what should be done, it does not answer the original request of not changing the script. Nonetheless you provided very interesting insight and I would like to formally thank you for your input (of course I upvoted your answer). Cheers ! – Valentin B. Apr 18 '17 at 7:29

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.