Gedit default behavior

English Applications
#1

Using GNOME.

I was taking notes of some php small programs, and saved them into a file named just “notesPhp” without extension. To my surprise, when just saving all text became colored like for coding, or even compiling, and its icon changed from “text” to “executable file”! Even though file has no executable permissions.

I suspected it was because I only took notes of the code itself, thus the “<?php” part was in the very first line. Changing file’s name to “notesPhp.txt” changed everything back to normal.
But just in case I also put some gibberish at very first line.

Is this expected behavior of gedit? Or something very bad just happened to me?

#2

You are exaggerating (as so often) This is at the maximum a slight inconvenience, not something “very bad”.

Also, contrary to what the popular expressions like “make a file executable by setting the x-bit” may imply, a file is an executable one (for a particular CPU - operating system combination) by nature (or it isn’t). The so called x-bit(s) are to permit certain categories of users to actual execute it. X-bits do not change the contents of a file at all and thus have no saying about if the can be executed or not.
You can set an x-bit for every file you want (when are allowed to change permission bits by other permission bits higher up in the directory tree). But trying then to execute a letter to your grandfather composed in LibreOffice will not result in much more then an error message.

#3

While I have some extra time, I tried to remove all non-technical extras from your post to find out what your problem is.

Before I try to answer that, a few remarks.
The members here are all openSUSE users as you. Many of them try to help their fellow openSUSE users in their spare time. For this to happen as efficient as possible, a clear and precise description of problems is needed. Adding all sorts of sentiments, etc. will probably shy people away from your thread even before they have read it to completion.

A good problem description has three parts:

  • what did you do;
  • what did you expect to happen;
  • what happened instead.

No need to present this exactly in this sequence and in a bullet list form, but when one or more of those elements are not presented, helping becomes difficult. Again people finding such incomplete problem descriptions might turn away from it, going for a more promising thread and /or a beer.

Now from what I can understand you try to address.

You are using a text editor designed for use in a GUI and that editor has basically the feature for “context sensitive editing”. Which means that when the editor thinks it understands what kind of text it is editing, it uses colouring etc. to highlight the construction of that particular programming language. This to help the user to see e.g. errors in unclosed constructions (opening but no belonging closing ] and similar) and other constructs, all depending on the language. This is all to help the user and does not change anything to the contents of the file itself. The user edits and the editor tries to help.

As this is dependent on the (programming) language in the file, the editor tries to find out at file opening what that language might be. This is a heuristic process (try and error). I am not a Gnome nor a gedit user, but in general the process is that first thing that is looked at is the suffix of the file name. This is a left-over from the Extension field that was part of MS-DOS file systems. A field of three upper case ASCII characters that was attached as meta data to every file defined in a directory. In Unix/Linux file systems it is not a separate field, but it is imitated by adding suffixes in the file names. There is a general consensus about what a lot of these suffixes mean. But it is by no way standardised, double occupations exist and everybody can add to this what he wants (even by adding suffixes to already suffixed names).

Thus, as you found out, you can change file names to have suffixes at will.

Nevertheless, in a GUI environment programs will assume combinations of certain suffixes with certain types of contents. In KDE you can even change/configure them as “file name associations”.

And I have no doubt Gnu/gedit will start doing that. And yes, whith the suffix .text, it will then handle the file as neutral text without any context highlighting.

When there is no suffix, gedit will then apparently try to determine the type of contents by looking into (the beginning of the) file. Your file started with <?php. The (not so intelligent, because I would think the same) conclusion is then that it most probably is a PHP language file and it then does PHP contents highlighting.
It does so to help you, not to scare you!

And yes, PHP is a language that is written with the goal to execute such a PHP program (or part of it) in the end.
While most often PHP perograms are executed by the HTTP server (like Apache) when needed, you can execute a PHP program on it’s own also. Like every scripting language.
So showing an icon representing something that can be executed (or is a programing language) looks a good action te me.

As an afterword.
People here not only try to help solving problems directly, but also try to help others in improving their problem solving skills. So they give hints on how to tackle problems. Which mostly involves following precise sequences of steps of possible causes until they prove being wrong trials and then following the next part of the path to the solution.

It is a variant on the old one “do not give a poor man a fish to eat, but give him a net to go fishing”.

This is tried with the above and also in another thread you have running at this very time.

#4

Thanks sir, and apologies. I will try to work on all of that.

So if I give a .txt or LibreOffice file the x bit and then try to run them I’ll just get an error; they’re simply not executable files.

Sorry for getting this slightly off-topic, but perhaps this is a bit related as well. I have worked with FAT32/NTFS external disks and Samba shares as well, and always noticed some things: these “drives” always give x bit to all files, at least for the owner. I already read this is due to Windows’s “archive bit” being mapped for POSIX environments.
So this fact is not a security treat neither? And anyway, is this “archive bit” really useful? Couldn’t one just remove it?

Thanks very much again.

#5

[quote=“F_style,post:4,topic:129634”]

So if I give a .txt or LibreOffice file the x bit and then try to run them I’ll just get an error; they’re simply not executable files.
For the .txt file it would depend on what is really in it. You can test these things easily yourself. Why are you trying to shove off all that basic things unto others? Here is a test:

henk@boven:~/test> ls -l hurray.text 
-rwxr--r-- 1 henk wij 26 12 jan 21:09 hurray.text
henk@boven:~/test> cat hurray.text 
This is just a text file.
henk@boven:~/test> ./hurray.text 
./hurray.text: regel 1: This: opdracht niet gevonden
henk@boven:~/test>

And for a .odt file t he same. What would you expect else? Some magic? Test it yourself!

They are of course only fakes because the Unix/Linux permission bits aren’t on non-Linux file systems. And those faked bits are set using options at mount. I doubt the Windows archive bit has anything to do with it.
See

man 8 mount

in the fat and other applicable) section(s).
And then you will understand that you can avoid them being set by using an appropriate fmask value.

Also the usage of the file system independent option noexec is not a bad idea, even on Linux file sytems you connect, but have been on other systems.