Hot answers tagged

170

bash does cache the full path to a command. You can verify that the command you are trying to execute is hashed with the type command: $ type svnsync svnsync is hashed (/usr/local/bin/svnsync) To clear the entire cache: $ hash -r Or just one entry: $ hash -d svnsync For additional information, consult help hash and man bash.


161

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: enabled interpreter /usr/lib/binfmt-support/run-detectors flags: offset 0 magic 4d5a (on a Debian system). This tells the ...


157

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


99

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 /bin/rm scriptname 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 ...


83

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, "...


63

The literal answer is as others have given: because the current directory isn't in your $PATH. But why? In short, it's for security. If you're looking in someone else's home directory (or /tmp), and type just gcc or ls, you want to know you're running the real one, not a malicious version your prankster friend has written which erases all your files. ...


58

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 ...


54

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 ...


51

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 ...


48

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. ...


47

The whole ABI is different, not just the binary format (Mach-O versus ELF) as sepp2k mentioned. For example, while both Linux and Darwin/XNU (the kernel of OS X) use sc on PowerPC and int 0x80/sysenter/syscall on x86 for syscall entry, there's not much more in common from there on. Darwin directs negative syscall numbers at the Mach microkernel and ...


45

/usr/local/bin is for programs that a normal user may run. The /usr/local hierarchy is for use by the system administrator when installing software locally. It needs to be safe from being overwritten when the system software is updated. It may be used for programs and data that are shareable amongst a group of hosts, but not found in /usr. Locally ...


44

When you fail to execute a file that depends on a “loader”, the error you get may refer to the loader rather than the file you're executing. The loader of a dynamically-linked native executable is the part of the system that's responsible for loading dynamic libraries. It's something like /lib/ld.so or /lib/ld-linux.so.2, and should be an executable file. ...


41

If you mean, why do you need ./ at the start - that's because (unlike in Windows), the current directory isn't part of your path by default. If you run: $ ls your shell looks for ls in the directories in your PATH environment variable (echo $PATH to see it), and runs the first executable called ls that it finds. If you type: $ a.out the shell will do ...


39

Usually, this kind of message is due to an extra carriage return at the end of the first line. Run $ head -1 yourscript | od -c and see how it ends: This is wrong 0000000 # ! / b i n / b a s h \r \n This is correct: 0000000 # ! / b i n / b a s h \n Use dos2unix to fix your script if this is the issue.


39

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 ...


38

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 ...


38

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. ...


35

In Linux, UNIX and related operating systems, . denotes the current directory. Since you want to run a file in your current directory and that directory is not in your $PATH, you need the ./ bit to tell the shell where the executable is. So, ./foo means run the executable called foo that is in this directory. You can use type or which to get the full path ...


33

/usr/, I assume is the user of the computer. Originally, yes, it did refer to the system's users. Before AT&T changed the default location for user folders to /home in System V Release 4 (SVR4), the default was /usr.1 That is to say, your $HOME might have been /usr/jfw on a System III box.2 /usr also contained, then as now, /usr/bin, /usr/lib, etc. ...


33

The shared library HOWTO explains most of the mechanisms involved, and the dynamic loader manual goes into more detail. Each unix variant has its own way, but most use the same executable format (ELF) and have similar dynamic linkers (derived from Solaris). Below I'll summarize the common behavior with a focus on Linux; check your system's manuals for the ...


31

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/...


30

If you compile an executable with gcc's -g flag, it contains debugging information. That means for each instruction there is information which line of the source code generated it, the name of the variables in the source code is retained and can be associated to the matching memory at runtime etc. Strip can remove this debugging information and other data ...


29

There isn't a universal way, but you can make an educated guess by looking for things only done by one compiler. GCC is the easiest; it writes a .comment section that contains the GCC version string (the same string you get if you run gcc --version). I don't know if there's a way to display it with readelf, but with objdump it's: objdump -s --section ....


29

You can determine the nature of an executable in Unix using the file command and the type command. type You use type to determine an executable's location on disk like so: $ type -a ls ls is /usr/bin/ls ls is /bin/ls So I now know that ls is located here on my system in 2 locations:/usr/bin/ls & /bin/ls. Looking at those executables I can see they'...


29

In a word: binfmt_misc. It's a Linux-specific, non-portable, facility. There are a couple of formats that are recognized by the kernel with built-in logic. Namely, these are the ELF format (for normal binaries) and the shebang convention (for scripts). (thanks to zwol for the following part of the answer). In addition, Linux recognizes a couple of esoteric ...


29

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 ...


27

shc is what you're looking for. get it here: shc Extract, cd into dir, make and then ./shc -f SCRIPT. Done. Everything you need to do this, you find here: SHC Howto


26

Another way is by calling the interpreter and passing the path to the script to it: /bin/sh /path/to/script The dot and source are equivalent. (EDIT: no, they're not: as KeithB points out in a comment on another answer, "." only works in bash related shells, where "source" works in both bash and csh related shells.) It executes the script in-place (as if ...


26

Virtual machine can give you highest security without reboot, but lowest performance. Another option, for even higher security than a virtual machine: boot a "live" CD/DVD/pendrive without access to the hard drive (temporarily disable the HDD in BIOS; if you can't, at least do not mount the drive / unmount it, if mounted automatically - but this is much less ...



Only top voted, non community-wiki answers of a minimum length are eligible