feat: separate and enhance logging capabilities.

[pac-rirl]

I have completely and blatant RIPPED-OFF your logging and I am using (the modification) in some of my own projects.

This PR separates out the logging into its own script (via source) and introduces some additional functionalities.

1. Adding an ISO8601 Local TZ timestamp (with ms) to each of the log entries
2. Add functionality that allows the use of 'conditional logging' blocks.

Additional block logging

# Supports the following usage:
# is_INFO, is_WARN, is_DEBUG, and is_FATAL
if is_DEBUG; then
  # a block of things to log at LOG_LEVEL_DEBUG
   DEBUG  "1) inside the DEBUG logging block"
   DEBUG "2) inside the DEBUG logging block"
fi

In the spirit of the open source community I am want to contribute some thing back.

[pac-rirl]

I hope you might find these contributions useful. I also want to thank you.

[carlocorradini]

I will check it later because I am currently on vacation ⛱️☀️🍹

[pac-rirl]

Thank you > no rush.
I do want to check with you that its okay by you that I use the inline.sh in some applications I work on.

[carlocorradini]

@pac-rirl
First of all, thank you for your contribution 🥳
However, I have a few questions or clarifications:

1. Why do you want to separate logging from the main script?
   This is a utility script that should not have "dependencies" to prevent unnecessary complexity (use the script as is).
   If we really want to add "sources" (source or .), we need to write an appropriate CI/CD to inline the inline.sh script itself (like compiling the compiler with itself), and then create a release with the inlined script.
2. Inline is POSIX compliant.
   However, inline-logging.sh contains #!/usr/bin/env bash, which implies BASH:
   

   inline/inline-logging.sh

   Line 1 in 4b72b32

   #!/usr/bin/env bash

3. I like the concept of using is_[LOGGING_LEVEL] to simply determine whether the logging level is enabled.
   To be consistent with the naming of other logging functions, I want to prepend it with log (log_is_FATAL or log_is_fatal).
4. When logging messages, I like the idea to use ISO8601 and the local timezone/timestamp.
   We need to check if most systems support or have date +%FT%T.%3NZ; otherwise, disable printing ISO8601 timestamps.
   Additionally, include a configuration flag to turn it off (it's on by default).

Thanks 🤗
Let me know what you think 🤯

[carlocorradini]

@pac-rirl Any update?

[pac-rirl]

Sorry, no update. I’ve been super super busy. From: Carlo Corradini ***@***.***> Sent: Friday, October 25, 2024 2:11 PM To: carlocorradini/inline ***@***.***> Cc: Rick Landon ***@***.***>; Mention ***@***.***> Subject: Re: [carlocorradini/inline] feat: separate and enhance logging capabilities. (PR #69) EXTERNAL EMAIL: This email originated from a sender outside of the organization. Use caution when responding to requests, clicking links, or opening attachments.

…

________________________________ @pac-rirl<https://urldefense.com/v3/__https:/github.com/pac-rirl__;!!CHviNMnO-bCPlQ!fn19J75ZiUXcoXZlwJJOkRHcthuNw2JuwGo6_QZ5CAgAb3_94fS4mtOgn8iwIfBiEEeSnrGlhEK7InyWs57VlRSbTiHpKZg$> Any update? — Reply to this email directly, view it on GitHub<https://urldefense.com/v3/__https:/github.com/carlocorradini/inline/pull/69*issuecomment-2438868207__;Iw!!CHviNMnO-bCPlQ!fn19J75ZiUXcoXZlwJJOkRHcthuNw2JuwGo6_QZ5CAgAb3_94fS4mtOgn8iwIfBiEEeSnrGlhEK7InyWs57VlRSb6PMoSss$>, or unsubscribe<https://urldefense.com/v3/__https:/github.com/notifications/unsubscribe-auth/A2OIO44PVJFDB5NYGR76LX3Z5KXW7AVCNFSM6AAAAABMMR3O4CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMZYHA3DQMRQG4__;!!CHviNMnO-bCPlQ!fn19J75ZiUXcoXZlwJJOkRHcthuNw2JuwGo6_QZ5CAgAb3_94fS4mtOgn8iwIfBiEEeSnrGlhEK7InyWs57VlRSb2XKxQdE$>. You are receiving this because you were mentioned.Message ID: ***@***.******@***.***>>

________________________________ The content of this email is confidential and intended only for the recipient specified in this message. It is strictly forbidden to share any part of this message with any other person without the sender's written consent. If you received this message by mistake, please reply to this message and follow with its deletion so that we can ensure such a mistake does not occur in the future.