Re: Good placement of bash export functions

[uzibalqa]

------- Original Message -------
On Tuesday, October 11th, 2022 at 9:21 PM, Greg Wooledge <greg@wooledge.org> 
wrote:


> On Tue, Oct 11, 2022 at 09:06:13PM +0000, uzibalqa wrote:
> 
> > A have a number of bash script files, each with its own set of functions 
> > that a user can call.
> > Each files focuses on specific tasks (for instance. comint.rc handles 
> > parallel versions of
> > search for both find and grep). So I call the whole collection a terminal 
> > shell "package".
> > 
> > > What are you trying to do here?
> > > 
> > > How do you actually run these "script files"?
> > 
> > I source the files. Then users can just call the functions they want, 
> > without having to worry
> > about specifying any paths.
> 
> 
> Ah, so they're not really scripts. They're files intended to be
> sourced.

Would you suggest extending them to allow their use as scripts as well?
The idea for sourcing is convenience on the command line. 
 
> In that case, I would imagine the way you should document your package
> is to tell the users to put "source /path/to/your/package" in their
> ~/.bashrc files. That way, the functions will be read in by each instance
> of bash, ready to be used.

Right.  That's the current approach.  
 
> Exporting them therefore serves no real purpose.
> 
> The only rational purpose I could imagine for exporting the functions after
> sourcing your package would be for a user who does a "startx" type login,
> who can therefore read the package one time during login, and have the
> functions propagate down to child processes.
> 
> Most users these days seem to use Display Manager logins, which makes
> sourcing a file full of bash functions and exporting them for their
> whole session literally impossible. A DM login either has no shell
> at all, or uses a /bin/sh (not bash) shell.

Then the idea of export is to allow propagation of environment variables,
rather than actually running exported functions.