Assume jsh has been "initialised" or load dependencies on demand?

[joeytwiddle]

(A) Proposal

Currently most jsh scripts only require one initialisation step before they should work:

• export PATH="$PATH:$JPATH/tools"

However there are advantages to running more initialisation, and letting scripts assume that initialisation has occurred:

• We can populate a bunch on environment variables for colors.
• We can declare a bunch of useful functions. (Currently when we want to use a common script, we have to find it on the PATH, which is a runtime overhead.)

Advantages:

• Slower init when jsh loads, but faster runtime for many scripts after that.

Disadvantages are:

• Scripts which use common functions will fail to run standalone. They won't work without the pre-init.
• compilejshscript will be compelled to add this init stuff to make scripts work, even though in some cases it will not be needed.
• Less modular. Editing a common function will require re-init of jsh, sometimes we may even need to start a fresh shell to clear out unwanted stuff.
• It's a bit naughty to pollute the environment vars with colors and whatever else. It's similarly a bit naughty to load a bunch of functions. There are more likely to be conflicts with other sourced scripts, e.g. rvm and oh-my-zsh.

For example, colors.

The current policy is whack:

• 1. Scripts call $(cursegreen) when they want to display green on the terminal. This is incredibly inefficient, since this has to resolve and run a shellscript in a new shell, for each colorcode shown!

A better policy would be:

• 2. A script which wants to use colours should source either curses/load_shell_colors.shlib to get environment variables (requires bash if we want to source from $PATH)
• 2b. A slightly different approach, jsh/faster_jsh_colors.init loads some functions to do the same. This provides legacy compatibility. In this case we could drop he environment variables.

However there is a third option:

• 3. On init, jsh sources one of the above, to populate the color environment variables. All jsh scripts may then assume the environment variables are available.

Another argument against

Sometimes I wish more of my commands worked in Vim's command line, through :!...

Most of those on the PATH do, but aliases and functions do not. To make the Vim user happier, I would convert more of those aliases and functions into standalone scripts. That is the opposite of this proposal!

(B) A best-of-both-worlds approach?

Using the makeshfunction script, we can load stand-alone scripts into the shell as functions.

If applied correctly, we could optionally load some functions at initialisation time. When a jsh script tries to call a common script, it will run the pre-loaded function if it exists, or the PATH script if the function is not present.

Disadvantage:

• We will not be able to take advantage of some of the features that using functions provides, e.g. functions can set variables in the context of the calling script, and can exit from the calling script (which is occasionally a feature).
• Although makeshfunction tries to mitigate them, we may run intro trouble due to the inconsistencies between function calls and script calls.

For example, a script which used to do . require_exes foo might prefer if require_exes was a function, so it could call require_exes foo with less overhead. But then we must always load it as a function, if it is not pre-loaded then it will not work as intended! But we cannot go back to the old way using . either because that simply doesn't apply to functions.