redo 0.03: bash completions and choose-your-interpreter
Avery Pennarun
I just tagged redo 0.03. I included a variant of Zoran's bash
completions; if you install these, you can tab-complete redo target
names without worrying about all the other cluttery files lying
around. Among other things, this avoids the common mistake of
tab-completing and trying to 'redo foo.do' instead of 'redo foo'.
I also added a bunch of tests so that redo can attempt to auto-select
an "as POSIX as possible" shell from the shells available on your
system. The idea here is that if we enforce POSIX compatibility in
redo itself, then any .do script will be able to assume the shell it's
running under is POSIX, thus saving a lot of the horrors of what
autoconf has to go through to make sure it works with whatever shell
it ends up using.
This still isn't perfect though; every single shell I have, except
zsh, fails at least some of the tests. It was a bit too ridiculous,
so I relaxed some of the failures to just "warnings", so that at least
bash and dash become candidates. That's cheating though, and it kind
of weakens the whole point of it a bit. Then again, the stuff I
relegated to warnings isn't really *that* important compared to basic
stuff like shell functions and ${x#y} and so on.
It's also imperfect because minimal/do still just hardcodes /bin/sh as
the shell it uses. I could work around that, but the idea is that
minimal/do could be included in your own projects to help out people
who don't have redo installed; the code for testing shell
compatibility is, unfortunately, twice as many lines of code as
minimal/do itself. So if we included this functionality, it would
triple the size of the program. I'm sure I could strip it down a bit,
but it's still gross. So for now, I haven't dealt with that problem
at all. If you want to use minimal/do, you need to have a sane shell
as /bin/sh.
Finally, I implemented the feature we discussed on the list that can
let you use alternate interpreters for your .do files. If you want a
particular .do to run under something other than the redo-selected
shell, just start the file with #!/path/to/shell, as you would with
any unix script. You don't have to chmod +x the file; redo actually
looks for the line by itself. I figured executable .do files would be
misleading, since you're not supposed to ever run them directly - you
should be doing 'redo filename' instead.
Oh, and while I was fixing up minimal/do to support the above feature,
I also fixed up the "clean" files it left lying around after a
'minimal/do clean'. There should be much less junk left after a
minimal/do from now on.
Let me know what you think!
Zoran Zaric (1):
Sample bash completion rules for redo targets.
Avery Pennarun (11):
Automatically select a good shell instead of relying on /bin/sh.
minimal/do: use posix shell features instead of dirname/basename.
minimal/do: use ".did" stamp files instead of empty target files.
minimal/do: delete .tmp files if a build fails.
minimal/do: faster deletion of stamp files.
bash completions: work correctly with subdirs, ie. 'redo t/<tab>'
bash completions: call redo-targets for a more complete list.
bash completions: work correctly when $cur is an empty string.
bash completions: also mark 'do' as a completable command.
minimal/do: don't print an error on exit if we don't build anything.
Handle .do files that start with "#!/" to specify an explicit interpreter.
Have fun,
Avery
Alex Bradbury
> Finally, I implemented the feature we discussed on the list that can
> let you use alternate interpreters for your .do files. If you want a
> particular .do to run under something other than the redo-selected
> shell, just start the file with #!/path/to/shell, as you would with
> any unix script. You don't have to chmod +x the file; redo actually
> looks for the line by itself. I figured executable .do files would be
> misleading, since you're not supposed to ever run them directly - you
> should be doing 'redo filename' instead.
Might it be worth documenting what happens to any arguments given on
the shebang line?
Alex
Henry Gebhardt
> I also added a bunch of tests so that redo can attempt to auto-select
> an "as POSIX as possible" shell from the shells available on your
> system. The idea here is that if we enforce POSIX compatibility in
> redo itself, then any .do script will be able to assume the shell it's
> running under is POSIX, thus saving a lot of the horrors of what
> autoconf has to go through to make sure it works with whatever shell
> it ends up using.
Very cool. My "which" spits out a bunch of warnings when it can't find
a shell, so how about redirecting the output as in the attached patch?
>
> This still isn't perfect though; every single shell I have, except
> zsh, fails at least some of the tests.
busybox (version 1.18.1) also passes them all. :-)
Thanks,
Henry
Avery Pennarun
<hsgge...@googlemail.com> wrote:
> On Sat, Jan 01, 2011 at 10:26:23PM -0800, Avery Pennarun wrote:
>> I also added a bunch of tests so that redo can attempt to auto-select
>> an "as POSIX as possible" shell from the shells available on your
>> system. The idea here is that if we enforce POSIX compatibility in
>> redo itself, then any .do script will be able to assume the shell it's
>> running under is POSIX, thus saving a lot of the horrors of what
>> autoconf has to go through to make sure it works with whatever shell
>> it ends up using.
>
> Very cool. My "which" spits out a bunch of warnings when it can't find
> a shell, so how about redirecting the output as in the attached patch?
Applied it, thanks.
>> This still isn't perfect though; every single shell I have, except
>> zsh, fails at least some of the tests.
>
> busybox (version 1.18.1) also passes them all. :-)
Hey, nice. I have busybox 1.10.2 on my computer (from Debian-lenny)
and it fails 96 and 102. Good to know they've been pre-emptively
fixing things, though :)
Have fun,
Avery
Saneesh
I think this is a good compromise. I mean, it would've been great if we
could've had a pure POSIX shell everywhere, but the guessing makes me
uncomfortable as there is no simple way to know, for sure, if something will
work on every system. (Not that make did it better, but still.)
Yay on bash-completion.
I like the not needing to be executable thing as well.
On Sat, Jan 01, 2011 at 10:26:23PM -0800, Avery Pennarun wrote:
--
It is said an Eastern monarch once charged his wise men to invent him a
sentence to be ever in view, and which should be true and appropriate
in all times and situations. They presented him the words: "And this,
too, shall pass away."
-- A. Lincoln
Avery Pennarun
> I think this is a good compromise. I mean, it would've been great if we
> could've had a pure POSIX shell everywhere, but the guessing makes me
> uncomfortable as there is no simple way to know, for sure, if something will
> work on every system. (Not that make did it better, but still.)
Not 100% sure what you mean here. Do you mean that bup's
auto-shell-choosing makes you uncomfortable? It's supposed to make
you *more* comfortable, so if it makes you uncomfortable, then I've
failed my mission :) I would appreciate it if you could clarify the
source of your discomfort so maybe we can find a better solution.
Have fun,
Avery
Avery Pennarun
> In addition I like that it opens the door to other shells (or
> languages) that could be used if a specific do file could be written
> much easier in that language instead of a shell, thought this is not
> all that important as anything can be called from a do file.
>
> All in all I was trying to say that I liked the additions.
Sweet, glad you like it :)
Have fun,
Avery