KDE Filemanager (konqueror) displaying php files as html doctype. Why?

English Applications
1

Hello,
I know this might be a ‘little thing’ to some, but This is Bugging me Huge:

*‘New’ observations since I originally posted at KDE, where as usual, No one has even viewed the post.

  • KDE > Konqueror AS Root > Navigate to ~/MyDocs/Inet Publishing/ (directory with websites in it), Konqueror displays the *.php files with the default ‘PHP’ mimetype iconhttp://landisreed.com/images/application-x-php.png ( screencap )](http://landisreed.com/images/screens/KDE4.12/Konqueror_displaying-php-files-as-html_03.03.14-04.png) and open them with Kate and Not with kwrite as it would if the document was an HTML file.
  • Also, Dolphine (wich I dislike), as User (not root) shows the correct mimetype icon and associated app (kate) for php

I’m hopping that my luck with openSuSE holds true with this problem.

Here is the long winded version of my ‘problem’
For no reason I can find, Konqueror is displaying my *.php files using mimetype HTML.
Until today, I had it set up in File Associations, if I click on a PHP file, Kate would open and the ‘icon’ would be my PHP mimetype and HTML files would not only have an HTML mimetype icon, but would open in KWrite.

http://landisreed.com/images/php128.pngImage of dir using HTML for PHP](http://landisreed.com/images/screens/KDE4.12/Konqueror_displaying-php-files-as-html_03.03.14-01.png)
http://landisreed.com/images/html128.pngImage of dir using proper PHP mimetype icon](http://landisreed.com/images/screens/KDE4.12/Konqueror_displaying-php-files-as-html_03.03.14-02.png)
*note: i created the icons in gimp, but am certain they have nothing to do with this issue. again, this is an ‘new issue’ for me and i’ve been using these icons for a very long time.

Al of the sudden, but after Kate locked up and would not ‘die’ after many attempts to ‘Kill’ it. (locked while I was in Settings > Configure Kate). I was forced to power down the computer and cold start.

To make a weird thing weirder is that it is Not All Directories. Some sub-directories of the same project display some PHP files using the mimetype icon = php and open in Kate and Some are displaying php files with mimetype icon HTML and opening in KWrite.
All the files with .php extensions Are php, at a minimum contain at least one php include statement. Both the files display HTML or PHP icons.

I’ve noticed this little issue, when I started creating .mediawiki documents. it seemed Konqueror would interpret them as ‘.C’ code files or ‘normal’ and Not mediawiki mimetypes. To ‘fool’ konqueror or really ‘the system’ I would put at the top of the document, '< ! DocType mediawiki > (NO spaces, obviously)… So, what I’m saying is that it seems ‘the system’ or konqueror is actually Reading the contents of the file instead of the file Extension…
http://landisreed.com/images/resized_mimetype-mediawiki.png What do you think?](http://landisreed.com/images/screens/KDE4.12/Konqueror_displaying-php-files-as-html_03.03.14-03.png)

Any Ideas Please?
Reed.

– edit –
one more thing. on my web servers, all the mimetypes seem to be right, but i also have x-app set in file associations that might be different from the ‘text’ setting.

2

So, this seems to be confined to Konqueror and Only for the last few days… ???

Thanks,
Reed.

3

There is a general problem of recognizing what the contents of a file represent. Only “intelligent guesses” can be made. IMHO the command

file

is the one doing it the best.

Dolphin (not: Dolphine) is not doing much file content testing I am afraid. It uses (at least in many cases) the suffix of the file name instead of looking inside for magic numbers. Example:

henk@boven:~/test/bestanden> ls -l verf*
-rw-r--r-- 1 henk wij 157943 10 mei  2013 verf.gif
-rw-r--r-- 1 henk wij 157943 10 mei  2013 verf.jpeg
henk@boven:~/test/bestanden> diff verf*
henk@boven:~/test/bestanden> file verf*
verf.gif:  JPEG image data, JFIF standard 1.01
verf.jpeg: JPEG image data, JFIF standard 1.01
henk@boven:~/test/bestanden>

In other words, two files are exactly the same and the file command detects that it is a JPEG image.

Dolphin and Konqureor both think that the one is a GIF and the other is a JPEG. Not very clever.

My conclusion: it is quite possible that both Dolphin and Konquerror have a different algorithm for deciding what the contents of a file represents and that both are not very good at it and that both act different from each other.
Maybe both should use the file command internaly instead of their own mechanism :wink:

BTW, for the case of PHP vs. HTML, the only way to be sure about the one or the other would of course be to read the whole file to see if there is any <?php string inside it. That wouild make it a very resource consuming process.

