4

In bash, sometimes I would like to reuse a function in several scripts. Is it bad to repeat the definition of the function in all the scripts? If so, what is some good practice?

Is the following way a good idea?

  • wrap the definition of a function myfunction in its own script define_myfunction.sh,
  • in any script where the function is called, source define_myfunction.sh , and then call the function myfunction arg1 arg2 ....

Thanks.

  • That is exactly what I do in my use-cases. – DopeGhoti Jun 5 '18 at 16:56
  • That is the way to do it, yes. – Kusalananda Jun 5 '18 at 16:57
2

In bash, that is a good way of doing it, yes.

Sourcing the "library" script using source or . would be an adequate solution to your issue of wanting to share a function definition between two or more scripts. Each script that needed access to the function(s) defined in the "library" script(s) would source the needed file(s), probably at the top of the script.

This would allow you to collect related functions in a single "library" script and source it to get access to them.

Not entirely unrelated, but the bash shell also has the ability to automatically source a file upon executing a non-interactive shell (i.e. a script). This may be used to set up a specific environment for the script:

BASH_ENV="$HOME/stuff/script.env" ./myscript

... where script.env may do anything from defining functions and setting shell or environment variables, to sourcing other files etc.


Some shells, like ksh93, has an environment variable that points to a directory that may contain function definition scripts like these. In ksh93, this variable is called FPATH. A script, $FPATH/foo, would contain a function called foo, which would automatically be found when the user types foo on the command line (or in a script). The bash shell does to my knowledge not have this specific functionality.

Other shells have other forms of "auto-load" functionality.

  • The fish shell also has an "autoload" directory. – glenn jackman Jun 5 '18 at 17:05
  • I'm 100% certain that zsh has one or several ways of doing this too (but I'm no zsh user). – Kusalananda Jun 5 '18 at 17:08
  • Also, bash does something similar: this appears in my /etc/profile (flattened for lack of formatting) if [ -d /etc/profile.d ]; then for i in /etc/profile.d/*.sh; do if [ -r $i ]; then . $i; fi; done; unset i; fi – glenn jackman Jun 5 '18 at 17:09
1

This question may get flagged for being subjective, but I believe it's generally accepted as best practice to use libraries for commonly-used code rather than reinventing the wheel every time. sourceing a script which defines functions and variables is the shell way to do this, so I would say yes, having library scripts and sourceing them is probably good practice.

I actually go one further and have a bin directory in my PATH with tools and script I frequently use; some of those library scripts are in there so I can source them readily for use at my interactive shell.

  • Thanks. Could you list the use-cases that you choose to put the reusable code into a function (and therefore need to wrap the function's definition in a script) instead of just putting the resuable code into a script? – Tim Jun 5 '18 at 17:01
  • In one case, I did a lot of software deployments using the same tools, but to different host sets. So I would depending on the argument to my deployment script, source the definitions library for the correct environment, and my script could agnostically use hostlist[@]. I also have a bunch of helper scripts that make using dialog a lot less hairy to read that I use in a lot of places. Pretty much any time I notice I'm defining the same variable for the third or fourth time, I put it in a helper script for sourceing. – DopeGhoti Jun 5 '18 at 17:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.