Choosing a specific sh for redo
Alex Bradbury
useful to choose the specific shell to be invoked for a project, e.g.
relying on bash to allow the writer of the build-script to safely rely
on bashisms. Any thoughts?
Alex
Prakhar Goel
executables. Therefore if you want to use bash, put in a #! line.
However, I think there was something else on this subject in this list
some time ago on redo calling /bin/sh explicitly.
--
________________________
Warm Regards
Prakhar Goel
e-mail: newt...@gmail.com, newt...@caltech.edu
LinkedIn Profile: http://www.linkedin.com/in/newt0311
Cell: (972) 992-8078
"The real universe is always one step beyond logic." --- Frank Herbert, Dune
Avery Pennarun
> To me the better idea seemed to be to treat the files as opaque
> executables. Therefore if you want to use bash, put in a #! line.
> However, I think there was something else on this subject in this list
> some time ago on redo calling /bin/sh explicitly.
This whole issue is a tough one that I've largely punted on so far
(and which make punted on pretty much permanently at this point :)).
I added a patch to redo recently that tests your local shells and
picks one that's "as posixy as possible" based on a bunch of
documented incompatibilities. I was a bit horrified at how many shells
failed in obscure ways - even dash and bash, and (as someone recently
emailed me) the freebsd sh. Only zsh passed all the tests (in "sh
compatibility" mode, ironic because I couldn't find any sh that
actually was compatible with all the rules).
Meanwhile, one person on reddit commented that redo would be no good
on windows, because depending on a posix shell on windows generally
means cygwin or msys, both of which are second-class citizens. (Of
course make has the same problem. But windows people also try to avoid
it, *because* it does, so that legitimizes the complaint.) The
suggestion was to use python syntax instead of sh, since python runs
fine on windows and has well-defined syntax. I agree with that part,
but unfortunately python's well-defined syntax is not nearly as
optimized for running subprograms as sh syntax is, so it would end up
being kind of gross. (Plus... other people have already done that, and
their build systems didn't become popular yet :))
The #!/ option could work though - give people the flexibility to
choose what they want in their own projects. It's just that
flexibility, for me, is not as good as option as some hypothetical
perfect one that's both portable *and* awesome :)
I would love to hear anyone else's feedback on this though.
Have fun,
Avery
Prakhar Goel
function call. At that point we can just use the standard python
interpreter. However, then we still need to call gcc et al. Then we
need to make sure that these hooks work across platforms. Ultimately,
we will never really paper all the incompatibilities in the different
platforms without saddling redo with redoconf.
We could try to give a hypothetical option that is both portable *and*
awesome but in reality it will never really be that portable or that
awesome and instead it will be _yet another_ platform that developers
who use the redo platform must learn and become proficient with (and
must debug POSIX incompatibilities with!).
Instead, I think you were right originally when you said that redoconf
and redo should stay separate. Pretty much every platform (that could
make use of redo) understands the concept of executables. Furthermore,
if a project wants to be cross-platform it will have to look at
differences in the shell (and generally how to run compilations)
anyway. If we setup redo to use plain executables and assume they (the
executables) know how to handle themselves, the client project
developers are free to choose the best solution whether it be the
portable and awesome redoconf or something else entirely.
Singpolyma
> I added a patch to redo recently that tests your local shells and
> picks one that's "as posixy as possible" based on a bunch of
> documented incompatibilities. I was a bit horrified at how many shells
> failed in obscure ways - even dash and bash, and (as someone recently
> emailed me) the freebsd sh. Only zsh passed all the tests (in "sh
> compatibility" mode, ironic because I couldn't find any sh that
> actually was compatible with all the rules).
different incompatibilities. Trying to get standards compliant shells
for different systems has been something I've been very interested in
for some time.
And, yes, someone really needs to write one for windows. Maybe I'll
get around to it some day...
Avery Pennarun
> On Dec 26, 4:50 pm, Avery Pennarun <apenw...@gmail.com> wrote:
>> I added a patch to redo recently that tests your local shells and
>> picks one that's "as posixy as possible" based on a bunch of
>> documented incompatibilities. I was a bit horrified at how many shells
>> failed in obscure ways - even dash and bash, and (as someone recently
>> emailed me) the freebsd sh. Only zsh passed all the tests (in "sh
>> compatibility" mode, ironic because I couldn't find any sh that
>> actually was compatible with all the rules).
>
> I'd be really interested to see an article talking about these
> different incompatibilities. Trying to get standards compliant shells
> for different systems has been something I've been very interested in
> for some time.
I'll try to save up my energy and write up an article. I've also been
talking to some FreeBSD developers, apparently they have a big test
suite (written in sh) that everything except freebsd sh fails. That
sounds like a useful source of compatibility tests.
> And, yes, someone really needs to write one for windows. Maybe I'll
> get around to it some day...
Looks like someone is already working on it, in fact:
https://github.com/pclouds/busybox-w32
This is very cool: a 500k standalone binary that includes most of the
basic unix tools, including sh, no installation required. And their
sh passes redo's shelltest.od on win32 with only one warning (a usual
one for dash/ash).
Crazy idea: what if redo looked for busybox and *preferred* it over
other shells, if it passes the tests? That would strongly encourage
people to keep to a consistent subset of unixyness, and if busybox-w32
stays maintained, it would even help with win32 portability.
Have fun,
Avery
Prakhar Goel
accepted practice first. Forcing policy changes may not be such a
great idea. If project devs want to limit their software to UNIX only
or bash only, why is this any of our concern?
--
________________________
Warm Regards
Prakhar Goel
e-mail: newt...@gmail.com, newt...@caltech.edu
LinkedIn Profile: http://www.linkedin.com/in/newt0311
Cell: (972) 992-8078
"The real universe is always one step beyond logic." --- Frank Herbert, Dune
Alex Bradbury
> Crazy idea: what if redo looked for busybox and *preferred* it over
> other shells, if it passes the tests? That would strongly encourage
> people to keep to a consistent subset of unixyness, and if busybox-w32
> stays maintained, it would even help with win32 portability.
It's a shame there doesn't seem to be an up-to-date BSD busybox port.
It would be handy if you could write build scripts using just the
functionality provided by busybox, and know it would work for anyone
willing to download the < 1MB binary, so you'd avoid any issues about
different command-line options or functionality between BSD and GNU
userland etc.
Alex
Avery Pennarun
> Aren't you putting the cart before the horse here? Redo has to become
> accepted practice first. Forcing policy changes may not be such a
> great idea. If project devs want to limit their software to UNIX only
> or bash only, why is this any of our concern?
Well, as I see it, one of the big convincing arguments against
adopting redo is that its core language is sh, and you can't always
count on sh to be compatible from one system to another: not just Unix
vs. Windows, but even different variants of Unix, or even different
versions of busybox or dash.
If I'm a developer considering converting my cross-platform projects
over to redo - and I am, in fact! - then these questions of redo's
portability are pretty important.
Of course we don't want to *force* developers to make their stuff
portable; that's why I added the #!/ code in the most recent version,
so if you really want bash, you can put #!/bin/bash at the top of your
.do file and you'll get bash.
Conversely, however, if people *do* want portability, they currently
have nowhere to turn. redo's auto-shell-selection is a start, but it
doesn't necessarily guarantee which features of find, ls, wc, etc
you'll end up getting. Having redo auto-prefer busybox would help
people to write portable .do scripts; if you care about portability,
make sure you have busybox installed, and redo will use it.
busybox might be *too* limiting though. Its 'find' command apparently
doesn't even have -exec, which I use pretty often. On the other hand,
building on Windows is pretty hard without something like busybox.
msys/cygwin are okay, but I'm imagining situations where redo could
actually be a useful build system even if you don't want to think of
your Windows system as POSIXy at all. For example, you could use redo
as the engine to run a Delphi or MSVC or Java compile.
So in short, no, I don't think redo has to become popular before we
can think about this sort of portability. In fact, it might be
exactly the reverse.
Have fun,
Avery
Avery Pennarun
Hmm, if they can port it to win32, I'm sure porting it to BSD is
probably not rocket science :) The really odd stuff, like insmod and
mount and ifconfig, aren't really needed of course. Just the easy
bits.
Have fun,
Avery