You can run the loader directly, and pass it the command you want to run:
/lib/ld-linux.so /bin/chmod +x /bin/chmod
Your path to the loader might vary. On a 64-bit system you need to choose the right one based on how chmod was compiled; the 64-bit version is named something like /lib64/ld-linux-x86-64.so.2
This is binfmt_misc in action: it allows the kernel to be told how to run binaries it doesn't know about. Look at the contents of /proc/sys/fs/binfmt_misc; among the files you see there, one should explain how to run Mono binaries:
(on a Debian system). This tells the ...
In addition to the performance benefits of using a character-special device, the primary benefit is modularity. /dev/null may be used in almost any context where a file is expected, not just in shell pipelines. Consider programs that accept files as command-line parameters.
# We don't care about log output.
$ frobify --log-file=/dev/null
# We are not ...
The shebang #! is an human readable instance of a magic number consisting of the byte string 0x23 0x21, which is used by the exec() family of functions to determine whether the file to be executed is a script or a binary. When the shebang is present, exec() will run the executable specified after the shebang instead.
Note that this means that if you invoke ...
The kernel interprets the line starting with #! and uses it to run the script, passing in the script's name; so this ends up running
which deletes the script. (As Stéphane Chazelas points out, scriptname here is sufficient to find the script — if you specified a relative or absolute path, that's passed in as-is, otherwise whatever path ...
The chmod utility relies on the chmod() system call (see man 2 chmod). So you could do this with a few lines of C, or just about any other language that has a wrapper around it (which would be most of them). Very few *nix systems are going to lack a C compiler and a perl interpreter; most linux distros require the later to work.
perl -e 'chmod 0755, "...
The number passed to the _exit()/exit_group() system call (sometimes referred as the exit code to avoid the ambiguity with exit status which is also referring to an encoding of either the exit code or signal number and additional info depending on whether the process was killed or exited normally) is of type int, so on Unix-like systems like Linux, typically ...
If you are fine with setting the execute permissions for everyone on all folders:
chmod -R -x+X *
The -x removes execute permissions for all
The +X will add execute permissions for all, but only for directories.
See below for a solution that uses find to really not touch folders as requested.
In general, if a non-system installed and maintained binary needs to be accessible system-wide to multiple users, it should be placed by an administrator into /usr/local/bin. There is a complete hierarchy under /usr/local that is generally used for locally compiled and installed software packages.
If you are the only user of a binary, installing into $HOME/...
You can do this with ldd command:
ldd - print shared library dependencies
ldd [OPTION]... FILE...
ldd prints the shared libraries required by each program or shared
library specified on the command line.
$ ldd /bin/ls
linux-vdso.so.1 => (0x00007fff87ffe000)
. will auto-complete to ./ (type . and press Tab) at least in modern Bash shells, so you shouldn't have to use a complex or insecure (like PATH modification) solution.
If it doesn't auto-complete you might need to install the "bash-completion" package.
The issue is that the script is not what is running, but the interpreter (bash, perl, python, etc.). And the interpreter needs to read the script. This is different from a "regular" program, like ls, in that the program is loaded directly into the kernel, as the interpreter would. Since the kernel itself is reading program file, it doesn't need to worry ...
Some systems also have busybox installed in which case you may run:
busybox chmod +x /bin/chmod
Since you were asking for hacks, I just thought of another one:
mv /bin/chmod /bin/chmod.orig
cp -a /bin/chown /bin/chmod
Now you have a /bin/chmod that's executable but it's actually chown (i.e. some other binary). Now all we have to do is overwrite it with ...
Even as root, you can't execute files that have no x permission bit set. What you can do though is call ld.so on it (provided they're dynamically linked executables):
$ echo /lib/*/ld*.so
Use the one that matches the architecture of chmod executable. In my case the x86_64 one:
In fairness, it's not a regular file per se; it's a character special device:
$ file /dev/null
/dev/null: character special (3/2)
It functioning as a device rather than as a file or program means that it's a simpler operation to redirect input to or output from it, as it can be attached to any file descriptor, including standard input/output/error.
That's because bash remembered your command location, store it in a hash table.
After you uninstalled node, the hash table isn't cleared, bash still thinks node is at /usr/local/bin/node, skipping the PATH lookup, and calling /usr/local/bin/node directly, using execve(). Since when node isn't there anymore, execve() returns ENOENT error, means no such file ...
readelf -d $executable | grep 'NEEDED'
Can be used if you can't run the executable, e.g. if it was cross compiled, or if you don't trust it:
In the usual case, ldd invokes the standard dynamic linker (see ld.so(8)) with the LD_TRACE_LOADED_OBJECTS environment variable set to 1, which causes the linker to display the library
dependencies. Be ...
For your specific script either way will work, except that ./script.sh requires execution and readable bits, while bash script.sh only requires readable bit.
The reason of the permissions requirement difference lies in how the program that interprets your script is loaded:
./script.sh makes your shell run the file as if it was a regular executable.
source or the equivalent but standard dot . do not execute the script, but read the commands from script file, then execute them, line by line, in current shell environment.
There's nothing against the use of execution bit, because the shell only need read permission to read the content of file.
The execution bit is only required when you run the script. ...
NOTE: I'm going to assume that your machine has a memory mapping unit (MMU). There is a Linux version (µClinux) that doesn't require an MMU, and this answer doesn't apply there.
What is an MMU? It's hardware—part of the processor and/or memory controller. Understanding shared library linking doesn't require you to understand exactly how an MMU works, just ...
I suspect the why has a lot to do with the vision/design that shaped Unix (and consequently Linux), and the advantages stemming from it.
No doubt there's a non-negligible performance benefit to not spinning up an extra process, but I think there's more to it: Early Unix had an "everything is a file" metaphor, which has a non-obvious but elegant advantage if ...
That library has a main() function or equivalent entry point, and was compiled in such a way that it is useful both as an executable and as a shared object.
Here's one suggestion about how to do this, although it does not work for me.
Here's another in an answer to a similar question on S.O, which I'll shamelessly plagiarize, tweak, and add a bit of ...
Easy. What you can do is prepare some other executable file, and then cp chmod over it.
$ cp /bin/ls chmod
$ cp /bin/chmod .
The first cp creates a file called chmod with executable permissions, but which is really the ls executable. The second cp populates this file with the binary code of chmod, while preserving the execute permissions of the target ...
“LSB” here stands for “least-significant byte” (first), as opposed to “MSB”, “most-significant byte”. It means that the binary is little-endian.
file determines this from the sixth byte of the ELF header.
test is an unfortunate name to use, it's the standard utility for conditional tests. (It's actually the same command as the [ in if [ ... ], it just looks like a syntactical thing, but is really just a normal command.)
test is also builtin in e.g. Bash, so running just test never looks up your binary from the path.
bash$ help test | head
test: test [expr]
This is not an answer, but it's showing binary, a command which you could run
Other useful commands
compgen -a # will list all the aliases you could run.
compgen -b # will list all the built-ins you could run.
compgen -k # will list all the keywords you could run.
compgen -A function # will list all the functions you could run....
or.. perhaps giving the interpreter an alias in the bashrc file and then simply
It is possible to write such a function:
in your ~/.bashrc. Then you'll be able to run p app arguments instead of ./app arguments. This solution works for executables of any type, including scripts and binaries.
"$@" expands to appropriately quoted ...