I recently updated my Ubuntu from 16.04 to 18.04, and one problem is the icon for the executable is the same as the one for a text file. (ArucoDetect is an executable, and others are usual text files)
In Ubuntu 16.04, the executable have it's own icon like
How can I configure Ubuntu 18.04 so the executable can have it's own special icon?
If you have problem than you can find gcc and add line -no-pie It is default executable because Ubuntu 18.04 has problem with pie that is why position independent executable. Just no pie! Than it works fine for me.
This answer exists solely of a continuation of Piggybacking off of Jens' answer of using
-no-pieas part of GCC builds...
This is a bug caused by Position Independent Executables (PIE). PIE is a security feature in modern versions of Linux that randomizes memory addresses as well as slightly changes file structures. PIE binaries are different from "standard" Linux binaries because PIE binaries have a different type - most systems (notably, file) will treat them as a Shared Library file instead of a plain-old executable binary:
$ file bin-nopie
bin-nopie: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=ee817f6d5d4f5635a981b1b837b1b0de3b16aacf, not stripped
$ file bin-pie
bin-pie: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically
linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32,
BuildID[sha1]=439fc92838d4d0981f99dd967485e5b95a5a0e7b, not stripped
Ubuntu's file browser (Nautilus) doesn't do its own filetype processing (it instead elects to use libmagic/file/etc.). As these upstream libraries are broken and are unable to detect PIE-built binaries properly, Nautilus is not able to show them as executable in the GUI. The system, therefore, elects to treat them as though they are any other shared library (that is, as a non-executable).
However, this problem can be mitigated away. A developer can compile a binary using the -no-pie option to disable PIE (although this does harm security a little bit). This will allow libmagic/file to see the binary file as an executable binary and pass that data on accordingly to Nautilus. Alternatively, a developer (or an end-user) may create a .desktop file pointing to the binary. This is considered the "preferred" workaround by the GNOME team, as it allows addition of metadata and icon files, creating an overall prettier user experience.
Open/Related Bug Reports:
This has to do with mime types and has nothing to do with whether a file is executable or not. All the scripts I use are of course executable but that doesn't change the fact that the Mime type is different.
Examples:
Busybox has the icon that is shown in the question.
$ file /bin/busybox
/bin/busybox: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, for GNU/Linux 2.6.32, BuildID[sha1]=86b86ebdeb1e423dc1672c2a7408fb83ee70eeb1, stripped
My scripts on the other hand have icons similar to:
file ~/bin/vdprocessx265.sh
/home/me/bin/vdprocessx265.sh: Bourne-Again shell script, ASCII text executable, with very long lines
As you can see, the bash script while executable is a shell script in ASCII text while busybox is an ELF executable.
using grep on /etc/mime.types makes it even more clear.
grep "exe" /etc/mime.types
application/x-executable
application/x-msdos-program com exe bat dll
grep "sh" /etc/mime.types
Users can add their own types if they wish by creating a ".mime.types"
<---Snip-->
text/x-csh csh
text/x-sh sh
There are a couple good answers to How do I change the icon for a particular file type? that should help you get the results that you want.
This question has answers that go into further detail: Where are file associations stored?
@dim I believe that you'll find that compiling with the -no-pie switch results in a different header
mimetype guesses the appropriate mime type based on the contents of the file. For ELF files (most compiled binaries and shared libraries), the header contains a field e_type which identifies its type. If it is ET_DYN, then mimetype will treat it as a shared library.
By default, gcc/ld will produce binaries which set e_type to ET_EXEC, which get detected as application/x-executable
which causes the mimetype to be guessed diferently as explained by this StackOverflow answer hence the different icon.
Sources:
Where are file associations stored?
How do I change the icon for a particular file type?
Change your application's name to ArucoDetect.appimage
.appimage but shouldn't it work without having to add that extension?
– user3667089
Jun 07 '18 at 18:37
chmod a+x again on the file the icon still doesn't change.
– user3667089
Jun 07 '18 at 21:25
-no-pie(only one dash in the front) and it solves it. Do you know whether there's any downside for compiling with this flag? – user3667089 Jan 31 '19 at 22:24-no-piethan you see an executable and you can click executable. or ./executable in terminal. // UPDATED https://i.imgur.com/SFoD5uB.png – Jens Eckervogt Jan 31 '19 at 23:07