Just now I set a python script to be executable and added a "hashbang" line to indicate its target program (#!/usr/bin/env python3). As a result it lost the filetype icon I had previously set for python script files.
The thing is that checking the mimetype using "file -i" showed that script files with and without the python icon showed the same one : "text/x-python". As such they /should/ have shown the same icon ...
A few googles later I came across this command "xdg-mime query filetype" which showed a different mimetype (a result which turned out the one I needed to use in a icon-for-mimetype .xml file)
The question is: what is the purposes of "file -i" and "xdg-mime query filetype" returning different results ? Or, in other words: what are they aimed at ?
file is for the underlying operating system. xdg is for the graphical interface that's been bolted on top. If you want to work with the graphical stuff, use the tools that use the same libraries the window manager is using.
You seem to have a concept of the graphical desktop and OS as one monolithic entity. It's not. The graphical components are entirely separate from the OS, written by different people at different times, in many cases aimed originally at entirely different operating systems.
Just as on other systems you can choose which word processor or web browser to run, on a Unix system you can choose which graphical environment to run (or indeed choose to have none at all).
So, how do I know which programs belong to the same group ? Does a program tell me when I ask it for it ? Can I ask the "window manager" for them ? If so, how ?
Not really.
It just a question to why two programs return a mimetype, but not always the same value. Your explanation does give a reason - and in the direction I suspected no less. :-)
Look at where they got installed from - xdg-mime (in Debian at least) comes from xdg-utils which are "desktop integration utilities from freedesktop.org", while file is in the file package, "Recognize the type of data in a file using "magic" numbers". Only one of those talks about a desktop, which is your clue.
There is very little documentation on this stuff beyond the individual program level, because writing documentation isn't fun compared with programming. Remember how much the authors have been paid for all this stuff (nothing).
:-) All I did was to copy the contents of a NOOBS zip to a micro-sd card and than let its do its thing. In other words, I didn't install anything.
I'm afraid that I currently have very little-to-no knowledge as to how I should do such a track-back (to the package). :-\ (Linux newbie with a DOS/Windows programming background).
:-) Yup.
Remember how much the authors have been paid for all this stuff (nothing).
But ... but ... I /need/ it ! Couldn't they have thought of that ! :-p
As can be seen, this R-Pi 3B+ running a recent Raspbian (via NOOBS) does NOT show differences.
pi@rpi3bplus-1:~$ apropos mime gvfs-mime (1) - (unknown subject) openssl-smime (1ssl) - S/MIME utility smime (1ssl) - S/MIME utility update-desktop-database (1) - Build cache database of MIME types handled by desktop files update-mime (8) - create or update MIME information update-mime-database (1) - a program to build the Shared MIME-Info database cache xdg-mime (1) - command line tool for querying information about file type handling an... pi@rpi3bplus-1:~$
pi@rpi3bplus-1:~$ cat /etc/mailcap ############################################################################### # # MIME media types and programs that process those types # # Much of this file is generated automatically by the program "update-mime". # Please see the "update-mime" man page for more information. # # Users can add their own rules if they wish by creating a ".mailcap" # file in their home directory. Entries included there will take # precedence over those listed here. # ###############################################################################
############################################################################### # # User section follows: Any entries included in this section will take # precedence over those created by "update-mime". DO NOT CHANGE the # "User Section Begins" and "User Section Ends" lines, or anything outside # of this section! #
# ----- User Section Begins ----- # # ----- User Section Ends ----- #
Odd. My NOOBS (v3.2.0) installation is just a few weeks old with just a few packages added (gtk2 & 3). Though when I did that "xdg-mime query filetype" on a python script hashbanged* with "python3" it returned "text/x-python3".
*you're calling it "shebang". Is that the official name ?
Ah. "apropos" is also a command. I saw it mentioned in a post, but didn't quite understand what was ment (assumed a kind of remark). Thanks for mentioning it.
What is "mailcap", and why should I be looking in it for stuff related to mimetypes ? I would assume, from the name, it has something to do with email, but I must be wrong there ...
Regards, Rudy Wieser
P.s. Do you know if there is a tool/app available to add/change desktop icon assignments for non-app files (like the python script files) ? I've been able to do it by hand, but if there is something simpler available I'm all for it. :-)
... and you guessed where my naming came from too. :-)
One question though : Do you have any idea where the "she" in the name comes from ? (It might help me to remember that name, instead of what I guessed it was.)
On Mon, 4 Nov 2019 18:15:52 +0100, "R.Wieser" declaimed the following:
I learned "bang" for ! back in the 70s, where it was used on Xerox CP/V OS for command script lines (no bang meant it was data line).
I learned "shebang" as short for "shell bang". My mind tends to use "sharp" or "pound" for # (though technically, a "sharp" has two vertical lines and two slanting horizontals, while the "octothorpe" has slanted verticals and plain horizontals). {Hmmm, I suppose "shabang" would be an option for "sharp bang"}
Possibly the gtk# installs rewrote some of the MIME tables. pi@rpi3bplus-1:~$ dpkg-query -l gtk* Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description
+++-================================-==============-============-=============================== ii gtk-update-icon-cache 3.24.5-1+rpt2 armhf icon theme caching utility ii gtk2-engines:armhf 1:2.20.2-5 armhf theme engines for GTK+ 2.x ii gtk2-engines-clearlookspix:armhf 1:2.20.7 armhf clearlookspix theme for GTK+ 2. ii gtk2-engines-pixbuf:armhf 2.24.32-3+rpt1 armhf pixbuf-based theme for GTK+ 2.x ii gtk2-engines-pixflat:armhf 0.2 armhf PiXflat theme engine for GTK+ 2 un gtk2.0-binver-2.10.0 (no description available) un gtk3-binver-3.0.0 (no description available) pi@rpi3bplus-1:~$
(I think that says "ii" Install/Installed, "un" Unknown/Not) Only have gtk2 stuff from the looks of it, so I'd suspect gtk3 might have changed a few...
MIME => Multimedia Internet Mail Extension
The original usage was for email headers to identify what non-text content is encapsulated in email.
"mailcap" was a file identifying "mail capabilities". That is -- what program is needed to process an email containing specific MIME data.
The usage by Linux desktops is secondary -- ie: we already have a file linking MIME types to programs, can we somehow make use of that to launch files from a desktop?
Unfortunately, the only time I run a desktop is when installing a new NOOBS release. All the rest of my usage has been via SSH login to a text console.
I'd probably have to start by reading something like...
formatting link
although I don't see anything specific to the icon that would be displayed.
I do have a desktop for Debian 10 running inside VirtualBox on my Windows machine. I use XFCE (rather than some variant of LXDE/LXQT) on that, and it shows a generic "text document" for a .py file. But then, it also shows that for an executable (compiled) C program...
But the icon appears to only be used by the desktop when displaying, say, the right-click "open with" menu.
formatting link
(about halfway down) has a section of creating launchers, but for Python it would be specific to a particular script. That is, you'd have to create one for each Python script you wanted to run by just clicking on it. In my test it created a file (note: normally this would be IN the Desktop directory as it shows on the desktop itself -- but I moved it into my home directory where it show in the file manager)
That means I have both test.py (source file with just text document icon) and test.py.desktop (launcher using Python icon) in my home directory. The launcher can be moved to other locations.
There is no one-time just to change the icon of the .py files, that I can find. One could create a script that searches for *.py files and creates *.py.desktop files, putting the proper path on the Exec line, and also in Path, and the correct Name too. Though it would have to assume either "terminal=true" or assume all such files are GUI scripts.
I just connected a display to the R-Pi. Created a similar file (couldn't find a simple way to do that from the GUI -- had to use text editor). Then found I had to install xterm -- seems the "launch in terminal" doesn't find the R-Pi terminal. R-Pi is also trying to be "friendly" in that it pops up a requester when you double click asking if you want to execute or open (hmm, maybe I needed to chmod the .desktop file so it was flagged as an executable). Not sure where it found the Icon it used, it didn't look like a Python icon. But... the gist is that a /launcher/ file can be created for specific script files, and the launcher can have an icon specified.
I've found nothing equivalent to how Windows associates icons to file types (which seems to be that it uses the icon associated with the application specified in the OpenWith registry entry of the file /type/).
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com http://wlfraed.microdiversity.freeddns.org/
I do. I tend to spend quite some time googling for information. Its just that in the course of our conversation I didn't consider it to be out-of-context.
But yes, I could have thrown it into google and than ask myself which of the humongous ammount of "results" would have the actual answer. :-( Its just that asking you seemed more straight-forward.
Thanks. I see its likely a corruption of a squeezed-together "Sharp Bang" phrase. Thats something I can remember it by.
I also see that referring to it with "hash bang" is not uncommon either. :-)
Thats a good one! Alexandre posted a link to wikipedia, which suggested that its a corruption of a contraction of "Sharp Bang". I like yours better though.
Houston, we have a problem : I just stuck another SD card into the Pi (one with which I did not anything with than a first-time boot and having it install raspbian in offline mode). I create a "test.py" file with just a shebang line mentioning "python3". Here xdg-mime did return a "text/x-python3" for it ...
In other words, while either your possibility or just me having unwittingly altered more than intended sound plausible, it does seem to point to our versions of the OS not being the same ...
...
Yep, now looking thru that file makes sense. Thanks.
Not really unfortunate I would say. I tend to, onWindow, do most of my programming in a command console.
That /was/ what it did for me too. And I quickly realized that mixing text documents with them (with code snippets or other info) would make it hard to find those back. Hence my queste to change the script documents icons to something else.
Yes, I found a description for that too, using xxx.desktop files.
But in my case it is really all about being able to easily recognise the script files in a folder (or on the desktop) (regardless of if they are executable or not).
On my desktop I can rightclick -> create new -> empty file. After which I ofcourse still have to open it with a text editor to add the shebang line though ...
And that does seem to confirm we're not running the same OS ... When I do that the script is ran in something called "lxterminal" ("psutil.Process().parent().name()")
Or, when the involved registry entry does not contain a reference to the to-be-used program (in the "default" key), by using a "DefaultIcon" key. Been there, done that - several times. :-)
That might be for /this/ one. Believe me, I've been googeling for long enough to have had loads of crap dumped on me - even with rather specific keywords (which google often thinks it should replace with whatever it has handy). And it feels like that has gotten worse in the last year or so. :-\
Though, my apologies if you found my question offensive. It was not ment to be.
On Tue, 5 Nov 2019 10:03:11 +0100, "R.Wieser" declaimed the following:
Interesting... I pulled down the 3.2.1 NOOBS file on October 1, and probably spent October 2 installing it on both 3B+, the 2GB 4B, and 4GB 4B.
One 3B+ is kept on my desk, next to a Beaglebone Black -- primarily for doing testing and investigations for answering questions here (and the Beaglebone forum). Typically, whenever I boot one, I run apt-get update/upgrade cycle.
pi@rpi3bplus-1:~$ date Tue 05 Nov 2019 09:01:02 PM EST pi@rpi3bplus-1:~$ uname -a Linux rpi3bplus-1 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l GNU/Linux pi@rpi3bplus-1:~$ file * Desktop: directory Documents: directory Downloads: directory MagPi: directory Music: directory Pictures: directory Public: directory RPi-config.sh: POSIX shell script, ASCII text executable Templates: directory test1.py: Python script, ASCII text executable test1.py.desktop: ASCII text test2.py: Python script, ASCII text executable tst-js.svg: XML 1.0 document text tst-nojs.svg: XML 1.0 document text tst.png: PNG image data, 800 x 600, 8-bit/color RGB, non-interlaced tst.py: ASCII text tst.svg: XML 1.0 document text Videos: directory pi@rpi3bplus-1:~$ file -i * Desktop: inode/directory; charset=binary Documents: inode/directory; charset=binary Downloads: inode/directory; charset=binary MagPi: inode/directory; charset=binary Music: inode/directory; charset=binary Pictures: inode/directory; charset=binary Public: inode/directory; charset=binary RPi-config.sh: text/x-shellscript; charset=us-ascii Templates: inode/directory; charset=binary test1.py: text/x-python; charset=us-ascii test1.py.desktop: text/plain; charset=us-ascii test2.py: text/x-python; charset=us-ascii tst-js.svg: text/xml; charset=utf-8 tst-nojs.svg: text/xml; charset=utf-8 tst.png: image/png; charset=binary tst.py: text/plain; charset=us-ascii tst.svg: text/xml; charset=utf-8 Videos: inode/directory; charset=binary pi@rpi3bplus-1:~$ ls Desktop MagPi Public test1.py tst-js.svg tst.py Documents Music RPi-config.sh test1.py.desktop tst-nojs.svg tst.svg Downloads Pictures Templates test2.py tst.png Videos pi@rpi3bplus-1:~$
Even more perplexing... tst.py doesn't even ID as a Python script!
pi@rpi3bplus-1:~$ diff test1.py test2.py
0a1
2c3 < generic Python script with no shebang line
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.