From: Joerg Vehlow <lkml@jv-coder.de>
To: ltp@lists.linux.it
Subject: [LTP] [PATCH 0/4] checkbashisms.pl in make check + fixed docs
Date: Fri, 3 Sep 2021 06:28:42 +0200 [thread overview]
Message-ID: <16028467-ecd5-ecc0-26d7-b7a617045970@jv-coder.de> (raw)
In-Reply-To: <YTDpQxDDPY3HCli6@pevik>
H Petr,
On 9/2/2021 5:09 PM, Petr Vorel wrote:
>
>> $ checkbashisms testcases/kernel/connectors/pec/cn_pec.sh
>> possible bashism in testcases/kernel/connectors/pec/cn_pec.sh line 127
>> (should be >word 2>&1):
>> ??????????????? done <&${fd_act}
>> This one is just a false positive and I have no clue how to prevent this.
>> I think the script does not like the <&, but this is posix...
> The same here, I'm not sure if it's POSIX. &> definitely is not POSIX.
> I remember we were talking about it. Can we avoid it somehow?
<&n is the only way to use the file handle n for input. <n would use the
file n.
See:
https://pubs.opengroup.org/onlinepubs/009604499/utilities/xcu_chap02.html#tag_02_07_05
checkbashisms has no problems if n is a number, not a variable. There is
nothing in the standard about n being a variable, but I guess this
should be posix as well.
Furthermore the suggested fix "(should be >word 2>&1)" clearly shows,
that checkbashisms thinks, this is &>.
I don't see another way to implement this (but using an implementation
in c). And I am not really happy to bend my code around bugs in a tool,
that is supposed to ensure better code.
I'd rather try to fix checkbashims in this case. Even the ((-case should
be fixed, after checking if it is posix. The suggestion (replace with
"$((") indicates at least a bug in the tool.
To be honest, I am a bit disappointed from this tool. It doesn't seem to
be tested very well... Probably barely good enough for scripting in the
kernel.
Joerg
next prev parent reply other threads:[~2021-09-03 4:28 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-09-02 10:37 [LTP] [PATCH 0/4] checkbashisms.pl in make check + fixed docs Petr Vorel
2021-09-02 10:37 ` [LTP] [PATCH 1/4] doc: Mention make check Petr Vorel
2021-09-02 13:17 ` Cyril Hrubis
2021-09-02 15:46 ` Petr Vorel
2021-09-02 10:37 ` [LTP] [PATCH 2/4] Vendor checkbashisms.pl version 2.20.5 Petr Vorel
2021-09-02 13:25 ` Cyril Hrubis
2021-09-02 10:37 ` [LTP] [PATCH 3/4] rules.mk: Add checkbashisms to 'make check' for *.sh Petr Vorel
2021-09-02 13:27 ` Cyril Hrubis
2021-09-02 15:51 ` Petr Vorel
2021-09-02 10:37 ` [LTP] [PATCH 4/4] doc: Update for vendored checkbashisms.pl Petr Vorel
2021-09-02 13:29 ` Cyril Hrubis
2021-09-09 10:55 ` Petr Vorel
2021-09-09 10:55 ` Petr Vorel
2021-09-02 11:50 ` [LTP] [PATCH 0/4] checkbashisms.pl in make check + fixed docs Petr Vorel
2021-09-02 14:01 ` Joerg Vehlow
2021-09-02 15:09 ` Petr Vorel
2021-09-03 4:28 ` Joerg Vehlow [this message]
2021-09-03 7:43 ` Petr Vorel
2021-09-03 8:10 ` Joerg Vehlow
2021-09-03 8:53 ` Petr Vorel
2021-09-02 15:14 ` 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=16028467-ecd5-ecc0-26d7-b7a617045970@jv-coder.de \
--to=lkml@jv-coder.de \
--cc=ltp@lists.linux.it \
/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