Re: Good placement of bash export functions

[Greg Wooledge]

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.

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.

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.