public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
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

  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