From: Petr Vorel <pvorel@suse.cz>
To: Cyril Hrubis <chrubis@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: Mon, 23 Mar 2026 13:06:26 +0100 [thread overview]
Message-ID: <20260323120626.GA315436@pevik> (raw)
In-Reply-To: <ab1zwXCUui24rmmC@yuki.lan>
Hi Cyril,
> 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.
+1, I'll do in next version.
> > > > +_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.
Yeah, I've found this shell limitation in the past as well.
> 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.
Good, I was worried it was something else needed to be fixed. Thanks for double
checking!
> > > 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.
+1. We can revisit it later. Anyway, I'll add only what's currently needed,
maybe these network tests will be changed or rewritten into C.
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-03-23 12:06 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
2026-03-23 12:06 ` Petr Vorel [this message]
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=20260323120626.GA315436@pevik \
--to=pvorel@suse.cz \
--cc=chrubis@suse.cz \
--cc=ltp@lists.linux.it \
--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