4

Thank You very much for your input.
I would like the file manager to look at prefix Only.
konqueror if definitely looking in the files plus something else, because a file Name.php and it’s backup made during editing, Name.php~ have different ‘mimetype icons’ yet the same content. Also, there is a ‘File Association’ specifically for ‘bak’ files called ‘Trash’ and this is being ignored now too.

BTW, it is better now, but I don’t know why.
I removed text association for php and added x-php, turned of (disabled) konqueror Extension ‘Directory Filter’ and disabled Konqueror > Settings > File Management > General > Preview > HTML…
Don’t know what changed, but… again, some what better now.

Again, Thank you.
Reed

p.s. I have a grep search going on .kde4 and .local going. looking for ‘mimetype’ entries.

5

FYI: found that there are .xml files that define mimetype extensions, the icon to use, but not the application in:
~/.local/share/mime/[text]/php.xml (for example). One for each file type i’ve added, which contains the following.


<?xml version="1.0" encoding="utf-8"?>
<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="text/x-php">
  <!--Created automatically by update-mime-database. DO NOT EDIT!-->
  <comment>PHP Server Side 'Personal Home Page' files</comment>
  <icon name="/usr/share/icons/php64.png"/>
  <glob-deleteall/>
  <glob pattern="*.PHP*"/>
  <glob pattern="*.php"/>
  <glob pattern="*.php.*"/>
  <glob pattern="*.php3*"/>
  <glob pattern="*.php4*"/>
  <glob pattern="*.php5*"/>
  <glob pattern="*.phps*"/>
  <glob pattern="*.php~"/>
</mime-type>


<?xml version="1.0" encoding="utf-8"?>
<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="text/mediawiki">
  <!--Created automatically by update-mime-database. DO NOT EDIT!-->
  <comment>MediaWiki - Wiki Markup pseudo HTML</comment>
  <icon name="/usr/share/icons/mimetype-mediawiki.png"/>
  <glob-deleteall/>
  <glob pattern="*.MediaWiki"/>
  <glob pattern="*.MediaWiki.*"/>
  <glob pattern="*.mediawiki"/>
  <glob pattern="*.mediawiki.*"/>
</mime-type>


<?xml version="1.0" encoding="utf-8"?>
<mime-type xmlns="http://www.freedesktop.org/standards/shared-mime-info" type="text/kateproject">
  <!--Created automatically by update-mime-database. DO NOT EDIT!-->
  <comment>Kate Editor Project File</comment>
  <icon name="/usr/share/icons/text-x-katefilelist.png"/>
  <glob-deleteall/>
  <glob pattern="*.kateproject"/>
  <glob pattern="*.kateproject.*"/>
  <glob pattern=".kateproject"/>
  <glob pattern=".kateproject~"/>
</mime-type>

many others, but again, only for extensions i’ve added.

and of course the files that kept getting changed that mozilla Firefox defers to:
~/.local/share/applications/mime.cache, mimeinfo.cache and mimeapps.list, but these only launch the associated application. My issue seems to be with the interpretation of the file in determining the mimetype… Hmmmm
*note. the mimetype cache file points to /var/cache/gio-2.0/gnome-defaults.list file. this one busted my chops a long time, messing with FF and default application for pdf… inkscape kept being added as the viewer.

Still looking…
Reed

6

Hm, I am not sure you are on the correct way in adding MIME types of your own invention.

MIME types are used on the internet to indicate the type of data that a file contains. PHP files are not normaly send over the internet. The resulting HTML is, and then of course have the MIME type text/html.

The list of MIME types is registered by IANA and adding things to your local list is of course entirely local to your environment.

And I do not think the icons used by file browsers are to be termed as MIME type icons. As said MIME types are on the internet. On a computer there of course files with contents that correspond with MIME types when send over the internet, but are many more other file content types that do not have any corresponding MIME type.

7

Yes, you’re right, i know.

I am talking about File Type / Application Association within KDE (openSuSE).
I just call it ‘mimetype’ as that is what seems to get my point across when talking about association.

I’m not sure what else to call the overall idea…

