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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

On Sat, Apr 7, 2012 at 12:34 AM, Jeff King <peff@xxxxxxxx> wrote:
> 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@xxxxxxxx> 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)'.
> 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?


> 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'.

> 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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Newbies FAQ]     [Linux Kernel Development]     [Free Online Dating]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Free Online Dating]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]     [Linux Resources]

Add to Google