From: Cyril Hrubis <chrubis@suse.cz>
To: Petr Vorel <pvorel@suse.cz>
Cc: Sebastian Chlad <sebastian.chlad@suse.com>, ltp@lists.linux.it
Subject: Re: [LTP] [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh
Date: Fri, 20 Mar 2026 17:20:17 +0100 [thread overview]
Message-ID: <ab1zwXCUui24rmmC@yuki.lan> (raw)
In-Reply-To: <20260318150252.GA31214@pevik>
Hi!
> > SAFE instead so that the name is closer to the SAFE_XXX macros in C.
>
> Makes sense. I was even thinking on SAFE_CMD, but we use tst_rod.c, not
> tst_cmd.c. OTOH it was obvious that ROD uses tst_rod.c, should it be also
> renamed? What ROD means anyway? run or dye?
Run or die (we are not coloring anything).
And yes it would make sense to rename tst_rod.c to tst_safe_cmd.c or
similar.
> > > +_tst_expect_pass()
> > > +{
> > > + local fnc="$1"
> > > + shift
> > > +
> > > + tst_rod "$@"
>
> > If I remmeber correctly the whole reason why we introduced tst_rod.c was
> > that passing the $@ like this causes the $@ to be evaluated twice and
> > produces unexpected results.
>
> FYI code is copy pasted from tst_test.sh. What do you want me to change?
I've spend a couple of minutes figuring out why we originaly implemented
ROD_BASE() in C.
The problem is that single quotes gets removed as soon as we pass the
parameter.
E.g.: ROD awk '{ print $1 }'
Once we pass that to a shell function the '' disappear, they managed to
keep the { print $1 } to be a single parameter in the list but they are
not there anymore.
And since we were manipulating the parameter list we got, we failed to
reconstruct it correctly in shell since in the next step the { print $1 }
breaks into four separate strings.
As long as we pass the $@ as a whole (even after shift), it does work
since the boundaries of parameters in $@ stay exactly as they were.
TL;DR; The code you copy&pasted is correct, I only misremembered what
was the problem back then.
> > I'm not sure that adding the PASS_BRK and FAIL_BRK is a good idea. I
> > would stick to simple EXPECT_PASS and EXPECT_FAIL. And maybe we can
> > export TST_PASS variable as we do in C to match the API. I think that
> > the closer the C and shell API are the better.
>
> C API usually returns on if (!TST_PASS). I don't like it either, but it cannot
> be shortened much as we don't use functions but macros.
>
> But changing the code in the shell API does not look to me an improvement:
>
> -EXPECT_PASS_BRK ping$TST_IPV6 -c1 -I $lhost $rhost \>/dev/null
> +EXPECT_PASS_BRK ping$TST_IPV6 -c1 -I $lhost $rhost \>/dev/null
> +[ "$TST_PASS" = 1 ] || tst_brk "Quit due the above error"
Let's keep it then.
> But OTOH maybe route-change-*.sh tests even don't need to quit.
> And it's a question if isofs.sh does (and whether we should even keep isofs.sh).
For the isofs I would probably generate the iso filesystems in advance
and store them in git so that we don't have to re-generate them during
the test run. Other than that mounting an iso filesystem over loopback
and checking that the files are there (which the test does not do) is
valid kernel test. But that is a different problem.
--
Cyril Hrubis
chrubis@suse.cz
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-03-20 16:20 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-13 14:25 [LTP] [PATCH 0/6] [RFC,WIP] shell loader fixes + du01.sh rewrite Petr Vorel
2026-03-13 14:25 ` [LTP] [PATCH 1/6] tst_run.sh: Fix passing arguments Petr Vorel
2026-03-17 7:36 ` Li Wang via ltp
2026-03-18 14:17 ` Cyril Hrubis
2026-03-18 15:10 ` Petr Vorel
2026-03-13 14:25 ` [LTP] [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh Petr Vorel
2026-03-17 7:54 ` Li Wang via ltp
2026-03-18 14:26 ` Cyril Hrubis
2026-03-18 15:02 ` Petr Vorel
2026-03-20 16:20 ` Cyril Hrubis [this message]
2026-03-23 12:06 ` Petr Vorel
2026-03-23 12:41 ` [LTP] isofs.sh rewrite [was Re: [PATCH 2/6] tst_env.sh: Backport common functions from tst_test.sh] Petr Vorel
2026-03-13 14:25 ` [LTP] [PATCH 3/6] shell_loader: Start test count from 1 Petr Vorel
2026-03-17 8:00 ` Li Wang via ltp
2026-03-13 14:25 ` [LTP] [RFC][PATCH 4/6] run_shell_tcnt: Add test count also for test_all Petr Vorel
2026-03-17 9:45 ` Li Wang via ltp
2026-03-13 14:25 ` [LTP] [PATCH 5/6] [WIP,RFC] tst_run.sh: Run setup() only once Petr Vorel
2026-03-17 9:42 ` Li Wang via ltp
2026-03-18 11:23 ` Cyril Hrubis
2026-03-18 12:26 ` Cyril Hrubis
2026-03-18 15:40 ` Petr Vorel
2026-03-20 15:15 ` Cyril Hrubis
2026-03-23 21:20 ` Petr Vorel
2026-03-13 14:26 ` [LTP] [PATCH 6/6] du01.sh: Rewrite into shell loader Petr Vorel
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=ab1zwXCUui24rmmC@yuki.lan \
--to=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--cc=pvorel@suse.cz \
--cc=sebastian.chlad@suse.com \
/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