On Fri, Aug 07, 2009 at 08:46:44AM -0400, Gwern Branwen wrote:
> On Fri, Aug 7, 2009 at 2:26 AM, Trent W. Buck<[email protected]> wrote:
>> On Fri, Aug 07, 2009 at 01:57:41AM -0400, Gwern Branwen wrote:
>>> What is there to follow? There's no need to call bash for a trivial
>>> executable invocation - I'm not even using conditionals or anything
>>> reasonably fancy.
>>
>> It wouldn't surprise me if, for example, there was no sh(1) in some
>> Cygwin environment.
It turns out that I even have a real-world example:
$ ssh mail.UNPRINTABLE.com bash --version
GNU bash, version 3.00.16(14)-release (i686-pc-cygwin)
Copyright (C) 2004 Free Software Foundation, Inc.
$ ssh mail.UNPRINTABLE.com sh --version
bash: sh: command not found
I have censored the hostname to protect the guilty, but it's a cygwin
environment that exists solely to run rsyncd. Whoever set it up
refrained from installing anything not directly necessary for that
role, presumably to reduce the number of vulnerabilities and/or to
reduce the download size.
>> Basing even a trivial script on the template will improve
>> homogeneity between scripts, avoid inexplicable failures resulting
>> from that kind of weirdness.
>
> How could cygwin not provide sh?
> If one has bash installed, how does one not have sh?
See above.
> That was the whole point of cygwin, I thought, to provide the basic
> utilities such as sh.
Correct -- but just because cygwin provides utilities, doesn't mean
they're ALL installed at all sites.
* * *
Allow me to break your script on a more conventional system: Debian.
Alice can't apt-get install hlint yet, so she uses cabal-install.
This places the binary in ~/.cabal/bin, which is not in her normal
PATH. For some misguided reason, she abhors PATH bloat, and so
doesn't want to add that directory permanently to her PATH in her
.zshrc.
She works out that she can use BASH_ENV to make hlint visible to
Darcs' test scripts (which run bash) without polluting her interactive
zsh environments, nor the Debian-supplied sh scripts:
zeus% tail -1 ~/.zshrc
export BASH_ENV=~/.bash_env
zeus% cat $BASH_ENV
PATH=$PATH:~/.cabal/bin
zeus% bash -c 'hlint --help | head -1'
HLint v1.2, (C) Neil Mitchell 2006-2009, University of York
zeus% sh -c 'hlint --help | head -1'
sh: hlint: not found
This works fine while all Darcs tests use bash, but if some start to
use sh, those scripts will break. Since I've just explained WHY
they'll break, it's obvious to readers what the problem is. But now
imagine trying to isolate the above problem when all you're given is
% cabal test
[...]
sh: hlint: not found
That's a contrived example, but it's not far from the real world. (I
had essentially the opposite problem: bash was behaving "incorrectly"
when invoked as bash, because I didn't know $ENV is read if *and only
if* in sh-compatibility mode.)
> But one might not have bash but have sh.
In the case of Darcs test scripts, this scenario is not allowed to
occur, because bash is decreed to be a dependency for the tests.
> One should use only what one needs; the hlint script doesn't need
> the lib script, so it doesn't call it. It doesn't need bash, so it
> doesn't call it.
I understand your reasoning, but I would like to avoid unnecessary
differences between tests as much as unnecessary code IN the scripts.
> I've also added a copyright header and brief explanation.
Thanks!
>>>> Incidentally, looking only at ../src/ causes Setup.lhs and
>>>> Distribution/*.lhs to be skipped. Any reason just ../ wouldn't
>>>> work?
>>>
>>> No. Should those files be looked at?
>>
>> I think they should (after all, hlint reports problems with them),
>> but I'm willing to be convinced otherwise.
>
> I've recorded another patch generalizing the dir.
Good-o.
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