I am actually talking about the association between the File.Ext, the ‘file manager’, the icon associated with the file type and the Application that my system / file manager uses to open a given file type (file.ext)… : (

Thank You again,
Reed.

8

Well, it is called Filetype Association in KDE (maybe other desktops call it diferent). In fact it is a Filename Suffix Association because, as we have seen, it only looks to the suffix of a file name.

Apparently it tries to emulate the MS-DOS file name extentions :frowning:

9

And there lies the rub… Konqueror is Not looking at the ‘File Association Suffix’ only. If it was, I would not be having a problem. It seems Konqueror is ‘Reading’ the document, using something called ‘magicdata’, i guess.

I wish it would ONLY read the extension. I hate when the ‘tools’ think they are smarter than they really are.

Thanks,
Reed

10

On 03/04/2014 07:16 PM, TyReed pecked at the keyboard and wrote:
> hcvv;2628503 Wrote:
>> … In fact it is a Filename Suffix Association because, as we have
>> seen, it only looks to the suffix of a file name.
>> …
> And there lies the rub… Konqueror is Not looking at the ‘File
> Association Suffix’ only. If it was, I would not be having a problem. It
> seems Konqueror is ‘Reading’ the document, using something called
> ‘magicdata’, i guess.
>
> I wish it would ONLY read the extension. I hate when the ‘tools’ think
> they are smarter than they really are.
>
> Thanks,
> Reed
>
>
You need to stop thinking in MS Windows ways and become assimilated in
the linux way of doing things.

11

In fact I am of the opposite opinion. The suffix does say nothing (as you can see from my JPEG/GIF example). It is the contents that may say something about what the contents is. And the “file” comand is very good at it. I do not know if Konqueror uses the same database as “file” *), but, as I said earlier", it would be a good idea (why reinventing).

The only negative aspect I see is that “file” is only called by a user when (s)he wants to know about the contents. Where a file manager tends to show icons based on the contents all the time and thus must determine all the contents of all the files every time one changes view to another directory. Resourses consuming.

And adding to your last remark:
IMHO Dolphin is suggesting it shows you based about the contents were it doesn’t. I hate tools that suggest you that they can do things, but in fact fool you rotfl!

*) BTW, did you try to use “file” on your files to see if it knows better then Konqueror?

12

I’ve been using Linux since 1996. If I seem ‘confused’ about the way linux handles extensions (file types), please explain. The way I see it, a file Extension Is, or should be the determining factor in file type identification, yes? Then using that relationship, ‘lookup’ in a file, the application associated with file extension X…
I do know that I can created / name a file WithOut an extension and it is still known to the file system as X file type, so i guess there is more to it than just the extension, eh.
****. I’ve now talked myself into believing It’s always been that way… There is rarely extensions in Linux.
Case in point, a ‘.sh’, Shell Script file is Only a shell script because I declare it to be on the first line of the file: " #!/bin/bash " and does Not require the .sh ‘file extension’…
OK, I’m getting there… I didn’t think of it like that… And No, I’m not thinking ‘windows’, never do. Just didn’t think. ; )

That Doesn’t explain why, as my current user, konqueror may or may not present a file as PHP or HTML.
For instance a file pair, the File.php and it’s current backup File.php~, both having the same head and <!DocType HTML> statement as the first line in the file, may present the backup~ file as HTML instead of PHP or it may not?? I can’t see a consistant reason why some PHP files might be identified as HTML (both the icon representation and associated application).
Again, I have file association set that php is opened by Kate and html by kwrite. So, I know it’s both icon and application being changed by ‘system’… Why?

now i’m just rambling… sorry.

Thanks,
Reed

13

Some but not all files have the Linux magic number. This is a signature string at the beginning of the fie hat defines the type. So take a program source file that is normally text but we would like to treat it and open it in the appropriate editor so the the editor know what type of programming language it is so it can format to the rules of that language. For such a file there is no header string that tells us the program language it is just a text file after all. but we would like to treat it as say a c source file so we add a .c to the end. If we wanted to eat it as a header file we add a .h suffix. So though magic headers are nice and a lot of structured files us some form they can not address all situations. It really is not magic you know. There is not some form of meta data attached to each file to uniquely identify the type.

Just to see the complexity of modern file types look at Configure Desktop- File Association which allow you to associate an extension to an app. in KDE.

14

Yes. If i run # file ColorCodes.php~ , for example. A ‘php’ file being displayed as html, while it’s parent (the file this ‘backup’ is derived from) is displayed as php (icon and associated application):


# file ColorCodes.php~
ColorCodes.php~: HTML document, UTF-8 Unicode text

the ‘parent’ or original file,


# file ColorCodes.php
ColorCodes.php: HTML document, UTF-8 Unicode text, with very long lines

same ‘encoding’, but displayed with different ‘mimetype’ icon and application association.

Thanks,
Reed.

15

fyi… here is the file command run on a php file that begins with <?php versus <!DocTyp…


# file css_snippets.php
css_snippets.php: PHP script, ASCII text, with very long lines

both files are basically ‘html’. they are html documents with php includes and very few other scripts.
This all started because, when I’m going quickly, I just click on the file I want to edit and assume it will open in the editor (kate) i want and then next thing I know, kwrite is opening… bummer… wait for load, close, file manager, right click, open in kate… what a pain.

