Linux Custom Executable Globally Available

Linux custom executable globally available

Edit your .bashrc to add the desired directory on the PATH environmental variable.

export PATH=/usr/local/google_app_engine/bin:$PATH

then, either start new terminal or do,

source ~/.bashrc

Now try to run the script from anywhere.

Another way you can do it without even touching the .bashrc would be to create a symlink by doing something like,

sudo ln -s /usr/local/google_app_engine/bin/script.py /usr/bin/script.py 

How to make a programme executable anywhere in the SHELL

1. Make the scripts executable: chmod +x $HOME/scrips/* This needs to be done only once.
2. Add the directory containing the scripts to the PATH variable: export PATH=$HOME/scrips/:$PATH (Verify the result with echo $PATH.) The export command needs to be run in every shell session. For convenience, you want to add that command to the $HOME/.profile file so it is run automatically for you at log-in time.

Now you can execute script.pl some-arguments or script.py some-arguments from anywhere.

How to make a shell script global?

/usr/local/bin would be the most appropriate location. Mac OS X has it in the PATH by default

How to make a binary executable able to write anywhere on linux?

When you create the tool, vector can own it.
The tool should reside somewhere on the user's PATH.
/usr/bin or /usr/local/bin are usually included the PATH.
You can check the path with echo $PATH to see what it is set to.

Check the permissions to make sure it is executable by everyone.
chmod 755 /path/to/binary

When the user executes the tool, it should execute as the user.

Make sure the output of the tool is not hard-code to a location the user does not have access to write.

If you can have it write to STDOUT, then the user can redirect the output to a place of their choosing

cmd> /path/to/binary > ~/output.txt

How do I get the directory where a Bash script is located from within the script itself?

#!/usr/bin/env bash

SCRIPT_DIR=$( cd -- "$( dirname -- "${BASH_SOURCE[0]}" )" &> /dev/null && pwd )

is a useful one-liner which will give you the full directory name of the script no matter where it is being called from.

It will work as long as the last component of the path used to find the script is not a symlink (directory links are OK). If you also want to resolve any links to the script itself, you need a multi-line solution:

#!/usr/bin/env bash

SOURCE=${BASH_SOURCE[0]}
while [ -L "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
  DIR=$( cd -P "$( dirname "$SOURCE" )" >/dev/null 2>&1 && pwd )
  SOURCE=$(readlink "$SOURCE")
  [[ $SOURCE != /* ]] && SOURCE=$DIR/$SOURCE # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
done
DIR=$( cd -P "$( dirname "$SOURCE" )" >/dev/null 2>&1 && pwd )

This last one will work with any combination of aliases, source, bash -c, symlinks, etc.

Beware: if you cd to a different directory before running this snippet, the result may be incorrect!

Also, watch out for $CDPATH gotchas, and stderr output side effects if the user has smartly overridden cd to redirect output to stderr instead (including escape sequences, such as when calling update_terminal_cwd >&2 on Mac). Adding >/dev/null 2>&1 at the end of your cd command will take care of both possibilities.

To understand how it works, try running this more verbose form:

#!/usr/bin/env bash

SOURCE=${BASH_SOURCE[0]}
while [ -L "$SOURCE" ]; do # resolve $SOURCE until the file is no longer a symlink
  TARGET=$(readlink "$SOURCE")
  if [[ $TARGET == /* ]]; then
    echo "SOURCE '$SOURCE' is an absolute symlink to '$TARGET'"
    SOURCE=$TARGET
  else
    DIR=$( dirname "$SOURCE" )
    echo "SOURCE '$SOURCE' is a relative symlink to '$TARGET' (relative to '$DIR')"
    SOURCE=$DIR/$TARGET # if $SOURCE was a relative symlink, we need to resolve it relative to the path where the symlink file was located
  fi
done
echo "SOURCE is '$SOURCE'"
RDIR=$( dirname "$SOURCE" )
DIR=$( cd -P "$( dirname "$SOURCE" )" >/dev/null 2>&1 && pwd )
if [ "$DIR" != "$RDIR" ]; then
  echo "DIR '$RDIR' resolves to '$DIR'"
fi
echo "DIR is '$DIR'"

And it will print something like:

SOURCE './scriptdir.sh' is a relative symlink to 'sym2/scriptdir.sh' (relative to '.')
SOURCE is './sym2/scriptdir.sh'
DIR './sym2' resolves to '/home/ubuntu/dotfiles/fo fo/real/real1/real2'
DIR is '/home/ubuntu/dotfiles/fo fo/real/real1/real2'

Making a Deno Script globally available

You could use deno install or deno compile to create executables from Deno code.

deno install will install your CLI tool in $HOME/.deno/bin or a custom directory when you set the DENO_INSTALL_ROOT environment variable.

deno_compile will create a self-contained binary including the runtime and dependencies, as was answered in this thread. It would make the executable more stand-alone but it increases the size of the compiled source.

It's up to you which one you prefer, but they can both work to execute a Deno module 'globally'

Will an executable access shared-libraries' global variable via GOT?

Part of the point of a shared library is that one copy gets loaded into memory, and multiple processes can access that one copy. But every program has its own copy of each of the library's variables. If they were accessed relative to the library's GOT then those would instead be shared among the processes using the library, just like the functions are.

There are other possibilities, but it is clean and consistent for each executable to provide for itself all the variables it needs. That requires the library functions to access all of its variables with static storage duration (not just external ones) indirectly, relative to the program. This is ordinary dynamic linking, just going the opposite direction from what you usually think of.

---

Related Topics