Log all errors at end

[abmusse]

Original report by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

Currently any failed commands will output at the time of failure and there isn't a summary report.

For example, I had this happen today.

cp /QOpenSys/usr/icu4c/lib/libicutest.a /QOpenSys/ibmichroot_containers/node2/QOpenSys/usr/icu4c/lib/libicutest.a
cp: /QOpenSys/usr/icu4c/lib/libicutest.a: A file or directory in the path name does not exist.

I saw the above error only because I scrolled through many lines of logs.

I propose we store failures in an array and print them out at the very end.

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

I propose we store failures in an array and print them out at the very end.

Mmm ... realm of opinion. I vote no change. See alternative.

1. Some want messages as tasks run (interactive).

2. Some want all messages at the end (batch).

alternative ... let shells be shells ... (my vote)

Perhaps better user simply redirects stdout/stderr to a file when in 'batch'. This way you can use natuaral shell utilities for all manner of post run processing, like grep or cat for errors in file 'uncle_error.txt'.

#!bash

== run (Note '&>' file redirects both stdout/stderr to file)
bash-4.3$ ./pkg_setup.sh pkg_perzl_bash-4.3.lst &> uncle_error.txt 

== run any utility to find errors (cat, grep, head, tail, etc.)
bash-4.3$ head uncle_error.txt 
**********************
Live IBM i session (changes made).
**********************
PATH=/QOpenSys/usr/bin:/QOpenSys/usr/sbin:/opt/freeware/bin
LIBPATH=/QOpenSys/usr/lib:/opt/freeware/lib
x          IBM i setup (package_setup_rpm)
x          restore -xvqf rpm.rte
New volume on rpm.rte:
 Cluster 51200 bytes (100 blocks).
    Volume number 1

[abmusse]

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

My main need is to get a concise list of the errors. My concerning about posthumous searching is that our search criteria would miss unexpected ones. Maybe we start a script where we store an array of regular expressions as we learn about them. Then that script can be run against the output log.

$ showerrors.sh chroot_creation001.log

cp: /QOpenSys/usr/icu4c/lib/libicutest.a: A file or directory in the path name does not exist.

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

My main need is to get a concise list of the errors. My concerning about posthumous searching is that our search criteria would miss unexpected ones.

Actually, 'unexpected' is hallmark reason for NOT trying to collect 'only errors'. That, is, you are making my shell be shell point for me. Specifically, if use use redirect stdout/stderr '&> uncle_error.txt', then you can build any type of filter to 'posthumous search' based on whatever criteria suits your fancy. The point is, using redirect you get ALL the errors .. and everything else out of stdout/stderr.

Basically, I vote no (again).

[abmusse]

Original comment by Aaron Bartell (Bitbucket: aaronbartell, GitHub: aaronbartell).

---

I want to make sure you understood what I was recommending because I believe it aligns with what you would vote for. Specifically, we go the route of redirecting output to a .log file, as suggested. In addition, we create another shell script named scan_log_for_errors.sh that stores a list of types of errors that we could use to scan log files.

Something like the following can be put in the new shell script, though there would be a much more complex regex that would include all the potential errors that could happen.

find . -type f | xargs grep -i "not exist"

[abmusse]

Original comment by Tony Cairns (Bitbucket: rangercairns, GitHub: rangercairns).

---

... we create another shell script named scan_log_for_errors.sh that stores a list of types of errors that we could use to scan log files.

Correct.

... errors that could happen

However, creating 'could happen' convenience script scan_log_for_errors.sh, implying everyone understood output seems a big task. Maybe icons for quick visual reference? ... green clovers means rpm installed, pink hearts means PASE binary issue, orange stars means dependency issue, yellow moons means authority issue ... wait ... mmm ... always after me Lucky Charms.