build-iso-mx: redirecting screen output

[jhsu802701]

I'm having difficulty making sense of the following line of code:

Code: Select all

            main_case  7>&1 1>&2 2>&7 \
                | tee -a $err_file | sed -e "s/^/$red/" -e "s/$/$nc/"

More specifically, I'm having difficulty making sense of the portion of the first line after "main_case" and before the backslash.

I understand in general that any errors in the screen output are directed to the error file ($err_file). I understand in general that the numbers and symbols of the part of the code in question specify details of how the screen output is redirected.

However, I'm having difficulty finding a good reference on any specifics of what it all means. It's not a normal command like "tee" or "sed".

In case you're wondering, what I'd like to do is execute the main_case function differently in the GitHub Workflows environment. My plan is to use an if statement to print the error information on the screen (as well as in the file) in the GitHub Workflows environment. (I've already made changes to the code that apply ONLY in the GitHub Workflows environment.)

[dolphin_oracle]

redirecting output happens all the time, although I got to admit this one made my head spin a little.

basically its combining stderr and stdout into stdout

7 is a new descriptor that redirects to stdout
1 (stdout) is redirected to stderr
2 (stderr) is redirected back to 7, which is essentially stdout now.

basically all of the stdout messages and the stderr messages are redirected into new file descriptor 7, which in turn is already redirected into stdout.

[fehlix]

I'm having difficulty making sense of the following line of code:

Code: Select all

            main_case  7>&1 1>&2 2>&7 \
                | tee -a $err_file | sed -e "s/^/$red/" -e "s/$/$nc/"

More specifically, I'm having difficulty making sense of the portion of the first line after "main_case" and before the backslash.

The first line "swap"'s or toggles stderr with stdout:
A nice attempt to explain what it does is made by our mastermind @BitJam himself (found within the live init) with this picture:

Code: Select all

# Evaluate redirects RIGHT TO LEFT:
#
#  stdout  1 -------.        .---> while, sed, tee ---> screen (stdout)
#                    \      /
#  stderr  2 ---.     `--- / -------------------------> screen (stderr)
#                \        /
#          7      `------'

So after the switch was done, the "old" stderr (2) is now the new stdout and can be processed with tee and sed,
which in this case is done in order to send "old" stderr to a log-file and and colorize the tee-duplicated error-lines send to the screen.

I understand in general that any errors in the screen output are directed to the error file ($err_file). I understand in general that the numbers and symbols of the part of the code in question specify details of how the screen output is redirected.

However, I'm having difficulty finding a good reference on any specifics of what it all means. It's not a normal command like "tee" or "sed".

Hmm.., that's normal shell file descriptor handling ... ( admitally for the advanced use case)

In case you're wondering, what I'd like to do is execute the main_case function differently in the GitHub Workflows environment. My plan is to use an if statement to print the error information on the screen (as well as in the file) in the GitHub Workflows environment. (I've already made changes to the code that apply ONLY in the GitHub Workflows environment.)

OK, I must admit I have never used "GitHub Workflows", so in this respect not really sure what you are talking about.
But the above file descriptor "switch" magic combined with tee and sed, does already what you want to do:
"to print the error information on the screen (as well as in the file)".
So I'm not sure what you are looking for, but this might be simply related about, that I'm having no knowledge of "GitHub Workflows". (May be you give us a quick introduction of how to use it and what it is good for.)
Thanks

[jhsu802701]

fehlix: Thanks for the more detailed explanation of the code. However, GitHub Workflows suppresses the error output and thus prevents me from seeing which line of code triggered the error. So I'll have to change the code to perform the same step somewhat differently in the GitHub Workflows environment. You can see that the build-iso-mx script has several instances of if/then/else statements that begin with:

Code: Select all

if [ -n "$GITHUB_WORKSPACE" ]

This allows the GitHub Workflows environment to bypass certain lines of code that trigger errors.

I've been adding GitHub Workflows continuous integration with these goals in mind:
1. To provide assurance that the build script works and warnings about any problems
2. To provide a safeguard against the infamous "but it works on my machine" problem
3. To aid the process of onboarding anyone new to the team
4. To automatically upload the generated ISO file

[fehlix]

fehlix: Thanks for the more detailed explanation of the code. However, GitHub Workflows suppresses the error output and thus prevents me from seeing which line of code triggered the error.

If that's "special" restriction of the "GitHub Workflows" environment,
just combine both after colorized adjustment have been made to the error stream.

So I'll have to change the code to perform the same step somewhat differently in the GitHub Workflows environment.
You can see that the build-iso-mx script has several instances of if/then/else statements that begin with:

Code: Select all

if [ -n "$GITHUB_WORKSPACE" ]

I'm not sure what you mean, are you saying you already changing the original MX Linux build-iso script?
Suggest to work on another branch or at least on a copy of the original script, until you are happy it works and can demonstrate how to use it? This is just to avoid any side effect by adding your adjustments.

This allows the GitHub Workflows environment to bypass certain lines of code that trigger errors.

I've been adding GitHub Workflows continuous integration with these goals in mind:
1. To provide assurance that the build script works and warnings about any problems
2. To provide a safeguard against the infamous "but it works on my machine" problem
3. To aid the process of onboarding anyone new to the team
4. To automatically upload the generated ISO file

I'm surely understand the general context, but as I said I never used or know how to setup "GW", so I'm not able to reflect on this.

[Adrian]

Suggest to work on another branch or at least on a copy of the original script, until you are happy it works and can demonstrate how to use it? This is just to avoid any side effect by adding your adjustments.

I second this.

[dolphin_oracle]

I would like to see this work moved out of main and into a testing branch.

and main reverted back to a known state. in hindsight, a test branch is where this belonged in the first place.