1

I have some programs I wrote a while ago to edit a journal I've been keeping. I normally don't like to use gedit, I like to keep my vim skills up for my next "gui-less" project. I was editing one of those programs written in bash script with gedit, and even with #!/bin/bash at the top, it wouldn't show the bash syntax. all the other ones seem to be working fine. here is the problematic script.

#!/bin/bash
############################
# ok, this is going to be  #
# a remake of my first     #
# easy access log editing  #
# Program.                 #
############################

chmod 770 ~/.Secret_Files
vi ~/.Secret_Files/Log17
chmod 000 ~/.Secret_Files
sleep .5
echo 'Done'

(like my feeble attempts at documentation?)

the thing that sucks is right here, it just showed the syntax coloring in askubuntu.

Question answered, no need to add.

2 Answers2

2

I don't know how gedit handles syntax highlighting of extension-less files (there are questions about that: Can Gedit default highlighting style be set for files without an extension?), but there definitely is a plugin that handles modelines:

enter image description here

So, if you have a comment of the form in the first (or last) few lines:

# vi: ft=sh #

It will use shell syntax highlighting, and with ft=perl, Perl syntax highlighting and so on.

muru
  • 193,181
  • 53
  • 473
  • 722
0

Generality Explained: If the first two bytes in a file are the 16bit value 2321 (hex), the file is a script to be handed to another executable in argv[1]. Argv[0] is the executable name.

Unlike M$-DOS, Windows, etc., Unix type O/Ss do not care about file extentions. The fact that the last 3 bytes in a file name happen to be ".sh" are useless to the kernel. What counts are the mode bits and the first 16bit integer at the first value in the file itself.the mode bits tell that an executable is present, regardless of its name structure. These used to be known as "magic numbers" and were defined in sys/magic.h For our example, if the first value is 2321, it means this is an interpreted file. It is expected that the next 16bit value will be 202f. If so, the string from position 2 in the file until the following 20, will better be a pathname to a real binary, or some other magic number. The rest of the line (greatly simplified) are arguments passed to the interpreter. Some messy code assigns these to argv[0], argv[1], etc. This is basically how the kernel can 'execute' an arbitrary script without needing to know when/why/how a new interpreter was just created.

Carry Away: the first two bytes (characters) in a file dictate how it will be handled, as a binary to load and run, or as an argument that will be handed to the executable. Read the kernel sources (or libc?), following magic.[ch], etc.