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: Wed, 18 Mar 2026 16:02:52 +0100 [thread overview]
Message-ID: <20260318150252.GA31214@pevik> (raw)
In-Reply-To: <abq1-BcXR1nfLGcU@yuki.lan>
> Hi!
...
> > +ROD_SILENT()
> > +{
> > + local tst_out
> > +
> > + tst_out=$(tst_rod "$@" 2>&1)
> > + if [ $? -ne 0 ]; then
> > + echo "$tst_out"
> > + tst_brk TBROK "$@ failed"
> > + fi
> > +}
> > +
> > +ROD()
> > +{
> > + tst_rod "$@"
> > + if [ $? -ne 0 ]; then
> > + tst_brk TBROK "$@ failed"
> > + fi
> > +}
> Since we are starting from a scratch I wonder if we should call this
> 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?
> > +_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?
> > + if [ $? -eq 0 ]; then
> > + tst_res TPASS "$@ passed as expected"
> > + return 0
> > + else
> > + $fnc TFAIL "$@ failed unexpectedly"
> > + return 1
> > + fi
> > +}
> > +
> > +_tst_expect_fail()
> > +{
> > + local fnc="$1"
> > + shift
> > +
> > + # redirect stderr since we expect the command to fail
> > + tst_rod "$@" 2> /dev/null
> > + if [ $? -ne 0 ]; then
> > + tst_res TPASS "$@ failed as expected"
> > + return 0
> > + else
> > + $fnc TFAIL "$@ passed unexpectedly"
> > + return 1
> > + fi
> > +}
> > +
> > +EXPECT_PASS()
> > +{
> > + _tst_expect_pass tst_res "$@"
> > +}
> > +
> > +EXPECT_PASS_BRK()
> > +{
> > + _tst_expect_pass tst_brk "$@"
> > +}
> 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"
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).
=> I'm ok with it.
Kind regards,
Petr
--
Mailing list info: https://lists.linux.it/listinfo/ltp
next prev parent reply other threads:[~2026-03-18 15:03 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 [this message]
2026-03-20 16:20 ` Cyril Hrubis
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=20260318150252.GA31214@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