Inspired

[MAFoElffen]

I was holding the commit until I got some feedback first... But pushed it just now so you can see them.

mafoelffen@ubuntu:~/git/MAFoElffen1/system-info$ git add system-info
mafoelffen@ubuntu:~/git/MAFoElffen1/system-info$ git commit -m "Put debug code back in as comments."
[main 0a1b047] Put debug code back in as comments.
 1 file changed, 13 insertions(+), 3 deletions(-)
mafoelffen@ubuntu:~/git/MAFoElffen1/system-info$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 454 bytes | 454.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: This repository moved. Please use the new location:
remote:   https://github.com/Mafoelffen1/system-info.git
To https://github.com/MAFoElffen1/system-info
   ebc6e10..0a1b047  main -> main

That is with that DEBUG/TEST code still commented out in the paste methods and Paster()...

That is without what was mentioned in post #309 as an addition.

[TheFu]

It is common to include "instrumentation" in code that can be turned up and down. We've all see how syslog allows errors to be sent to a different log file compared to warnings and informational messages.

A common method is to have 1 variable control the logging level ... 1=errors only, 2=errors and warnings, 3=errors, warnings, and information, 4= .... I haven't looked for a pattern to that solution in bash, but there must be something. Or just use the -x option and tee all the output to a log file for the session. Nothing hidden when we do that.

There are options.

Or did I miss the point of debug messages?

I vaguely remember having a discussion about test cases for software so automatic tests can be run before any code gets pushed to the master repo. Any thoughts on that?

[MAFoElffen]

@TheFU:

Exactly.

In Python, like in some of my scripts for the Ama-gi LiveCD, I use the Python module logging.logger... With that I can send what I want from different levels to different objects. Like what is displayed on screen, to error, to a warning, to a debugger. Whatever.

In BASH, well... LOL. I haven't found an easy way around that yet. (Where is is not using more memory and using more resources.) I have to keep an open mind and use some imagination to figure out what it is, and try to figure out how to redirect it to replicate what I can already do in other languages easily and apply it to/within a shell, and what it can do, based on the types of things I can capture and predict.

I can easily create a "script" log file to capture what variables and exit codes were found and pasted... To create and keep track of the undercover's what-may-be's... Just means more lines of underlying code. LOL I can write a logger function to do that... Or do I have enough messaging already to tell us what is going on without that?

I can already tell from what type of message come's up, where it is in the script and the possible why's... But, per-say, if I die... The next person to have to support this...

I'm hoping that some of these mod's I suggested and locking these debug messages down (if or not)... Will bring us to being able to release this soon. I feel we are just about to that point.

[guiverc]

I re-grabbed system-info from https://github.com/Mafoelffen1/system-info/ and followed the instructions under "Run from CLI", some comments are

MOKUTIL

"mokutil" could not be found.
Required basic Linux utilities not found.

The first line is in red, so is very bright, and the package `mokutil` is not required as I have no issues with this legacy non-uEFI (and impish) install.

I tested a couple of recent impish QA-installs and they do have mokutil installed (those boxes were non-uEFI too); though I do note a fresh Lubuntu install didn't have `curl` installed; but I felt messages were appropriate (no bright red for just `curl`)

Maybe adding a "Note: if this is an old/legacy box install; this is not a problem" OR MAYBE BETTER a conditional statement in the error message such as

"System-info script required basic Linux utilities not found"

as I fear the message (esp. with red highlight with `mokutil`) could be read as an issue with the box; but I could be wrong.

Duplicated Source entries

This was mentioned/noticed before (Sudodus), as my primary box has duplicates.

In my /etc/apt/sources.list.d/ directory you'll find

guiverc@d960-ubu2:/de2900/ubuntu_64/bionic$    ls -la /etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list*
-rw-r--r-- 1 root root 217 Jun  4 10:04 /etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list
-rw-r--r-- 1 root root 211 Nov 11  2018 /etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list.distUpgrade

Yet the script lists

Sources List from SourcesD:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:

Why I gather is the contents of my files