: )
Reed.

16

On 2014-03-05 10:06, hcvv wrote:
>
> TyReed;2628663 Wrote:
>> And there lies the rub… Konqueror is Not looking at the ‘File
>> Association Suffix’ only. If it was, I would not be having a problem. It
>> seems Konqueror is ‘Reading’ the document, using something called
>> ‘magicdata’, i guess.
>>
>> I wish it would ONLY read the extension. I hate when the ‘tools’ think
>> they are smarter than they really are.

> In fact I am of the opposite opinion. The suffix does say nothing (as
> you can see from my JPEG/GIF example). It is the contents that may say
> something about what the contents is. And the “file” comand is very good
> at it. I do not know if Konqueror uses the same database as “file” *),
> but, as I said earlier", it would be a good idea (why reinventing).

It doesn’t really matter what /we/ think - it is up to what the
developers of each application think :wink:

I just did a quick test with Dolphin and some files (13.1).

An empty file with the .pdf “extension” is identified as a pdf file.
A text file with the .pdf “extension” is identified as a pdf file.

Both are clearly incorrect. But:

A pdf file without extension is correctly identified as a pdf file.
A libre office spreadsheet file without extension (or suffix), it is
correctly identified as a LO file.

Nautilus does exactly the same.

Konqueror (kde4) appears to do the same.

What they are doing is looking at the extension if it exists, and then
treating the file accordingly. However, if the extension does not exist,
then they use the slower method of looking at the contents to decide.

It looks quite reasonable to me.

I remember seeing, time ago, some browser where you could configure what
method to use, extension or ‘magic’.

However, konqueror from KDE 3 acts different! It looks inside and
decides, ignoring extensions.

By the way, in verbose mode, Nautilus has a column named “MIME type”.
I’m not saying that this is either correct or incorrect, I’m only saying
that it does :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

17

On 2014-03-06 02:36, TyReed wrote:

> and then next thing I know, kwrite is opening… bummer… wait for load,
> close, file manager, right click, open in kate… what a pain.

You can probably open it in kate without waiting for kwrite to close :slight_smile:

–
Cheers / Saludos,

Carlos E. R.
(from 13.1 x86_64 “Bottle” at Telcontar)

18

I do not know if you want to walk this way any more steps (after all, it deviates from your original problem more and more), but next I would use

diff

on those files to see if they are realy exactly the same, because why is the one with “very long lines” and the other not?

Then I would like to see the contents, because we only have your word that it is PHP. After all, even a file that contains conforming HTML only, can be used as PHP, because we all know that the PHP interpreter will just copy HTML input to it’s output and thus it is as well as PHP as it is HTML.

And of coure, when we know more about these files contents, we can try to interprete the “file” database (I assume you have read the man pagee and thus have a basic knowledge on how it works and where it’s “database” with magic numbers, etc. is).

That is of course all very interesting, but it will not help you in solving your day to day problem.
The only thing I wanted t to introduce you fom the beginning is that:

  • Unix/Linux has no concept of “extensions” (in the way they come to us from MS-DOS);
  • from the very beginning of UNIX, some tools/programs have used suffixes (starting with a dot) to add to file names to inform themselves (the tools) and their users about the contents (think of the .Z suffix added to a file compressed with “compress”);
  • there is no certainty whatsoever that such a suffix is “telling the truth”;
  • there is no defined way in Unix/Linux to tell how the contents of a file may be interpreted with the best chance of success (maybe a flaw in the design of Unix);
  • the habit of using suffixes to tell what most probably the contents of a file means has spread through many applications and also users (I do use suffixes of my own design in cases, llike when I alter a file in /etc, I firts make a copy of the original, adding the siffix “.orig”, but of course “-orig” works as good);
  • in KDE (and I guess in more DEs), you can configure an application to be connected to a file name pattern (mostly used ro denote suffixes I assume) (File Associations), E.g. in my KDE *.php, *.php3, … are associated to KWrite and when not found then LibreOffice Writer , etc. and *.htm *.html are asociated with Firefix theh Konqueror, then Kwrite, etc. Easy enough to change to your liking.

Your real complaint is not about starting the wrong application, but bout the icon. So it is something about human interaction. That is of course very personal. I for myself use Details view in Dolphin (and similar in Konqueror) where the icons are very minimal. I am very well able to read those suffixes and do not need an icon. But I repeat, that is very personal.

Again, I only wanted to introduce you to a subject that is rather complicated and not easy to solve definitely and certainly not to the liking of everybody :wink: