New answers tagged

0

# cat proc/cpuinfo system type: RTL8672 processor: 0 cpu model: 56322 An RTL8672 is not a full MIPS implementation, but a Lexra. You will need a customized toolchain that knows how to handle this. Something like this, or for a binary-only toolchain, look for rsdk; e.g., this.


12

Bash is an interpreter; it accepts input and does whatever it wants to. It doesn't need to heed the executable bit. In fact, Bash is portable, and can run on operating systems and filesystems that don't have any concept of an executable bit. What does care about the executable bit is the operating system kernel. When the Linux kernel performs an exec, ...


4

As far as the OS is concerned, a file containing shell script is just data. If you pass the name of such a data file to the source command or pass it on the command line to an invocation of the bash shell, all the OS sees is a string that happens to coincide with the name of a file containing data. How would the execute bit be at all relevant in that case?


3

The distinction is important because you may have a file of shell commands which is not useful as an executable, but only useful when sourced. For this file you can turn off the execute bit and then it will never be accessed unless explicitly in a source command. The reason for such a thing is to have side effects on the shell it is run from. For a ...


-1

Another point of view: Sourced script basically consists of shell builtins and program calls. Shell builtins (with source among them) are parts of the shell and the shell must be executable in the first place. Every program called (that being ELF, another script with shebang, whatever) has to have execution bit set, otherwise it will not run. So it is not ...


8

That's a good question! Unix uses the executable bit to distinguish between programs and data. The OS does not require the execution bit, since a sourced script is not passed to the OS for execution as a new process. But the shell treats a sourced script as a program, and will look in $PATH for the file you want to source. So, the shell itself could have ...


16

The executable bit (unlike the rest) on nonsetuid and nonsetguid files isn't much of a security mechanism. Anything you can read, you can run indirectly, and Linux will let you indirectly read anything you can run but not directly read (that should be enough to punch a hole in the concept of non-set(g)uid x-bit being a security measure). It's more of a ...


41

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


0

You can copy all of its libraries from their system locations into a subdirectory of where your executable is and use patchelf, to make the executable look for its libdependencies there instead of the system lib directories. E.g.: relativize_libs: #!/bin/bash -e [ -n "$1" ] || set -- a.out mkdir -p ./lib/ #<copy the libraries here #use ldd to resolve ...


-5

I found on Ubuntu Linux 16.04 that "No such file or directory" means you have to switch your current working directory while "command not found" means you have to use apt-get install xxxyyy_zzz to fix the problem.


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


3

For the question, where file1.pgm and file2.pgm are files whose contents you want sent to a.out as input: cat file1.pgm file2.pgm | ./a.out If file1.pgm and file2.pgm are executables that produce output for a.out: (file1.pgm; file2.pgm) | ./a.out


0

To make your scripts unreadable yet executable, you have 3 major options: First Option Use the openssl command to manually encrypt it. And in the future, when you want to run the script, you'll have to run openssl manually again, and provide the password to decrypt. Encryption with openssl: cat yourscript.sh | openssl aes-128-cbc -a -salt -k yourpassword ...


0

Change your path, then replicate a tree of all your executables to it, where each one is just another name for your script. Something like : $ mkdir ${HOME}/shell $ OLDPATH=$PATH $ PATH=${HOME}/shell:$PATH $ echo $PATH | tr : \\n \ | while read P; do (mkdir -p $(echo $P | sed s':/::'); ls $P/* ) \ | while read F; do ln master_script $(echo $F | sed s':...


0

I don't know of any way to archieve that the command is completely send to a script, but in bash or in zsh you can add a hook usign the DEBUG trap which is called before each command. For the details, please see http://superuser.com/questions/175799/does-bash-have-a-hook-that-is-run-before-executing-a-command Edit: To stop a command, you can make it fail ...


0

You probably should not combine a Bash script into an executable, for these reasons, but if you absolutely need an executable, you can use SHC (technically an obfuscation algorithm). SHC "translates" the script into C code, and then compiles it. We then come to the problem of the multiple files. Because SHC can only take one file as input, you will have to ...



Top 50 recent answers are included