From: Stefano Brivio <sbrivio@redhat.com>
To: Phil Sutter <phil@nwl.cc>
Cc: "Pablo Neira Ayuso" <pablo@netfilter.org>,
"Laura García Liébana" <nevola@gmail.com>,
netfilter-devel@vger.kernel.org
Subject: Re: [PATCH nft] tests: shell: Drop redefinition of DIFF variable
Date: Mon, 15 Jun 2020 14:40:55 +0200 [thread overview]
Message-ID: <20200615144055.31bbfd66@redhat.com> (raw)
In-Reply-To: <20200615115424.GJ23632@orbyte.nwl.cc>
On Mon, 15 Jun 2020 13:54:24 +0200
Phil Sutter <phil@nwl.cc> wrote:
> Hi Stefano,
>
> On Mon, Jun 15, 2020 at 12:18:11PM +0200, Stefano Brivio wrote:
> > On Mon, 15 Jun 2020 11:00:44 +0200
> > Phil Sutter <phil@nwl.cc> wrote:
> >
> > > Hi Stefano,
> > >
> > > On Sun, Jun 14, 2020 at 11:41:49PM +0200, Stefano Brivio wrote:
> > > > Commit 7d93e2c2fbc7 ("tests: shell: autogenerate dump verification")
> > > > introduced the definition of DIFF at the top of run-tests.sh, to make
> > > > it visually part of the configuration section. Commit 68310ba0f9c2
> > > > ("tests: shell: Search diff tool once and for all") override this
> > > > definition.
> > > >
> > > > Drop the unexpected redefinition of DIFF.
> > >
> > > I would fix it the other way round, dropping the first definition.
> >
> > Then it's not visibly configurable anymore. It was in 2018, so it
> > looks like a regression to me.
>
> Hmm? Commit 68310ba0f9c2 is from January this year?!
Commit 7d93e2c2fbc7 (which makes it "configurable") is from March 2018.
> > > It's likely a missing bit from commit 68310ba0f9c20, the second
> > > definition is in line with FIND and MODPROBE definitions immediately
> > > preceding it.
> >
> > I see a few issues with those blocks:
> >
> > - that should be a single function called (once or multiple times) for
> > nft, find, modprobe, diff, anything else we'll need in the future.
> > It would avoid any oversight of this kind and keep the script
> > cleaner. For example, what makes sort(1) special here?
>
> It is simply grown and therefore a bit inconsistent.
Yes, hence worth a minor rework perhaps? I can take care of this at
some point.
> > - quotes are applied inconsistently. If you expect multiple words from
> > which(1), then variables should also be quoted when used, otherwise
> > the check might go through, and we fail later
>
> There are needless quotes around $(...) but within single brackets we
> need them if we expect empty or multi-word strings. Typical output would
> be 'diff not found' and using '[ ! -x "$DIFF" ]' we check if which
> returned diff's path or said error message. We don't expect diff's path
> to contain spaces, hence no quoting afterwards.
Probably stupid but:
[ break nft ]
# mkdir "my secret binaries"
# cp /usr/bin/diff "my secret binaries/"
# export PATH="my secret binaries:$PATH"
# nftables/tests/shell/run-tests.sh nftables/tests/shell/testcases/listing/0003table_0
I: using nft command: nftables/tests/shell/../../src/nft
W: [FAILED] nftables/tests/shell/testcases/listing/0003table_0: got 127
nftables/tests/shell/testcases/listing/0003table_0: line 15: my: command not found
I: results: [OK] 0 [FAILED] 1 [TOTAL] 1
or, perhaps more reasonable:
# grep DIFF=\" nftables/tests/shell/run-tests.sh
DIFF="diff -y"
# nftables/tests/shell/run-tests.sh nftables/tests/shell/testcases/listing/0003table_0
I: using nft command: nftables/tests/shell/../../src/nft
W: [FAILED] nftables/tests/shell/testcases/listing/0003table_0: got 1
I: results: [OK] 0 [FAILED] 1 [TOTAL] 1
Personally, this bothers me more than some cheap, extra quotes. If the
general agreement is that it's not worth to add quotes to fix this,
fine, I would skip this the day I have time to propose the single
checking function rework I mentioned. Just let me know.
--
Stefano
next prev parent reply other threads:[~2020-06-15 12:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-06-14 21:41 [PATCH nft] tests: shell: Drop redefinition of DIFF variable Stefano Brivio
2020-06-15 9:00 ` Phil Sutter
2020-06-15 10:18 ` Stefano Brivio
2020-06-15 11:54 ` Phil Sutter
2020-06-15 12:40 ` Stefano Brivio [this message]
2020-06-15 13:21 ` Phil Sutter
2020-06-15 14:36 ` Stefano Brivio
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=20200615144055.31bbfd66@redhat.com \
--to=sbrivio@redhat.com \
--cc=netfilter-devel@vger.kernel.org \
--cc=nevola@gmail.com \
--cc=pablo@netfilter.org \
--cc=phil@nwl.cc \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.