Another issue where new text with a proposed resolution is posted
to the bug, and the bug is then closed within minutes, preventing
any further (in bug report) discussion.

People, please stop doing this - if a new note is added with a proposed
resolution (other than "apply the text in note NNN" perhaps) then leave
the issue open, for at least a week, before closing it (assuming there
are no more substantive comments).

In this one, while the example 3 being added (both of them) will work,
it is (or they are, this applies to both) (or seems to me to be) more
complicated than it needs to be.

That is:

        at now + 1 hour <<EOF
        {
            exec 3>&1
            run-batch-processing 2>&1 >&3 \
                | mailx -E -s "errors during batch processing" mygroup
        } | mailx -s "batch processing output" mygroup
        EOF

could be written as

        at now + 1 hour <<EOF
        {
                run-batch-procesing |
                    mailx -s "batch processing output" mygroup
        } 2>&1 | mailx -E -s "errors during batch processing" mygroup

couldn't it?

Note there are two changes ... splitting the order in which the stdout and
stderr pipes are done, so that natural fd ordering is preserved, and hacks
using duplication onto another fd aren't required (in some cases, though 
probably not usefully here, it also means that any errors during the normal
stdout mail processing are also included in the stderr mail) and second,
avoiding use of the backslash-newline combination for line joining when
there's not really any good reason to do it that way (the change in
indentation is superficial, a result of my re-typing, and irrelevant).

Since 3 is a new example, it can hardly be needed to demonstrate a use
of duplicating onto another fd (ie: explicitly to show how to do that)
or an example using that technique would have been there already (and it
would be one where it really is needed, otherwise all people do is ask
"why that way?")

If the intent of the complicated processing is to avoid the "empty message
body, hope that's OK?" or whatever message it is from mailx from the stdout
mail being sent in the error mail (and perhaps only that), then

        at now + 1 hour <<EOF
        {
                { run-batch-procesing; echo } |
                    mailx -s "batch processing output" mygroup
        } 2>&1 | mailx -E -s "errors during batch processing" mygroup

would avoid that happening, in a harmless way, and what's more demonstrates
the one and only truly safe use of "echo".

kre

  • [1003.1(2016... Austin Group Bug Tracker via austin-group-l at The Open Group
    • Re: [10... Robert Elz via austin-group-l at The Open Group
      • Re:... Richard Hansen via austin-group-l at The Open Group
      • Re:... Robert Elz via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group
    • [1003.1... Austin Group Bug Tracker via austin-group-l at The Open Group

Reply via email to