Anyone cloning your repository can clone it anywhere, and hard-coding the path to an executable is considered an anti-pattern. What you most likely are trying to do is to call an executable from inside the project directory where the file was cloned. You should probably assume that anyone who can clone your project is capable of changing to a project directory, or at least read the README file you include explaining where to install the binaries and run the code.
If you're distributing your Ruby file as a gem named "foo", then there's a standard gem layout that allows you to use require
or require_relative
from the project's ./lib/foo.rb
. You can also modify the $LOAD_PATH of your Ruby program if you are putting libraries in unusual places.
If you're doing something else, then you might want to look at utilities like direnv that lets a user modify their shell PATH dynamically when they enter a project directory. This is useful because it also unsets the changes when they leave the project directory.
Finally, if you're distributing your code as a gem, then once the gem is properly installed into GEM_HOME the user shouldn't have to worry about the location of executables within the gem. They should either be exposed when the user invokes require "foo"
or calls an executable installed into the gem's bin directory, which your Ruby version manager should expose in PATH via GEM_HOME, e.g. $HOME/.gem/ruby/3.2.1/foo/bin/file1
.
In short, there are a lot of standard ways to invoke a Ruby source file, but shell aliases probably aren't the right way for the use case you described. PATH and CDPATH are the most likely environment variables to modify for Bash, and LOAD_PATH is the most likely setting to modify for Ruby itself. If you can, though, stick with the standards, and make sure to note any oddities in your project's README.