Add load/reloader logs

[NoahGorny]

Continuation of #1501
Also add prefix option for the logs, not by a stack, but rather by a variable set by the owning file

TODO:

• Add logs to plugins
• Unset prefix on closure of each file
• Add logs to completions?
• Add logs to themes?

[davidpfarrell]

Nice work knocking out a version of this already !

I suppose a simple string prefix is usable as my initial stack idea.

However, I don't think I would expect each individual alias/plugin/completion/theme/etc file set the prefix directly. I think the bash-it.sh script can set the prefix right before sourcing the individual files:

# libraries, but skip appearance (themes) for now
_log_debug "Loading libraries(except appearance)..."
LIB="${BASH_IT}/lib/*.bash"
APPEARANCE_LIB="${BASH_IT}/lib/appearance.bash"
for _bash_it_config_file in $LIB
do
  if [ "$_bash_it_config_file" != "$APPEARANCE_LIB" ]; then

    BASH_IT_LOG_PREFIX="library: ${_bash_it_config_file}"  # TODO - strip path prefix and .bash suffix

    # shellcheck disable=SC1090
    source "$_bash_it_config_file"
  fi
done

Here, each library gets the context (prefix) for free and only has to worry about logging messages.

Just a few of these sprinkled throughout the bash-it core code would go a long way.

[nwinkler]

Yes, I agree with @davidpfarrell - setting the prefix variable in the loader code loops (in reloader.bash) would take care of a good chunk of the work. Together with the log message in _command_exists, it should provide good initial coverage.

For the reloader code, it would imagine it working like this:

• Print a debug message about loading stuff from the enabled directory.
• For each found file/link:
  ** Print a debug message about loading that file
  ** Set the prefix variable to something like plugin: $plugin_name - getting the plugin_name from the file name should probably be provided in a function - don't think we have that yet. The bash-it.completion.bash file uses this: basename $f | sed -e 's/\(.*\)\..*\.bash/\1/g' | sed -e "s/^[0-9]*---//g"
  ** Load the file
• After the loop reset the prefix variable to its previous value

Thoughts?

[davidpfarrell]

The bash-it.completion.bash file uses this: basename $f | sed -e 's/\(.*\)\..*\.bash/\1/g' | sed -e "s/^[0-9]*---//g"

What are we, animals !?

# full component filename with path, priority and extension
$ filename="/home/user/.bashit/enabled/123---awesome-component.type.bash"

# filename without path
$ filename=${filename##*/}

123---awesome-component.type.bash

# filename without path or priority
$ filename=${filename##*---}

awesome-component.type.bash

# filename without path, priority or extension
$ filename=${filename%.*.bash}

awesome-component

---

After the loop reset the prefix variable to its previous value

This is kinda what my stack idea as meant to address.

I wouldn't want the code at the loop location to hard-code the previous value. We might be able to use a backup variable to store/restore the value, but you'll want the backup variable name to be unique to the loop so that if the call path enters a second loop somewhere that also needs to store/restore the context, it doesn't trash your first backup value.

You could also use this backup variable to abstract global context from the local loops:

# Store global context so we can restore it later
BASH_IT_LOG_PREFIX_BAK_LIB=${BASH_IT_LOG_PREFIX}

for do
    # Add our local context, maintaining global context
    BASH_IT_LOG_PREFIX="${BASH_IT_LOG_PREFIX_BAK_LIB}:library: ${_bash_it_config_file}"
done

# Restore global context before moving on
BASH_IT_LOG_PREFIX=${BASH_IT_LOG_PREFIX_BAK_LIB}

Again, my stack idea was meant to enable these concepts using simpler push/pop semantics.

Overall I think we're heading in a good direction !

-DF

[NoahGorny]

I did not yet implemented stack or even prev backup, but now there are many log messages and the prefix are set up correctly
I might add some tests to see that it works as expected

[nwinkler]

Looks great - I've left some comments, please take a look.

[nwinkler]

Sorry about the back and forth, didn't mean it to be this complicated, but I think it's important that we get this right... Some more review comments.

[nwinkler]

Thanks for working through this - looks great now! Is this ready-to-merge from your perspective?

@davidpfarrell Comments, thoughts?

[NoahGorny]

Thanks so much for reviewing!
I think this is a nice start, and we should start to recommend adding logs to anyone who opens a PR. I think we can merge this, but let's wait for more people to chime in 😄

In any case, we can add more logs to various components whenever we want to

[nwinkler]

Merging this now - we can keep adding more logs as needed.

[nwinkler]

Thanks again for the implementation, @NoahGorny - this is great!

[NoahGorny]

Thanks for merging @nwinkler
Happy to help 😊