[Toybox] [PATCH] toybox compiled on OS X 10.6

Rob Landley rob at landley.net
Tue Mar 13 15:44:40 PDT 2012


On 03/13/2012 02:59 AM, Georgi Chorbadzhiyski wrote:
> On 13.3.2012 г. 07:10, Rob Landley wrote:
>> Patch #0001:
>>
>> In the short term, create a directory with a symlink from "sed" to the
>> gsed binary, and insert it at the start of your $PATH.
>>
>> In the longer term: I plan to add sed to toybox, and the ability to
>> build individual commands standalone.  I'd like to make toybox build
>> its' own sed standalone, and use that.
>>
>> (I was going to say "test the host sed to see if it's good enough"...
>> but why test?  Build the toybox one, use the toybox one.  No different
>> than building our own instlist binary during install.  (Because toybox
>> is a target binary so you can't do "./toybox --list" when cross
>> compiling, that's why.)
> 
> That sounds good.
> 

Woot.  I need to get to work on sed. :)

> I have seen yesno() implementations that test if stdin isatty() and
> use stdin reading and stderr for writing. If stdin is not a tty just
> return confirmation.

I want this to work:

  find blah | xargs rm -i

In that case, stdin isn't the tty, but /dev/tty is.  I hit this all the
time with (tar cz | ssh blah "tar xvz") and even though we're not
implementing ssh, we may implement telnet...

>> patch #0004:
>>
>> I don't want to sprinkle #ifdef linux into toys/*.c.
>>
>> If we can add some kidn of portability/apple directory with alternate
>> implementations of stuff, or put really clever macros into
>> lib/portability.h, I'm all for it.  If we can't,
>>
>> More to the point: I'm all for making commands work on the macintosh,
>> but this doesn't.  This stubs them out.  I'd much rather just disable
>> them in the config (the way unshare vanishes on systems that don't
>> support it: you can't select it, the option goes away when the build
>> environment can't compile it) than produce a misleading NOP command.
> 
> Oh the ifdefs were just a quick hack to get toybox to build. I've done
> the same when compiled it on android. Definitely genconfig.sh should
> just disable the applets that are not working on the platform.

Hmmm...  The seemingly obvious thing to do would be to have configure
set some sort of APPLE or BIONIC symbol, and then "depends on !APPLE" in
the relevant commands.  Except how is that really different than #ifdef
__apple__? The per-command portability annotations either have to be in
the commands or in the resources they use, and when it's something like
dmesg or insmod where that command is the only user of that resource...

Fiddly.

Let's look at the list of things being switched off:

 lib/getmountlist.c |   10 ++++++++++
 toys/dmesg.c       |    7 +++++++
 toys/free.c        |    5 +++++
 toys/insmod.c      |    2 ++
 toys/mdev.c        |    5 +++++
 toys/rmmod.c       |    5 +++++
 toys/swapoff.c     |    2 ++
 toys/swapon.c      |    2 ++
 toys/uptime.c      |    2 ++

Let's see: dmesg and mdev are linux-specific, insmod and rmmod probably
are but don't the BSDs have some alternative? Also swapon/swapoff: how
do the BSDs handle that?  free and uptime don't seem particularly
linux-specific but I can see an OS not providing uptime, and our free
output format is waaay more complicated than seems reasonable.  (You'd
think it would be "free: $X/$Y, swap: $X/$Y".  I'm aware reality's a bit
more complicated, but not _that_ much more.  /proc/meminfo exists...)

Anyway, I'm starting to come around to the viewpoint of making stuff
depend on a LINUX config symbol, if only so I don't have to annotate
several different ways of saying !linux...

Rob

 1331678680.0


More information about the Toybox mailing list