[PATCH] fstests: fix error redirection in generic/256

[PATCH] fstests: fix error redirection in generic/256

[Christoph Hellwig]

Not sure if my shell is the problem here, but I need this explicit
redirection to ignore the error output from mkdir and xfs_io, otherwise
the test fails due to the error messages from these commands.

Signed-off-by: Christoph Hellwig <hch@lst.de>

diff --git a/tests/generic/256 b/tests/generic/256
index cfbf790..2db22cd 100755
--- a/tests/generic/256
+++ b/tests/generic/256
@@ -80,7 +80,7 @@ _fill_fs() {
 	# Creation of files or folders
 	# must not be done as root or
 	# reserved blocks will be consumed
-	_user_do "mkdir -p $dir &> /dev/null"
+	_user_do "mkdir -p $dir > /dev/null 2>&1"
 	if [ $? -ne 0 ] ; then
 		return 0
 	fi
@@ -93,7 +93,7 @@ _fill_fs() {
 	while [ $file_size -ge $block_size ]
 	do
 		bytes_written=0
-		_user_do "$XFS_IO_PROG -f -c \"pwrite 0 $file_size\" $dir/$file_count.bin &> /dev/null"
+		_user_do "$XFS_IO_PROG -f -c \"pwrite 0 $file_size\" $dir/$file_count.bin > /dev/null 2>&1"
 
 		if [ -f $dir/$file_count.bin ]
 		then

Re: [PATCH] fstests: fix error redirection in generic/256

[Eryu Guan]

On Sat, Nov 12, 2016 at 08:47:20AM -0800, Christoph Hellwig wrote:
> Not sure if my shell is the problem here, but I need this explicit
> redirection to ignore the error output from mkdir and xfs_io, otherwise
> the test fails due to the error messages from these commands.

That's weird, from bash manpage, "&>" should be equivalent to "> ... 2>&1"

There're many other tests use "&>" as well, do you see such failures
from other tests, such as generic/347?

Thanks,
Eryu

Re: [PATCH] fstests: fix error redirection in generic/256

[Christoph Hellwig]

On Sun, Nov 13, 2016 at 02:39:43AM +0800, Eryu Guan wrote:
> On Sat, Nov 12, 2016 at 08:47:20AM -0800, Christoph Hellwig wrote:
> > Not sure if my shell is the problem here, but I need this explicit
> > redirection to ignore the error output from mkdir and xfs_io, otherwise
> > the test fails due to the error messages from these commands.
> 
> That's weird, from bash manpage, "&>" should be equivalent to "> ... 2>&1"
> 
> There're many other tests use "&>" as well, do you see such failures
> from other tests, such as generic/347?

generic/347 works fine for me, but I'm not sure I hit an error there
which would have to be redirected.

Re: [PATCH] fstests: fix error redirection in generic/256

[Christoph Hellwig]

On Sun, Nov 13, 2016 at 02:39:43AM +0800, Eryu Guan wrote:
> On Sat, Nov 12, 2016 at 08:47:20AM -0800, Christoph Hellwig wrote:
> > Not sure if my shell is the problem here, but I need this explicit
> > redirection to ignore the error output from mkdir and xfs_io, otherwise
> > the test fails due to the error messages from these commands.
> 
> That's weird, from bash manpage, "&>" should be equivalent to "> ... 2>&1"
> 
> There're many other tests use "&>" as well, do you see such failures
> from other tests, such as generic/347?

No.  But 256 keeps on failing for me without this.  Given that it's
just a slightly more verbose syntax is there any reason not to just
apply this patch for now?

Re: [PATCH] fstests: fix error redirection in generic/256

[Eryu Guan]

On Mon, Jan 09, 2017 at 05:40:08AM -0800, Christoph Hellwig wrote:
> On Sun, Nov 13, 2016 at 02:39:43AM +0800, Eryu Guan wrote:
> > On Sat, Nov 12, 2016 at 08:47:20AM -0800, Christoph Hellwig wrote:
> > > Not sure if my shell is the problem here, but I need this explicit
> > > redirection to ignore the error output from mkdir and xfs_io, otherwise
> > > the test fails due to the error messages from these commands.
> > 
> > That's weird, from bash manpage, "&>" should be equivalent to "> ... 2>&1"
> > 
> > There're many other tests use "&>" as well, do you see such failures
> > from other tests, such as generic/347?
> 
> No.  But 256 keeps on failing for me without this.  Given that it's
> just a slightly more verbose syntax is there any reason not to just
> apply this patch for now?

Ok, I've queued it up for next update.

Thanks,
Eryu

Re: [PATCH] fstests: fix error redirection in generic/256

[Eryu Guan]

On Tue, Jan 10, 2017 at 11:46:05AM +0800, Eryu Guan wrote:
> On Mon, Jan 09, 2017 at 05:40:08AM -0800, Christoph Hellwig wrote:
> > On Sun, Nov 13, 2016 at 02:39:43AM +0800, Eryu Guan wrote:
> > > On Sat, Nov 12, 2016 at 08:47:20AM -0800, Christoph Hellwig wrote:
> > > > Not sure if my shell is the problem here, but I need this explicit
> > > > redirection to ignore the error output from mkdir and xfs_io, otherwise
> > > > the test fails due to the error messages from these commands.
> > > 
> > > That's weird, from bash manpage, "&>" should be equivalent to "> ... 2>&1"
> > > 
> > > There're many other tests use "&>" as well, do you see such failures
> > > from other tests, such as generic/347?
> > 
> > No.  But 256 keeps on failing for me without this.  Given that it's
> > just a slightly more verbose syntax is there any reason not to just
> > apply this patch for now?
> 
> Ok, I've queued it up for next update.

I need to do some tweaks on this patch, generic/256 has been updated and
patch didn't apply cleanly. I replaced all "&>" with "> ... 2>&1",
though some of them won't generate any output.

Thanks,
Eryu

From: Christoph Hellwig <hch@lst.de>
Date: Sat, 12 Nov 2016 08:47:20 -0800
Subject: [PATCH] generic/256: fix error redirection

Not sure if my shell is the problem here, but I need this explicit
redirection to ignore the error output from mkdir and xfs_io,
otherwise the test fails due to the error messages from these
commands.

Signed-off-by: Christoph Hellwig <hch@lst.de>
---
 tests/generic/256 | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tests/generic/256 b/tests/generic/256
index 63f2d4f..5327c33 100755
--- a/tests/generic/256
+++ b/tests/generic/256
@@ -81,10 +81,10 @@ _test_full_fs_punch()
                exit 1
        fi
 
-       rm -f $file_name &> /dev/null
+       rm -f $file_name > /dev/null 2>&1
 
        $XFS_IO_PROG -f -c "pwrite 0 $file_len" \
-               -c "fsync" $file_name &> /dev/null
+               -c "fsync" $file_name > /dev/null 2>&1
        chmod 666 $file_name
 
        # All files are created as a non root user to prevent reserved blocks
@@ -111,8 +111,8 @@ _test_full_fs_punch()
 }
 
 # Make a small file system to fill
-_scratch_unmount &> /dev/null
-_scratch_mkfs_sized $(( 1536 * 1024 * 1024 )) &> /dev/null
+_scratch_unmount > /dev/null 2>&1
+_scratch_mkfs_sized $(( 1536 * 1024 * 1024 )) > /dev/null 2>&1
 _scratch_mount
 # Test must be able to write files with non-root permissions
 chmod 777 $SCRATCH_MNT

Re: [PATCH] fstests: fix error redirection in generic/256

[Eryu Guan]

On Mon, Jan 09, 2017 at 05:40:08AM -0800, Christoph Hellwig wrote:
> On Sun, Nov 13, 2016 at 02:39:43AM +0800, Eryu Guan wrote:
> > On Sat, Nov 12, 2016 at 08:47:20AM -0800, Christoph Hellwig wrote:
> > > Not sure if my shell is the problem here, but I need this explicit
> > > redirection to ignore the error output from mkdir and xfs_io, otherwise
> > > the test fails due to the error messages from these commands.
> > 
> > That's weird, from bash manpage, "&>" should be equivalent to "> ... 2>&1"
> > 
> > There're many other tests use "&>" as well, do you see such failures
> > from other tests, such as generic/347?
> 
> No.  But 256 keeps on failing for me without this.  Given that it's
> just a slightly more verbose syntax is there any reason not to just
> apply this patch for now?

BTW, are you using Debian, or your default shell is not bash? If so, I
guess you may hit this

https://www.spinics.net/lists/fstests/msg00686.html

Changing the default shell to bash for fsgqa user should do the work for
you, I guess.

Thanks,
Eryu

Re: [PATCH] fstests: fix error redirection in generic/256

[Christoph Hellwig]

On Tue, Jan 10, 2017 at 12:27:01PM +0800, Eryu Guan wrote:
> BTW, are you using Debian, or your default shell is not bash? If so, I
> guess you may hit this

Yes, this is debian with dash.

> 
> https://www.spinics.net/lists/fstests/msg00686.html
> 
> Changing the default shell to bash for fsgqa user should do the work for
> you, I guess.

I don't think that's a good idea.  But option 2) from Ted's list to
use a specific shell for executions is a good idea.  I'll look into
that.