What I think 273 is trying to get across is the interpreter is the program that is being executed not the file on the USB drive. The interpreter reads the file and performs the instructions. The same is true for a java file. While a jar file is compiled it is not a stand alone executable and as posted requires the JRE. Again the JRE is the program that runs, reads the jar file and perform its instructions.

A shell script is nothing more then a text file. It can be "executable" if it contains the shebang (#!/path/to/interpreter) and its executable bit set. In addition the directory where the file is located must also have the appropriate permission bits set. Otherwise as long as the file is readable it can be "executed" by running the interpreter directly i.e.

interpreter /path/to/file

1 members found this post helpful.

Indeed. Added to the above when you're using a GUI file browser you are using a program that, when you click on a file, will either execute it if it is an actual executable or open it with another program -- that could be an interpreter for scripts or just an image manipulation program and the GUI file manager doesn't know the difference.
So, what you are trying to do is stop the fuile manager from associating scripts with ande interpreter only when they're run from a USB drive which, I suspect, is non-trivial and possibly not what you really require anyway. Hence my suggestion that you read around the subject some more.

Think of the interpreter as a chef working in the host kitchen. If the chef can read the recipe from the USB kitchen, then the chef can prepare the dish.

This logic is completely wrong. If the file is readable it can be copied anywhere (and can be made executable if required). Even onto usb/disk/ram/whatever. Also either it can be executed - if executable, or can be run by its interpreter/executor (if that was installed). There is no way to disable it. If the file is not readable you cannot use it (but probably you can make it readable).

ce309,

Unless it's a compiled program, that's been compiled into machine code, then it's an interpreted program being executed by an interpreter, that itself (the interpreter) has been written in a compiled programming language, then compiled (the interpreter) into machine code. More precisely, the interpreter's instructions (that it's reading from your script) are being executed by your machine's processor - it's the interpreter that's issuing those same instructions to the processor, not the script you're running.

I suggest you look up what compiled means - things should become clearer for you.

1 members found this post helpful.

As far as the OS is concerned, that .jar file is just data. The Java interpreter is the executable that reads that data and acts on it, just as a spreadsheet program reads and processes a spreadsheet file. And BTW, that spreadsheet file can contain escapes that can invoke other programs to perform arbitrary actions in the OS. The only permission needed is for reading the file.

Regarding your experience with the "Hello World" script vs. the .jar file, if you directly execute the file by typing just its name, i.e. "./hello" or "./sample.jar", then execute permission is required. But, if you invoke the needed interpreter by typing "bash ./hello" or "java ./sample.jar", then the interpreter only needs permission to read the file. Again, to the OS it is just data being read and processed. It does not matter if you consider that "processing" to be execution. The OS does not, and indeed cannot, distinguish an interpreter's processing of a script file from the processing that a spreadsheet program, movie player, PostScript interpreter, etc. performs on the files that it reads.

Thank you all for your replies.


I did look up further. Here is what I got:-

Compiled and Interpreted:

There are two types of compilation:

1. Some compilers compile source code directly into machine code. This is the original mode of compilation, and languages that are directly and completely transformed to machine-native code in this way may be called truly compiled languages.

2. Intermediate representations
When code written in a language is compiled to an intermediate representation, that representation can be optimized or saved for later execution without the need to re-read the source file. When the intermediate representation is saved, it may be in a form such as bytecode. The intermediate representation must then be interpreted or further compiled to execute it. Virtual machines that execute bytecode directly or transform it further into machine code have blurred the once clear distinction between intermediate representations and truly compiled languages.


So, the .jar file itself is not directly executable but is read by the interpreter which transforms the bytecode to machine code and executes it. Java is a high-level language as it provides high level of abstraction from machine code.

The shell script (hello file) is directly executed i.e. converted to machine code by the Unix Shell (command-line interpreter).
Shell scripting, even though directly executable is a very high-level language as it provides a very high level of abstraction from machine code.

I also tried executing .py, .c and .bin files while executable permission was disabled (syntax: ./filname.[extension]) and I got "Permission Denied" error.

So, the executable permission in linux is for scripting languages which can be directly converted to machine code without the need of intermediate representation.
(Note: Some scripts may require additional compiler or other software like gcc complier for .c files)

Correct me if any of the above is wrong.

I still don't see the exact use/purpose of this permission because native .deb files can still be installed and may contain a virus while executable permission is disabled. Rather a user may be tricked into feeling secure knowing that the executable permission is disabled.

that is completely wrong. I mean probably you are right, but the logic is misleading.

Only binaries can be executed which are runnable on the "current" system. Some examples: bash itself, firefox, gcc, python....
scripts are not executable by themselves, files containing byte codes again are not executables, we always need an executor for them, which is a binary in any case (containing native code).

However there is a trick to make it better (or more complex?): you can specify that binary executor in text files (like scripts) in the very first line (called shebang).
The format is:
you can specify any executable which will process the text file (which is still not runnable by itself, but by the binary specified). By this trick you can make .py, .bin or even .c files executable if you wish.

It is completely irrelevant if that file was created using an editor, a compiler or any other kind of generator.

The execute permission is just a flag to tell the system if you want to execute it or not (regardless of the content). You can change it any time you want.

What is still even more tricky: the java bytecode theoretically can be executed as native code on a java machine (which actually does not exist) and can be executed using a binary on any other hardware (this is the file named java).

1 members found this post helpful.

py is a python program which is an interpreted language.

.c would indicate c language source code which is not a script and normally compiled into a executable program.

.bin file indicates a binary file but not necessarily executable.

A deb file is an archive that can contain executable files but is not executable by itself. Used by a package manager to install programs but not the same thing as a program.

Most compiled programs are executable by themselves and will not run without the executable but set.

Thanks pan64 and michaelk for your inputs.

So, the processor can run:
1. Directly executable files/programs called binaries e.g. Unix shell, Spreasheet, Firefox, etc.
2. Some binary files like .bin which can be made directly executable (not executable by default)

1.1 The Unix shell can take input in the form of executable scripts or invoke other programs

1.1.1 Executable scripts such as

1.1.1.1 Bash Script .sh or no extension
1.1.1.2 Scripts having extension like .py or .c for which the OS has a transformation software to convert to machine code
1.1.1.3 Scripts having extension like .py or .c beginning with shebang (#!) followed by path to the transformation software for that file

1.1.2 Invoking other programs from the Unix shell such as:

1.1.2.1 Invoking java interpreter via java -jar filename.jar for scripts that are compiled to an intermediate representation
1.1.2.2 Invoking dpkg i.e. Debian package manager for .deb files. (dpkg -i filename.deb)

1.2 Binaries other than Unix shell like Spreadsheet, Firefox which can read a file as input for processing.
Example: A .xlsx file read by Spreadsheet which can be used for processing.

Note 1: Script or scripting language is used to indicate a program or programming language
Note 2: The phrase "transformation software" is used as a general term to indicate a compiler/interpreter which converts non-machine code to machine code.

So, the executable permission in Linux is for Unix shell executable scripts (1.1.1) -- Am I right?

I will edit this post for any corrections/update so that the information is accurate.

what is the goal of this thread now?

The executable permission is used for everything you want to execute not for shell scripts.

A script is a text file but not all text files are scripts.

A compiled program is a binary file but not all binary files are executable programs.

As pan64 posted "The execute permission is just a flag to tell the system if you want to execute it or not (regardless of the content). You can change it any time you want." The executable bit is not just for shell scripts. It works for compiled programs too.

Actually, linux does not actually care about extensions. So whether it is .sh, .c, .py, .bin or .xyz is a matter of convention for use users but does not matter. The system uses what is called a magic number to determine its association or how the script/program is executed. By association i.e when you click on a .xls file it is automatically opened in a spreadsheet program.

Although extensions are used by some programs especially text editors to determine what plugin to use for syntax highlighting.

The thread is slightly off topic but for a user like me who has shifted from Windows to Linux, knowing basics of how Linux works is quite useful.

Previous statement:
"2. Binary files like .bin which are made directly executable (not executable by default)"
edited to
"2. Some binary files like .bin which can be made directly executable (not executable by default)"

Can such compiled programs be executed outside of Unix Shell? A small example would be quite helpful.

This is scary. Because even if I disable executable permission for a usb as a root user, still a non-root user who has read access for that usb can run executables from it. I tried this and a non-root user is able to execute such files from a usb.

compiled programs always executed outside of a shell. Shell is only used to start them, but you can start them by clicking on an icon or executing an ssh or ....

Just to expand on what michaelk was saying about C source code; when you compile C source code, gcc for one converts it into assembly language, which is a low-level programming language, then it converts the assembly language into machine code. The machine code is what the processor understands to be a set of instructions to do something. The original source code may mean something to us humans, but it means nothing to the processor, because the processor only understands machine code. I'd just think of it that way to make it easier to understand.

That said, you could write a program directly in assembly language if you know assembly, but it would not be portable. In other words, you would have to re-write it for it to work on a different computer, in simple terms. Therefore, you would either use a higher-level language like the C programming language (but not limited to), or you would use a scripting language. Personally, I'd say if you think you might need to modify the program at some point, and particularly if it's only for a specific task, like for example, doing a backup every week/day/month/whatever, then you would probably use a script for that rather than a compiled programming language. As in that example, you would have much more flexibly using a scripting language rather than a compiled language. Because you could simply use a text editor to modify it, and more to the point, you would not need to re-compile it.

1 members found this post helpful.