On Wed, Jul 6, 2022 at 1:20 PM Brad Hayes <bradoz...@gmail.com> wrote: > Perhaps something similar to PHP's __DIR__ and __FILE__ constants? > > ``` > > source "$__DIR/file.ext" #$__DIR == the absolute path to the current > scripts location. > > ```
I think $__DIR__ and $__FILE__ are better for less brain memory overhead. > I am aware there are existing bash mechanisms to achieve this but are > cumbersome to use. Indeed. An explicit works-in-all-cases solution would be great. I think there are solutions that utilize BASH_SOURCE or $0 but those stuff require subshell hacks to be accurate I think, and work depending on how Bash is executed. > USE CASE: > > > I've been building myself a little ecosystem with hundreds of bash scripts. > Its really handy to have the script's source and call each other without > doing path resolving gymnastics in every single script. > > To make it nice to rapidly build scripts at will I have been putting common > code into smaller scripts. > > And to solve the problem of easily sourcing them I just shoved them in my > path lol. > > > This lets me use a nice clean syntax like so: > > > ``` > > #!/usr/bin/env bash > > source error-handler > > source colours > > #etc.. > > ``` > > > While this makes including common files an absolute breeze it's not ideal > to have all of them in my path because: > > > - my sourceables also need logic to prevent them from being executed by > accident (they tell you to source them instead). > - I cant just share my script collection with colleagues because it will > all break unless they add ALL my scripts to their system path and they > might not want to do that. > - all of the scripts call on each other and that also only works if the > executables are in the system path. > > Defining a ton of functions and shoving them into peoples running > environment is not an answer for me either lol. > > A shorthand to call them from the relative path would be immensely helpful > for using bash scripting as a way to build suites of developer tools. Perhaps Bash can add a variable like perhaps, $SOURCE_PATH variable, which when defined should force 'source' to locate scripts from $SOURCE_PATH instead of $PATH. This easier and lazier solution however is unideal to be used in startup scripts because it changes the behavior of 'source' globally, and generally it adds confusion on how 'source' works when somebody reads the script. Adding another builtin like 'include' is still better. > A pseudo namespacing feature would be way handier, hear me out... > > > Let's say you have a namespace keyword followed by the __DIR__ shorthand. > And once that is done it will treat that folder as if it is at the front of > the PATH var for the duration of the script. > > > Then we can call upon all the local resources in the distributed scripts > collection without jumping through hoops: > > > ``` > > namespace $__DIR #$PATH = "$__DIR:$PATH" for the duration of the script. > > source error-handler > > DATA=some-common-command-in-my-library > > # etc.. > > ``` > > > This would also mean that it can be easy to add a wrapper command to a > collection of scripts named after the vendor so that, > > instead of directly calling from a collection of 300 scripts or adding them > all to your path, > > you can simply add the one parent script to your path that namespaces and > then calls all the others while providing bash completions etc. I didn't understand the intent of this completely but if it's about loading a group of scripts and also in a way having them transparently grouped namespace-wise and directory-wise, I have my own solution for it. I simply have a parent script placed outside the directory to call all the files inside the directory. This is practically the convention used in Ruby too. As an example I have a 'utils.bash' script which loads the *.bash files in a 'utils' directory. Any other application that wants to use the scripts can just load the utils.bash script instead of loading each file in utils/. As for the naming convention, I prefix each function with 'utils.' (if function name is same as script) or 'utils.<script_name>.' since the dot is allowed in Bash. For the global variables used in each script, I have them all capitalized and prefixed with the name of the "namespace", like "UTILS_<SCRIPT_NAME>_". It risks conflict with global and builtin variables but adds easy distinguishability vs. just using lowercase letters prefixed with an underscore. Optionally an underscore can be prefixed to avoid the conflict but I haven't really needed it so far besides on a few shared (just, probably) ones. I also do have an extended "include" function that accepts wildcards best used for loading dynamic yet managed sub-scripts. -- konsolebox
