[LTP] test.sh and ROD redirection

[LTP] test.sh and ROD redirection

[Cyril Hrubis]

Hi!
As I've been doing last minute fixes to shell testcases I've stambled
upon this problem. We have a couple of places that do:

ROD echo foo > bar

And while this works fine if the command executes successfully it writes
the error message to the file bar on failure as well (since the part
that gets to the ROD as $@ is the 'echo foo' while the '> bar' is parsed
by the shell.

One solution would be redirecting the messages from tst_* to stderr, so
we would be able to at least see the error message, but this wouldn't
catch errors when we cannot write to the 'bar' (since echo foo would
executed successfully anyway).

Another solution would be to create ROD_ECHO and ROD_CAT and change ROD
to abort if anybody tries to use it with these two. Which solves our
usage pattern but this is clumsy and still broken as anyone can redirect
output from ROD anyway.

Is there a elegant solution to this problem that I'm missing?

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] test.sh and ROD redirection

[Alexey Kodanev]

Hi,
On 01/21/2016 04:51 PM, Cyril Hrubis wrote:
> Hi!
> As I've been doing last minute fixes to shell testcases I've stambled
> upon this problem. We have a couple of places that do:
>
> ROD echo foo > bar
>
> And while this works fine if the command executes successfully it writes
> the error message to the file bar on failure as well (since the part
> that gets to the ROD as $@ is the 'echo foo' while the '> bar' is parsed
> by the shell.
>
> One solution would be redirecting the messages from tst_* to stderr, so
> we would be able to at least see the error message, but this wouldn't
> catch errors when we cannot write to the 'bar' (since echo foo would
> executed successfully anyway).
This won't work in case of simple file creation: ROD >file. Quotation 
marks seem to
help in this case with ROD.

./testcases/network/nfs/nfs_stress/nfs03:            ROD >file$j$k

can be changed to ROD ">file$j$k"

> Another solution would be to create ROD_ECHO and ROD_CAT and change ROD
> to abort if anybody tries to use it with these two. Which solves our
> usage pattern but this is clumsy and still broken as anyone can redirect
> output from ROD anyway.

Could be just one ROD_RED that accepts parameters in this way: 1st for 
exec and
the others to set after '>' redirection.

ROD_RED()
{
     $1 > ${@:2}
     if [ $? -ne 0 ]; then
     ....
}

ROD_RED "echo 0" "file"

Best regards,
Alexey

>
> Is there a elegant solution to this problem that I'm missing?

[LTP] test.sh and ROD redirection

[Cyril Hrubis]

Hi!
> > As I've been doing last minute fixes to shell testcases I've stambled
> > upon this problem. We have a couple of places that do:
> >
> > ROD echo foo > bar
> >
> > And while this works fine if the command executes successfully it writes
> > the error message to the file bar on failure as well (since the part
> > that gets to the ROD as $@ is the 'echo foo' while the '> bar' is parsed
> > by the shell.
> >
> > One solution would be redirecting the messages from tst_* to stderr, so
> > we would be able to at least see the error message, but this wouldn't
> > catch errors when we cannot write to the 'bar' (since echo foo would
> > executed successfully anyway).
> This won't work in case of simple file creation: ROD >file. Quotation 
> marks seem to help in this case with ROD.
> 
> ./testcases/network/nfs/nfs_stress/nfs03:            ROD >file$j$k
> 
> can be changed to ROD ">file$j$k"

You lost me here. All I wanted to do is:

--- a/testcases/lib/test.sh
+++ b/testcases/lib/test.sh
@@ -47,7 +47,7 @@ tst_resm()
 
        local ret=$1
        shift
-       echo "$TCID $TST_COUNT $ret : $@"
+       echo "$TCID $TST_COUNT $ret : $@" >&2

This should not break anything. And maybe this is a good idea regardless the
original problem.

> > Another solution would be to create ROD_ECHO and ROD_CAT and change ROD
> > to abort if anybody tries to use it with these two. Which solves our
> > usage pattern but this is clumsy and still broken as anyone can redirect
> > output from ROD anyway.
> 
> Could be just one ROD_RED that accepts parameters in this way: 1st for 
> exec and
> the others to set after '>' redirection.
> 
> ROD_RED()
> {
>      $1 > ${@:2}
>      if [ $? -ne 0 ]; then
>      ....
> }
> 
> ROD_RED "echo 0" "file"

This sounds good, but I would like to have the file as single argument
so that we do not have to quote the command in question. The easiest
solution would be to have the file to be the first argument, but that is
counter intuitive, so I would rather go with the last even if the code
ends up far more complicated.

Another option would be inventing our special syntax for redirecting for
ROD. Use for example % and threat it like > i.e. split $@ on % and
redirect the output to whatever is found after % which shouldn't be
much more complicated than separating last parameter from $@...

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] test.sh and ROD redirection

[Cyril Hrubis]

Hi!
> Another option would be inventing our special syntax for redirecting for
> ROD. Use for example % and threat it like > i.e. split $@ on % and
> redirect the output to whatever is found after % which shouldn't be
> much more complicated than separating last parameter from $@...

What about this one:

diff --git a/testcases/lib/test.sh b/testcases/lib/test.sh
index 074be74..ef2af14 100644
--- a/testcases/lib/test.sh
+++ b/testcases/lib/test.sh
@@ -214,7 +214,29 @@ ROD_SILENT()
 
 ROD()
 {
-	$@
+	local cmd
+	local arg
+	local file
+	local flag
+
+	for arg; do
+		if [ "$arg" == ">" ]; then
+			flag=1
+			continue
+		fi
+
+		if [ -n "$flag" ]; then
+			break
+		fi
+		cmd="$cmd $arg"
+	done
+
+	if [ -n "$flag" ]; then
+		$cmd > $arg
+	else
+		$@
+	fi
+
 	if [ $? -ne 0 ]; then
 		tst_brkm TBROK "$@ failed"
 	fi


It's called as: 'ROD echo a \> b', the reason for choosing \> is that
the error message will contain '>' instead of some strange char as %.

I.e. doing 'ROD echo a \> /proc/cpuinfo' yields:

test.sh: line 235: /proc/cpuinfo: Permission denied
foo 1 TBROK : echo b > /proc/cpuinfo failed

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] test.sh and ROD redirection

[Alexey Kodanev]

Hi,
On 01/25/2016 04:45 PM, Cyril Hrubis wrote:
> Hi!
>> Another option would be inventing our special syntax for redirecting for
>> ROD. Use for example % and threat it like > i.e. split $@ on % and
>> redirect the output to whatever is found after % which shouldn't be
>> much more complicated than separating last parameter from $@...
> What about this one:
>
> diff --git a/testcases/lib/test.sh b/testcases/lib/test.sh
> index 074be74..ef2af14 100644
> --- a/testcases/lib/test.sh
> +++ b/testcases/lib/test.sh
> @@ -214,7 +214,29 @@ ROD_SILENT()
>   
>   ROD()
>   {
> -	$@
> +	local cmd
> +	local arg
> +	local file
> +	local flag
> +
> +	for arg; do
> +		if [ "$arg" == ">" ]; then

I would change it to
         if [ "${arg:0:1}" == ">" ]; then
                 arg=${arg:1}

in case '\>' is not separated by space.

e.g.:
ROD echo a \>/proc/cpuinfo

> +			flag=1
> +			continue
May be break here, so we don't need the next if block.

> +		fi
> +
> +		if [ -n "$flag" ]; then
> +			break
> +		fi
> +		cmd="$cmd $arg"

But what if the rest of args has something else, e.g. 2>&1 ?

> +	done
> +
> +	if [ -n "$flag" ]; then
> +		$cmd > $arg
> +	else
> +		$@
> +	fi
> +
>   	if [ $? -ne 0 ]; then
>   		tst_brkm TBROK "$@ failed"
>   	fi
>
>
> It's called as: 'ROD echo a \> b', the reason for choosing \> is that
> the error message will contain '>' instead of some strange char as %.
>
> I.e. doing 'ROD echo a \> /proc/cpuinfo' yields:
>
> test.sh: line 235: /proc/cpuinfo: Permission denied
> foo 1 TBROK : echo b > /proc/cpuinfo failed

Best regards,
Alexey

[LTP] test.sh and ROD redirection

[Cyril Hrubis]

Hi!
> > +	for arg; do
> > +		if [ "$arg" == ">" ]; then
> 
> I would change it to
>          if [ "${arg:0:1}" == ">" ]; then
>                  arg=${arg:1}

That does work only in bash.

The easiest portable way I can come up with is:

	if [ "${arg#\>}" != "$arg" ]; then
		arg=${arg#\>}
	fi

> > +			flag=1
> > +			continue
> May be break here, so we don't need the next if block.

Right.

> > +		fi
> > +
> > +		if [ -n "$flag" ]; then
> > +			break
> > +		fi
> > +		cmd="$cmd $arg"
> 
> But what if the rest of args has something else, e.g. 2>&1 ?

Hmm, we can look for that in the $@ as well but nobody is using ROD with
that at the moment. We can think about this later ideally when there is
need for this.

-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] test.sh and ROD redirection

[Cyril Hrubis]

Hi!
> > +			flag=1
> > +			continue
> May be break here, so we don't need the next if block.

We have to do another loop just to fetch the parameter after the \> if
there is space between \> and path. So the continue should stay.

Full version then would be:

--- a/testcases/lib/test.sh
+++ b/testcases/lib/test.sh
@@ -214,7 +214,35 @@ ROD_SILENT()
 
 ROD()
 {
-       $@
+       local cmd
+       local arg
+       local file
+       local flag
+
+       for arg; do
+               file="${arg#\>}"
+               if [ "$file" != "$arg" ]; then
+                       if [ -n "$file" ]; then
+                               break
+                       fi
+                       flag=1
+                       continue
+               fi
+
+               if [ -n "$flag" ]; then
+                       file="$arg"
+                       break
+               fi
+
+               cmd="$cmd $arg"
+       done
+
+       if [ -n "$file" ]; then
+               $cmd > $file
+       else
+               $@
+       fi
+
        if [ $? -ne 0 ]; then
                tst_brkm TBROK "$@ failed"
        fi



This works both with:

ROD echo a \> file
ROD echo a \>file


-- 
Cyril Hrubis
chrubis@suse.cz

[LTP] test.sh and ROD redirection

[Alexey Kodanev]

On 01/25/2016 08:18 PM, Cyril Hrubis wrote:
> ...
>
> This works both with:
>
> ROD echo a \> file
> ROD echo a \>file
>

Looks good to me!

Best regards,
Alexey

[LTP] test.sh and ROD redirection

[Cyril Hrubis]

Hi!
> Looks good to me!

Ok. I will push this along with documentation and fixed all uses in
tests tomorrow, then tag the release.

-- 
Cyril Hrubis
chrubis@suse.cz