Util-Linux package development
 help / color / mirror / Atom feed
From: Ruediger Meier <sweet_f_a@gmx.de>
To: Stanislav Brabec <sbrabec@suse.cz>
Cc: util-linux@vger.kernel.org
Subject: Re: tests: strange redirection
Date: Mon, 15 Feb 2016 12:54:22 +0100	[thread overview]
Message-ID: <201602151254.22589.sweet_f_a@gmx.de> (raw)
In-Reply-To: <56BCE1F6.9000805@suse.cz>

On Thursday 11 February 2016, Stanislav Brabec wrote:
> I just found
> 2>&1 >> $TS_OUTPUT
> in many tests.
>
> I am not sure, whether it does what is expected:
>
> 2>&1 >> $TS_OUTPUT
> which does:
> Redirect stdout to $TS_OUTPUT and redirect stderr to stdout.
>
> I guess that it is most probably intended to be:
> >> $TS_OUTPUT 2>&1
>
> which does:
> Redirect stdout and stderr to $TS_OUTPUT.
>
> Here is a global fix:
> cd tests/ts
> sed -i 's:2>\&1 >> \$TS_OUTPUT:>> $TS_OUTPUT 2>\&1:g' $(fgrep -rl
> '2>&1 >> $TS_OUTPUT' .)
>
> I ran a check, and it seems, that there could be some minor issues
> in:
>
> MD raid1 (whole-disks)
> mount-by-uuid
> mount-flags
> x-mount.mkdir
> fstab-label
> fstab-uuid
>
> The current version of redirection can cause false positive result of
> the test.

I remember that one day I was also about to fix that redirections. But 
after thinking about this for a while I've left it as it is. 
Unfortunately I don't remember why :)

Could be that sometimes we will get harmless warnings which should be 
ignored. Also a minor advantage was that our mount tests could survive 
running with LIBMOUNT_DEBUG=all.

Anyways, checking stderr too is IMO a good idea.

BTW I would even like to add checking return values of any used commands 
(not only for mount tests) like we did in 45eb5b29 for blkdiscard for 
example.

cu,
Rudi

      parent reply	other threads:[~2016-02-15 11:54 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-02-11 19:33 tests: strange redirection Stanislav Brabec
2016-02-11 19:40 ` [PATCH] tests: fix redirection Stanislav Brabec
2016-02-15 11:54 ` Ruediger Meier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=201602151254.22589.sweet_f_a@gmx.de \
    --to=sweet_f_a@gmx.de \
    --cc=sbrabec@suse.cz \
    --cc=util-linux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox