chmod +x: Making a File Executable and the umask Catch

chmod +x is the first command anyone learns after writing a script, and it is one of the few places where symbolic notation is clearly better than octal: it adds the execute bit and leaves read and write exactly as they were. A file at 644 becomes 755, a file at 640 becomes 750, and you did not have to know which it was.

The catch is that omitting the class makes it depend on the umask. POSIX says a bare plus applies to all three classes with the umask subtracted, so under the common 022 you get a+x as expected, and under a tight 077 you get owner execute only. On a shared machine where the umask is set for privacy, chmod +x quietly does less than the person typing it intended.

Execute alone is not enough for a script. The kernel reads the first line to find the interpreter, and the interpreter then reads the whole file, so a script needs the read bit for whoever runs it. A file at 711 is executable and unreadable, which works for a compiled binary and gives permission denied for a shell script, and that error names the script rather than the missing read bit.

The other half of a working script is the interpreter line. Without a shebang as the first line of the file, an execute attempt either fails or falls back to the calling shell, which is why a Python script with the execute bit set can still produce syntax errors from a shell. Adding the shebang and the execute bit together is the reliable pair.

Version control only records part of this. Git tracks a single executable bit, storing a file as mode 100644 or 100755, and ignores the rest of the mode entirely. To set it without touching your working copy's permissions, use git update-index with the chmod flag, which is also the way to fix a file that arrived from a system that does not carry permissions at all.