From: "Torsten Bögershausen" <tboegi@web.de>
To: Adam Spiers <git@adamspiers.org>
Cc: Jeff King <peff@peff.net>, git mailing list <git@vger.kernel.org>
Subject: Re: $PATH pollution and t9902-completion.sh
Date: Thu, 20 Dec 2012 18:25:13 +0100 [thread overview]
Message-ID: <50D349F9.9030100@web.de> (raw)
In-Reply-To: <CAOkDyE-J7sTJ-GefhteP1wy7WorqTRnj5nn0k6hd1dp0VJz5iQ@mail.gmail.com>
On 20.12.12 16:13, Adam Spiers wrote:
> On Thu, Dec 20, 2012 at 2:55 PM, Jeff King <peff@peff.net> wrote:
>> On Mon, Dec 17, 2012 at 01:05:38AM +0000, Adam Spiers wrote:
>>> t/t9902-completion.sh is currently failing for me because I happen to
>>> have a custom shell-script called git-check-email in ~/bin, which is
>>> on my $PATH. This is different to a similar-looking case reported
>>> recently, which was due to an unclean working tree:
>>>
>>> http://thread.gmane.org/gmane.comp.version-control.git/208085
>>>
>>> It's not unthinkable that in the future other tests could break for
>>> similar reasons. Therefore it would be good to sanitize $PATH in the
>>> test framework so that it cannot destabilize tests, although I am
>>> struggling to think of a good way of doing this. Naively stripping
>>> directories under $HOME would not protect against git "plugins" such
>>> as the above being installed into places like /usr/bin. Thoughts?
>>
>> I've run into this, too. I think sanitizing $PATH is the wrong approach.
>> The real problem is that the test is overly picky. Right now it is
>> failing because you happen to have "check-email" in your $PATH, but it
>> will also need to be adjusted when a true "check-email" command is added
>> to git.
>>
>> I can think of two other options:
>>
>> 1. Make the test input more specific (e.g., looking for "checkou").
>> This doesn't eliminate the problem, but makes it less likely
>> to occur.
>>
>> 2. Loosen the test to look for the presence of "checkout", but not
>> fail when other items are present. Bonus points if it makes sure
>> that everything returned starts with "check".
>>
>> I think (2) is the ideal solution in terms of behavior, but writing it
>> may be more of a pain.
>
> I agree with all your points. Thanks for the suggestions.
I volonteer for 1) (and we got for 2) later)
next prev parent reply other threads:[~2012-12-20 17:25 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-12-17 1:05 $PATH pollution and t9902-completion.sh Adam Spiers
2012-12-20 14:55 ` Jeff King
2012-12-20 15:13 ` Adam Spiers
2012-12-20 17:25 ` Torsten Bögershausen [this message]
2012-12-20 18:36 ` Junio C Hamano
2012-12-20 19:55 ` Junio C Hamano
2012-12-20 20:01 ` Jeff King
2012-12-20 20:53 ` Torsten Bögershausen
2012-12-20 21:02 ` Junio C Hamano
2012-12-20 21:04 ` Jeff King
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=50D349F9.9030100@web.de \
--to=tboegi@web.de \
--cc=git@adamspiers.org \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/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.