Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
> I swear I'm not just on a mission to ruin everyone's GSOC projects. This
> patch definitely looks good, and given that we have this / document it
> makes sense.
>
> However. I wonder in general if we've re-visited the utility of these
> wrappers and maybe other similar wrappers after -x was added.
>
> Back when this was added in 2caf20c52b ("test-lib: user-friendly
> alternatives to test [-d|-f|-e]", 2010-08-10) we didn't have -x.
> ...
> But 4 years after this was added in a136f6d8ff ("test-lib.sh: support -x
> option for shell-tracing", 2014-10-10) we got -x, and then with "-i -v -x":
I think two things need to be considered separately.
- Do the path-is-file and friends make the test source easier to
read and undrstand? Special bonus if it helps us by making it
harder to write a wrong test.
- Do these helpers make the output from the test execution easier
to diagnose or harder?
If your primary compalint is the latter (which I think it is, and I
share the same feeling to a certain degree), I think it is to throw
the baby with bathwater to get rid of path-is-* family.
And as to the former question, I think we even are getting special
bonus. Often when people write tests to ensure a fix that left an
unwanted file behind would say "! test -f unwanted", but if we say
"path-is-missing unwanted" that would catch not just a regular file
but also catch other kinds of filesystem entities.
As to readablity, I do not think "test -f/-d" etc are unnecessary
hard to read, but using path-is-* does not make it harder to read,
so I'd say it would not give us much to revert to the bare "test -f"
and friends.
Unless you are after squeezing the last cycle spent executing a
shell builtin in the test scripts by using bare-bones "test -f",
that is. But that is not among the two I said we need to consider
separately, so I won't go there.
Thanks.
[jch: I am still mostly offline til the next week, but I had a
chance to sit in front of my mailbox long enough, so...]