guiverc@d960-ubu2:/de2900/ubuntu_64/bionic$   cat /etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list
#-deb http://ppa.launchpad.net/audio-recorder/ppa/ubuntu artful main
#-deb http://ppa.launchpad.net/audio-recorder/ppa/ubuntu bionic main
#-deb-src http://ppa.launchpad.net/audio-recorder/ppa/ubuntu artful main

The duplicate is explained away by my nature of never deleting anything (same contents in the .distUpgrade file thus the six)

[sudodus]

I tested the current version of the system-info script in two computers, one with version 18.04.5 LTS and one with 20.04.3 LTS and it works well

You may consider some further comments from us about the 'look and feel', high-lighting etc. But the basic function seems robust now.

Thanks for the patience with us, @MAFoElffen. You made a good tool

[MAFoElffen]

MOKUTIL
The first line is in red, so is very bright, and the package `mokutil` is not required as I have no issues with this legacy non-uEFI (and impish) install.

I created a $orangeback - Orange Background Ansi for this prompt and changed the wording for this to display as

 $orangeback \"${Program}\" could not be found. This program is suggested.$resetvid
 If this is older hardware that is 'Legacy Only BIOS', then this can be ignored.

#and below on the overall followup

 The Script 'system-info' uses  some very basic Linux utilities.
 Some of these utilities were not found.

Duplicated Source entries
This was mentioned/noticed before (Sudodus), as my primary box has duplicates.

In my /etc/apt/sources.list.d/ directory you'll find

guiverc@d960-ubu2:/de2900/ubuntu_64/bionic$    ls -la /etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list*
-rw-r--r-- 1 root root 217 Jun  4 10:04 /etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list
-rw-r--r-- 1 root root 211 Nov 11  2018 /etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list.distUpgrade

Yet the script lists

Sources List from SourcesD:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:
/etc/apt/sources.list.d/audio-recorder-ubuntu-ppa-artful.list:

I'm seeing that it is displaying the file names that are there, with no contents from them, because of the filter on that- It first strips out any commented lines, then strips out any blank lines, then formats... But since there was nothing left to display, it just showed the file names with no contents. Hmmm. That still makes sense to me.

To do that differently:
I would have to read each file individually while keeping the file name > Process what needed to be displayed from that file. > Count the lines of what is left to display, before determining if it is to be displayed... But it would not show that there 'are' files that are empty (such as everything commented out like yours), unless I also added the logic to display that as an alternate message to indicate that.

Do you all want me to change it in that manner? We know what that means when it does that... Do I need to spell that out clearer by breaking that apart and adding the logic to that?

[MAFoElffen]

Okay... Updated. Changed messages. Added $orangeback. Rewrote GetRepositiories(). Updated Version number/date.

mafoelffen@ubuntu:~/git/MAFoElffen1/system-info$ git add system-info

mafoelffen@ubuntu:~/git/MAFoElffen1/system-info$ git commit -m "Changed messagesfor prereq's and mokutil. Rewrote GetRepositories()."
[main bb144f4] Changed messagesfor prereq's and mokutil. Rewrote GetRepositories().
 1 file changed, 38 insertions(+), 3 deletions(-)

mafoelffen@ubuntu:~/git/MAFoElffen1/system-info$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 881 bytes | 881.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: This repository moved. Please use the new location:
remote:   https://github.com/Mafoelffen1/system-info.git
To https://github.com/MAFoElffen1/system-info
   0a1b047..bb144f4  main -> main

mafoelffen@ubuntu:~/git/MAFoElffen1/system-info$ git add system-info

mafoelffen@ubuntu:~/git/MAFoElffen1/system-info$ git commit -m "Updated Version number/date."
[main f5084a6] Updated Version number/date.
 1 file changed, 1 insertion(+), 1 deletion(-)

mafoelffen@ubuntu:~/git/MAFoElffen1/system-info$ git push
Enumerating objects: 5, done.
Counting objects: 100% (5/5), done.
Delta compression using up to 4 threads
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 313 bytes | 313.00 KiB/s, done.
Total 3 (delta 2), reused 0 (delta 0)
remote: Resolving deltas: 100% (2/2), completed with 2 local objects.
remote: This repository moved. Please use the new location:
remote:   https://github.com/Mafoelffen1/system-info.git
To https://github.com/MAFoElffen1/system-info
   bb144f4..f5084a6  main -> main

