From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
To: Bartosz Golaszewski <brgl@bgdev.pl>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Kent Gibson <warthog618@gmail.com>,
Erik Schilling <erik.schilling@linaro.org>,
Phil Howard <phil@gadgetoid.com>,
Viresh Kumar <viresh.kumar@linaro.org>,
linux-gpio@vger.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
Subject: Re: [libgpiod][RFC/RFT 02/18] tests: split out the common test code for bash scripts
Date: Tue, 23 Apr 2024 21:17:21 +0300 [thread overview]
Message-ID: <Zif7McOO-1d2coCO@smile.fi.intel.com> (raw)
In-Reply-To: <20240412122804.109323-3-brgl@bgdev.pl>
On Fri, Apr 12, 2024 at 02:27:48PM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski <bartosz.golaszewski@linaro.org>
>
> In order to allow the upcoming DBus command-line client tests to reuse the
> existing bash test harness, let's put the common code into an importable
> file and rename run_tool to run_prog to reflect that it now can run any
> program.
> tests/bash/Makefile.am | 4 +
> tests/bash/gpiod-bash-test-helper.inc | 328 +++++++++++++++
Is the 'bash' a new folder name?
If so, it might be problematic for make as it may recognize it as a bash
command. I would rather name it 'scripts' or 'shell' or alike.
...
> +++ b/tests/bash/gpiod-bash-test-helper.inc
And why not a simple shell? Do you use bashisms?
...
> +# Run the command in $* and fail the test if the command succeeds.
"$*" in most cases is simply wrong. "$@" is better.
https://unix.stackexchange.com/questions/294052/how-to-properly-pass-set-of-parameters-with-spaces-into-shell-function
...
> +num_lines_is() {
> + [ "$1" -eq "0" ] || [ -z "$output" ] && return 0
-o inside [] will do better than ||
> + local NUM_LINES=$(echo "$output" | wc -l)
> + assertEquals " number of lines:" "$1" "$NUM_LINES"
> +}
...
> + for ARG in $*
This may be wrong.
> + do
> + done
...
> +gpiosim_chip_symlink_cleanup() {
> + if [ -n "$GPIOSIM_CHIP_LINK" ]
> + then
> + rm "$GPIOSIM_CHIP_LINK"
> + fi
If you use already || or && you may continue doing that, this will be one liner
with it.
[ -n "$GPIOSIM_CHIP_LINK" ] && rm "$GPIOSIM_CHIP_LINK"
> + unset GPIOSIM_CHIP_LINK
> +}
...
> + for i in {1..30}; do
$(seq 1 30) or IIRC $(seq 30)
Less bashisms are better.
> + [ "$(<$PORT)" = "$EXPECTED" ] && return
> + sleep 0.01
> + done
...
> + if [ "$?" = "0" ]
> + then
> + for LINE in $(find $BANKPATH/ | grep -E "line[0-9]+$")
What's the point in -E ?
Yet another `Useless use of grep`.
IIRC how `find` works. You may filter names there (and with regex IIRC again).
> + do
> + test -e $LINE/hog && rmdir $LINE/hog
Why not [ -e ... ] && ?
> + rmdir $LINE
> + done
> + fi
...
> +dut_read_redirect() {
> + output=$(<$SHUNIT_TMPDIR/$DUT_OUTPUT)
> + local ORIG_IFS="$IFS"
> + IFS=$'\n' lines=($output)
> + IFS="$ORIG_IFS"
TABs vs. spaces indentation issues?
> +}
...
> +dut_read() {
> + local LINE
> + lines=()
> + while read -t 0.2 -u ${COPROC[0]} LINE;
What is ; for as you are using three-lines form?
> + do
> + if [ -n "$DUT_FIRST_CHAR" ]
> + then
> + LINE=${DUT_FIRST_CHAR}${LINE}
> + unset DUT_FIRST_CHAR
> + fi
> + lines+=("$LINE")
Don't remember the syntax, but something like this
lines=$((LINE + $lines))
is better than bashisms.
> + done
> + output="${lines[@]}"
> +}
...
> + read -t 0.2 -u ${COPROC[0]} LINE || (echo Timeout && false)
Wouldn't () fork a shell?
(The () vs. {} discussion, don't remember by heart though.)
...
> +dut_write() {
> + echo $* >&${COPROC[1]}
Oh.
> +}
...
> +# Must be done after we sources shunit2 as we need SHUNIT_VERSION to be set.
> +oneTimeSetUp() {
> + test "$SHUNIT_VERSION" = "$MIN_SHUNIT_VERSION" && return 0
> + local FIRST=$(printf "$SHUNIT_VERSION\n$MIN_SHUNIT_VERSION\n" | sort -Vr | head -1)
I believe you can do it with a simple test rather than involving sort and head
and printf. And test most likely will be builtin.
> + test "$FIRST" = "$MIN_SHUNIT_VERSION" && \
> + die "minimum shunit version required is $MIN_SHUNIT_VERSION (current version is $SHUNIT_VERSION"
> +}
...
> + SORTED=$(printf "$REQUIRED\n$CURRENT" | sort -V | head -n 1)
Ditto.
> + if [ "$SORTED" != "$REQUIRED" ]
Dup? Seems to me you can run a single test to get the answer.
> + then
> + die "linux kernel version must be at least: v$REQUIRED - got: v$CURRENT"
Linux
> + fi
...
Okay, it seems you moved existing code... That code needs more love towards
becoming a nicely formatted shell.
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2024-04-23 18:17 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-12 12:27 [libgpiod][RFC/RFT 00/18] dbus: add GLib-based DBus daemon and command-line client Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 01/18] tests: split out reusable test code into a local static library Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 02/18] tests: split out the common test code for bash scripts Bartosz Golaszewski
2024-04-23 18:17 ` Andy Shevchenko [this message]
2024-05-24 17:59 ` Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 03/18] bindings: glib: add build files Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 04/18] bindings: glib: add public headers Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 05/18] bindings: glib: add core code Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 06/18] bindings: glib: add examples Bartosz Golaszewski
2024-04-23 18:23 ` Andy Shevchenko
2024-05-24 18:22 ` Bartosz Golaszewski
2024-05-27 19:51 ` Andy Shevchenko
2024-05-27 20:01 ` Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 07/18] bindings: glib: add tests Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 08/18] README: document GLib bindings Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 09/18] dbus: add build files Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 10/18] dbus: add the API definitions Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 11/18] dbus: add a wrapper around the gdbus-codegen generated header Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 12/18] dbus: add data files Bartosz Golaszewski
2024-04-12 12:27 ` [libgpiod][RFC/RFT 13/18] dbus: add gpio-manager code Bartosz Golaszewski
2024-04-12 12:28 ` [libgpiod][RFC/RFT 14/18] dbus: add tests Bartosz Golaszewski
2024-04-12 12:28 ` [libgpiod][RFC/RFT 15/18] dbus: add a command-line client Bartosz Golaszewski
2024-04-12 12:28 ` [libgpiod][RFC/RFT 16/18] dbus: client: add tests Bartosz Golaszewski
2024-04-12 12:28 ` [libgpiod][RFC/RFT 17/18] README: document the DBus API Bartosz Golaszewski
2024-04-12 12:28 ` [libgpiod][RFC/RFT 18/18] TODO: drop the DBus daemon from the list Bartosz Golaszewski
2024-04-23 17:41 ` [libgpiod][RFC/RFT 00/18] dbus: add GLib-based DBus daemon and command-line client Andy Shevchenko
2024-04-23 17:44 ` Bartosz Golaszewski
2024-06-28 16:16 ` Sverdlin, Alexander
2024-06-28 19:04 ` Bartosz Golaszewski
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=Zif7McOO-1d2coCO@smile.fi.intel.com \
--to=andriy.shevchenko@linux.intel.com \
--cc=bartosz.golaszewski@linaro.org \
--cc=brgl@bgdev.pl \
--cc=erik.schilling@linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-gpio@vger.kernel.org \
--cc=phil@gadgetoid.com \
--cc=viresh.kumar@linaro.org \
--cc=warthog618@gmail.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;
as well as URLs for NNTP newsgroup(s).