From: "Torsten Bögershausen" <tboegi@web.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Torsten Bögershausen" <tboegi@web.de>,
"Jonathan Nieder" <jrnieder@gmail.com>,
git@vger.kernel.org, kraai@ftbfs.org
Subject: Re: [PATCH] tests: turn on test-lint-shell-syntax by default
Date: Sun, 27 Jan 2013 08:43:46 +0100 [thread overview]
Message-ID: <5104DAB2.5000606@web.de> (raw)
In-Reply-To: <7v1ud71uys.fsf@alter.siamese.dyndns.org>
On 26.01.13 22:43, Junio C Hamano wrote:
> Torsten Bögershausen <tboegi@web.de> writes:
>
>> Do we really need "which" to detect if frotz is installed?
> I think we all know the answer to that question is no, but why is
> that a relevant question in the context of this discussion? One of
> us may be very confused.
>
> I thought the topic of this discussion was that, already knowing
> that "which" should never be used anywhere in our scripts, you are
> trying to devise a mechanical way to catch newcomers' attempts to
> use it in their changes, in order to prevent patches that add use of
> "which" to be sent for review to waste our time. I was illustrating
> that the approach to override "which" in a shell function for test
> scripts will not be a useful solution for that goal.
Yes, the diskussion went away.
I would rather see the check-non-portable-shell.pl enabled per default.
It looks as if the "which" command is hard to find, when we want a minimal
risk of false positves.
I can see different solutions:
1) We can make a much simpler expression which only catches the most
common usage of which, like
"if whitch foo".
This will not catch lines like
if test -x "$(which foo 2>/dev/null)"
But I think the -x is not a useful anyway, because which should only
list command which have the executable bit set.
2) We drop the which from check-non-portable-shell.pl
I'll send a patch for 1)
/Torsten
next prev parent reply other threads:[~2013-01-27 7:44 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-12 5:50 [PATCH] tests: turn on test-lint-shell-syntax by default Torsten Bögershausen
2013-01-12 6:00 ` Junio C Hamano
2013-01-13 10:25 ` Torsten Bögershausen
2013-01-13 16:50 ` Matt Kraai
2013-01-13 17:32 ` Jonathan Nieder
2013-01-13 22:38 ` Junio C Hamano
2013-01-15 20:12 ` Torsten Bögershausen
2013-01-15 20:38 ` Junio C Hamano
2013-01-26 6:57 ` Torsten Bögershausen
2013-01-26 21:43 ` Junio C Hamano
2013-01-27 7:43 ` Torsten Bögershausen [this message]
2013-01-27 9:31 ` Jonathan Nieder
2013-01-27 13:13 ` Torsten Bögershausen
2013-01-27 17:34 ` Junio C Hamano
2013-01-27 20:25 ` Junio C Hamano
2013-02-05 20:36 ` Torsten Bögershausen
2013-02-05 20:52 ` Junio C Hamano
2013-02-05 21:56 ` Junio C Hamano
2013-01-27 17:15 ` Junio C Hamano
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=5104DAB2.5000606@web.de \
--to=tboegi@web.de \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=jrnieder@gmail.com \
--cc=kraai@ftbfs.org \
/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.