On 4/13/25 1:17 PM, Darrell Anderson via tde-users wrote:

uriously there is some kind of detection taking place in TDE Kate. I opened a shell script and Kate correctly selected Bash highlighting. I changed the declaration to /bin/perl. Nothing happened but when I saved the file Kate changed the highlighting to perl. Curiouser and curiouser is when I did likewise to /bin/python, Kate retained the perl highlighting. Returning the declaration to /bin/bash and saving saw Kate return the highlighting to Bash.

The existence of the metainfos files might be a clue from years ago the original developers did not have a useful or dependable detection scheme. This is alluded to in the KDE 5 documentation mentioned above.

Confusing me is my original point. Some of the files I open are obvious shell scripts with /bin/bash|sh in the declaration. If the existing TDE, nee old KDE, detection scheme uses mimetypes, something like the file command, then how does this detection fail with obvious shell scripts?

That is something I would have to look at the katepart code to begin to understand enough to offer a guess on.

I think there are probably a few issues that were addressed in Frameworks5/Plasma kate.

What I understand is you have the 2-part lookup. Extension and/or mime-type. The problem with the mime type (x-shellscript in this case) is that there has always been rough edges in KDE3/TDE handling of them internally. I don't know if this is a corner-case memory leak issue or list corruption, but I have seen the mime types get confused on a regular basis.

Not that the "wrong" mime type gets presented, but that "no" mime type is presented. This happens at least ever few months or so where when it occurs, you can go though kcontrol file-association or konqueror (rt.-click, then properties) and discover that the normal association has just disappeared. (that can be on the the individual mime-type for the file, or which group it belongs to, e.g. "application" or "text", etc.)

This isn't a permanent corruption, a log out/in restores them (or perhaps a "kbuildsycoca --noincremental" without log out/in). Granted, I have my box up and running for sometimes weeks at a time (between kernel updates) so there is a lot of chances for the corner-case to be hit.

This is where the mime type syntax highlight breaks down. I would say the extension, mime-type algorithm works correctly 95-99% of the time for me. And I too dislike always using extensions for scripts.

The disparity without an extension can be easily seen by a simple example.

1. open kate or kwrite, 2. enter a simple awk script with proper interpreter line, e.g.

#!/usr/bin/awk -f

{ print $2 }

3. save the file without extension as 'print2' (no highlighting)

4. copy/paste into new file (or save as) 'print2.awk' (highlighting)

The 'file' command has no problem identifying the file as an awk script with or without the extension:

$ file tmp/awk/print2 tmp/awk/print2: awk script, ASCII text executable

But kwrite doesn't. So there apparently is no check of the 'file' command, and without the extension, the newly saved file has no mime type other than plain text.

Now from the menu, Tools->Hightlighting->Scripts->AWK will instantly correct the the mime type seen for syntax highlighting and all is well. However, closing the file without extension and then reopening in kwrite, even using File->Open Recent, reopens with file without the previously set highlighting association.

That is despite the file-open dialog showing print2 with the shellscript icon. Somewhere there is a disconnect between the information QDir holds from iterating over the directory to produce the listing in the file-open dialog and whatever part of katepart triggers selecting the proper syntax file. But, add the .awk extension and the syntax highlight is applied just fine.

So somewhere there is a breakdown in the syntax highlight. If you find out where, maybe we can come up with a patch to fix it. If I stumble across where the breakdown is, I'll do likewise.