From: Junio C Hamano <gitster@pobox.com>
To: Siddharth Asthana <siddharthasthana31@gmail.com>
Cc: git@vger.kernel.org, "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>,
"Derrick Stolee" <derrickstolee@github.com>,
"Elijah Newren" <newren@gmail.com>,
"Lars Schneider" <larsxschneider@gmail.com>
Subject: Re: [GSoC] [PATCH] t1011: replace test -f with test_path_is_file
Date: Mon, 11 Apr 2022 12:09:28 -0700 [thread overview]
Message-ID: <xmqq1qy3igif.fsf@gitster.g> (raw)
In-Reply-To: <20220409114458.23435-1-siddharthasthana31@gmail.com> (Siddharth Asthana's message of "Sat, 9 Apr 2022 17:14:56 +0530")
Siddharth Asthana <siddharthasthana31@gmail.com> writes:
> Use test_path_is_file() instead of 'test -f' for better debugging
> information.
> ---
missing Sign-off.
> test_cmp expected.swt result &&
> - ! test -f init.t &&
> - ! test -f sub/added
> + ! test_path_is_file init.t &&
> + ! test_path_is_file sub/added
> '
Given the definition of the helper function, i.e.
test_path_is_file () {
test "$#" -ne 1 && BUG "1 param"
if ! test -f "$1"
then
echo "File $1 doesn't exist"
false
fi
}
the new test will _complain_ "init.t doesn't exist" when we have
successfully run the test, while it will be _silent_ when init.t
that _should_ not exist is there.
Which is the complete opposite of the spirit of why we want to use
the helper when we expect the path "$1" to exist, i.e. loudly fail
when our expectation is _not_ met.
$ git grep '! test_path_is' t/
shows that we already have such a misuse of test_path_is_dir in one
place, but luckily we do not have any for test_path_is_file or other
similar helpers. test_path_is_hidden is sort-of OK as that is not
about verbosity.
In these two test, we do not expect init.t or sub/added to _exist_
at all. It's not like we are happy if we see init.d exist as a
directory (which is not a file). test_path_is_missing is probably
the right helper to use.
It is not very plausible that we'd want to assert that existence of
a path as a file the only bad condition (i.e. we are happy if the
path did not exist or it is a directory, symlink, or a socket), so I
think the simple
Never use '! test_path_is_file'; test_path_is_missing may be
what you are looking for.
is a good enough rule.
If not, we could allow the caller to write such a convoluted "only
existence of a path as a file is unacceptable and everything else is
good" assertion as
test_path_is_file ! init.d
with something like
test_path_is_file () {
expecting_file=true
if test "$1" = "!"
then
expecting_file=false
shift
fi
test "$#" -ne 1 && BUG "1 param"
if test -f "$1"
then
$expecting_file || echo "File $1 exists"
$expecting_file
else
$expecting_file && echo "File $1 doesn't exist"
! $expecting_file
fi
}
but I do not think we want to go that way.
next prev parent reply other threads:[~2022-04-11 19:09 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-09 11:44 [GSoC] [PATCH] t1011: replace test -f with test_path_is_file Siddharth Asthana
2022-04-11 19:09 ` Junio C Hamano [this message]
2022-04-12 20:21 ` Siddharth Asthana
2022-04-12 20:37 ` [GSoC] [PATCH v2] " Siddharth Asthana
2022-04-14 8:19 ` Christian Couder
2022-04-14 16:42 ` Junio C Hamano
2022-04-16 13:55 ` Siddharth Asthana
2022-04-16 13:59 ` [PATCH v3] t1011: replace test -f with test_path_is* helpers Siddharth Asthana
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=xmqq1qy3igif.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=avarab@gmail.com \
--cc=derrickstolee@github.com \
--cc=git@vger.kernel.org \
--cc=larsxschneider@gmail.com \
--cc=newren@gmail.com \
--cc=siddharthasthana31@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 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.