[MAFoElffen]

This is a prototype/test script for some proposed information possibly to be included in "Other Details"

#!/bin/bash

## MAFoElffen <mafoelffen@ubuntu.com> 2021.09.14
# HWE related functions
#    - Proposed


######
# Functions
######

function GetHweKernels()
{
    show_kernels=$(apt-cache show linux-generic-hwe-$(lsb_release -sr) \
        | awk '/Depends:/ {print "For HWE Package: " $2 ", Kernel Version: " $4}' \
        | sed -e 's/..$//' -e 's/~.*//')
    echo -e "$show_kernels"
}

function CheckHwe()
{
    return_status=$(dpkg -s linux-generic-hwe-$(lsb_release -sr) 2>&1 )
    for line in $return_status
    do
        if [ "$line" == *"Status:"* ]
        then 
            echo -e "Package linux-generic-hwe-$(lsb_release -sr) is installed."
        elif [ "$line" == *"dpkg-query: package"* ]
        then
            echo -e "HWE package linux-generic-hwe-$(lsb_release -sr) was not detected. Please check "
            echo -e "kernel version to verify range"
        fi
    done
}

function CheckIfCertifiedHardwarePlatform()
{
    platform_check=$(ubuntu-drivers list-oem)
    if [ -z $platform_check ]
    then
        echo -e "Ubuntu Certified Hardware Platform. Safe to install "
        echo -e "the Hardware Enablement Stack (HWE)."
    else
        echo -e "Hardware meta packages were listed. Please refrain from manually changing "
        echo -e "the kernel flavours. The Hardware Enablement Stack (HWE) should not be "
        echo -e "installed on this platform. "
    fi
}

######
# Main
######

GetHweKernels
CheckHwe
CheckIfCertifiedHardwarePlatform

I asked if this information would be useful in this report... And got no feedback.

I am not sure if we want to have the last function that uses 'ubuntu-drivers'. Only because I'm Not sure that it is a default installed program... And as I remember, on 18.04, it was from package ubuntu-drivers and in 20.04 it was from ubuntu-drivers-extra... But it tell's a lot if the Kernel is in an HWE series, and the platform indicated that was not wise nor recommended. If it is not a default program, then maybe I should reserve that to the Ama-gi LiveCD where it will be installed and there.

[TheFu]

@TheFU:

Exactly.
.....
I'm hoping that some of these mod's I suggested and locking these debug messages down (if or not)... Will bring us to being able to release this soon. I feel we are just about to that point.

https://gist.github.com/goodmami/6556701 has a simple logging example with 5 levels. I would prefer a single command with the log level included as the first function parameter, but whatever. Doesn't really matter, except to have a way to turn up/down the logging and to have the default to show errors only.

[MAFoElffen]

@TheFu

## License: Public domain; do as you wish

LOL. Okay then...

That is a good start, along the same lines that I described, and you talked about wanting...

Out at the front, the exec redirection, File descriptor 3 is a new/custom file descriptor, which is being defined, and being redirected to stderr (always). In the system-info script I sometimes suppress stderr, and yet sometimes capture the stderr as the condition I want to check for. (Just thinking out loud.) I think what we talked about (you and I) was more along the lines of also selecting whether it is displayed AND/OR to a log file... Where that could be handled with that log() function if there was another argument there and more logic... Instead of file descriptor 3 always being directed to stderr.

As a logger to screen or to log files:
- I would turn the "exec define of the custom file descriptor 3" statement as an argument triggered condition and use that within the log() function... That way it could be redirected to screen, to a log file, or to both.
- it already uses verbosity to show or not, what level it switches on the display of what levels...

Hmmmm. I will play with that and see what I come up with from that. Using the first argument to log() as a variable, then I could shift the level of what is being logged/displayed, in a single swoop. At the least, that will help with testing and debugging.