Re: [RFC/PATCH] tests: add initial bash completion tests

From: Felipe Contreras <felipe.contreras@gmail.com>
Date: Apr 6, 2012, 22:05 UTC
Message-ID: <CAMP44s0VWWuM6eeij_nys9OAqu6Jr87Wv4K56mbbqhuMbVXKaQ@mail.gmail.com>
In-Reply-To: <20120406213448.GA5436@sigill.intra.peff.net>

On Sat, Apr 7, 2012 at 12:34 AM, Jeff King <peff@peff.net> wrote:

Show 16 quoted lines

> On Sat, Apr 07, 2012 at 12:21:35AM +0300, Felipe Contreras wrote:
>
>> On Fri, Apr 6, 2012 at 11:19 PM, Jeff King <peff@peff.net> wrote:
>> > On Fri, Apr 06, 2012 at 10:28:39PM +0300, Felipe Contreras wrote:
>>
>> > I think you need to start with something like:
>> >
>> >  #!/bin/sh
>>
>> That is irrelevant, even if it's '#!/bin/foobar', it wouldn't make any
>> difference since the actual command would be something like
>> '$(SHELL_PATH) t9902-completion.sh'.
>
> True; I thought "prove" would run them directly, but even it uses
> $(SHELL_PATH) to run the tests. However, doesn't that mean your test
> will fail completely when $(SHELL_PATH) isn't bash?

Yes.

> So yes, the #! isn't relevant to "make test" (though marking it as
> #!/bin/sh does serve as documentation for what you expect,

No, it's the opposite; #!/bin/sh would imply that you can run this with any POSIX shell; you can't. For example, if /bin/sh points to dash (which is the case in debian AFAIK), the test would fail in the middle of it. #!/bin/bash would be more proper; it would properly document that you need bash to run this. Sure, maybe bash is not in /bin (I have never seen that), but that would not affect 'make tests', only the people that want to run this directly, which I suspect are very, *very* few, and they would immediately see a clear error: './blah: /bin/bash: bad interpreter: No such file or directory', and then they could easily try 'bash ./blah'.

Show 5 quoted lines

> But my point still stands that you cannot assume that you are running
> bash, and you need to either find bash, or gracefully exit the test
> script if it is not available. Anything else will cause "make test" to
> fail on some systems (and indeed, applying and running your test, it
> breaks "make test" on my debian box with dash as /bin/sh).

So? 'make test' fails on my Arch Linux box which doesn't have /usr/bin/python, which is presumably why there is NO_PYTHON. Instead of doing some nasty hacks such as 'bash <<\END_OF_BASH_SCRIPT', it would be much easier to have a NO_BASH option. And in fact, when zsh completion tests are available, NO_ZSH (probably on by default).

But you clearly prefer the status quo, so I'm not going to bother.

-- 
Felipe Contreras