Bug 3951 - (int-96574/int-96575) Incompatible quote handling in Busybox xargs (FEATURE_XARGS_SUPPORT_QUOTES disabled?)
(int-96574/int-96575)
: Incompatible quote handling in Busybox xargs (FEATURE_XARGS_SUPPORT_QUOTES di...
Status: CLOSED FIXED
Product: Core
Busybox
: 5.0-alpha
: All Linux
: Low normal with 3 votes (vote)
: 5.0-beta2
Assigned To: unassigned
: busybox-bugs
:
:
:
: 3938 3948
  Show dependency tree
 
Reported: 2008-12-22 10:49 UTC by Eero Tamminen
Modified: 2009-07-16 14:03 UTC (History)
3 users (show)

See Also:


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description Eero Tamminen (reporter) nokia 2008-12-22 10:49:17 UTC
(I split this issue from bug 3948 as it's for different component)

SOFTWARE VERSION:
- 5.2008.43-7

STEPS TO REPRODUCE THE PROBLEM:
1. echo \"x\"|xargs

EXPECTED OUTCOME:
- x

(Like happens with GNU xargs)


ACTUAL OUTCOME:
- "x"

(Which breaks upstream installation scripts, see bug 3948)


REPRODUCIBILITY:
- always
Comment 1 Eero Tamminen (reporter) nokia 2008-12-22 10:50:24 UTC
This happens also with (the current Fremantle) BusyBox v1.10.2, not just with
v1.6.1 in Diablo.
Comment 2 tz 2008-12-23 16:36:35 UTC
As you noted in a reply to 3848, the busybox "ls" doesn't support -Q, so
busybox ls will also break scripts.  It appears invoke-rc.d has both problems
will succeed but in the wrong manner as the ls will return nothing.  I don't
know if this should too be filed as a separate bug.

In general, many advanced scripts are using things beyond which the busybox
implementation can handle - the whole discussion of "can't build under
busybox", and how to replace busybox applets with the full GNU applets might be
part of this, just one specific case of updated script boilerplate breaking
things and it might get worse.
Comment 3 Eero Tamminen (reporter) nokia 2008-12-23 18:28:43 UTC
(In reply to comment #2)
> As you noted in a reply to 3848, the busybox "ls" doesn't support -Q, so
> busybox ls will also break scripts.  It appears invoke-rc.d has both problems
> will succeed but in the wrong manner as the ls will return nothing.  I don't
> know if this should too be filed as a separate bug.

Please file -Q as separate issue as it concerns different BB applet.


> In general, many advanced scripts are using things beyond which the busybox
> implementation can handle - the whole discussion of "can't build under
> busybox",

I don't think "can't build under busybox" is a significant issue, one can &
should use SB1 or SB2 for building packages when this matters.


> and how to replace busybox applets with the full GNU applets might
> be part of this, just one specific case of updated script boilerplate
> breaking things and it might get worse.

We're not getting rid of Busybox and there will indeed be these kind of issues
in the future.  Aim should be to make Busybox stuff replacing Debian essentials
(coreutils etc) as compatible as possible, and non-essential stuff provided by
Busybox replaceable in the device (as packages need to declare explicit
dependencies to non-essentials having them replaceable is less of an
compatibility issue).

Packages that try to use non-standard GNU options in standard utilities, should
be fixed, also in upstream (-Q is pretty useful though, even if it wouldn't be
defined in POSIX).

Nokia should provide some better facility for (automatically) testing
installing packages using Busybox (SB1 installs don't use BB).  Would you be
interested to file a bug about this too?  This test setup could then e.g. be
used by the Extras autobuilder too.

Busybox could also give better warnings about things that it doesn't implement
(that are easy to notice automatically).  Currently it for example doesn't warn
about options that have been disabled in its configuration (I have filed
Busybox upstream bug about this).
Comment 4 tz 2008-12-23 19:15:52 UTC
I will take a look and see what I can file.  The ls -Q, and something about
doing the testing with busybox (though I would note there may be other silent
fails which are more of a problem - e.g. if something isn't copied or
configured but there is no error code returned).

busybox ls does complain about -Q, but to stederr (which goes 2>/dev/null in
the script).

And have you ever tried to set the time using busybox?  It only accepts ONE
input format for the date/time, and it doesn't say which one in the help.  (and
try finding it on the web - you can but it isn't easy).

I like busybox, but the problem is more that some things aren't turned on (e.g.
diff), and other things are apparently the lighter version, so it is hard to
figure out if I should ask for a more complete busybox, or just go with a full
GNU replacement.

There should be some tablet/busybox install test, but I noticed this before the
recent SSU (I think with agps-ui/supld) but didn't track it down at the time. 
I think doing a busybox install test might help, but I also wonder if there
might be something that can go a bit farther since the tests tend to be to the
equivalent of a newly flashed tablet.

I know there has been some progress in getting a virtual n810 to boot up in
qemu - perhaps this can be extended.

Was the SSU in something like "extras-devel" first?  The only way to truly test
is a release candidate perhaps two weeks before the official update to see how
it works out on actual tablets with a wide variety of added software and
configurations.
Comment 5 tz 2008-12-23 23:13:27 UTC
Bugs #3957 and #3958 entered for ls -Q and test with busybox respectively. 
Please edit to clarify and correct as needed.
Comment 6 Eero Tamminen (reporter) nokia 2008-12-30 15:45:27 UTC
(In reply to comment #4)
> I will take a look and see what I can file.  The ls -Q, and something about
> doing the testing with busybox (though I would note there may be other silent
> fails which are more of a problem - e.g. if something isn't copied or
> configured but there is no error code returned).

If you notice any other BB compatibility issue, please, please report them. At
least comment in one of these Busybox bugs about them. :-)


> busybox ls does complain about -Q, but to stederr (which goes 2>/dev/null in
> the script).

ls returns an error code:
---------------
# ls -Q 2>/dev/null; echo $?
1
---------------

But it's not propagated through pipe or from subshell:
-----------
# ls -Q 2>/dev/null | ls >/dev/null; echo $?
0                      
# for i in $(ls -Q 2>/dev/null); do echo $?; done; echo $?
0
-----------


> And have you ever tried to set the time using busybox?  It only accepts ONE
> input format for the date/time, and it doesn't say which one in the help.
> (and try finding it on the web - you can but it isn't easy).

I'm mostly worried about things that can (badly) break device installation. 
Device has its own UI to set time/date, packages shouldn't (need to) set them,
or should they?

(Wrong time can cause funny issues with most unexpected things on though, for
example with CVS.)


> I like busybox, but the problem is more that some things aren't turned on
> (e.g. diff), and other things are apparently the lighter version,

Diff is an excellent example of BB tool that's lacking most of the options that
its GNU variant has.  What you would like it for and would it really be
compatible enough for that?


> so it is hard to figure out if I should ask for a more complete busybox,
> or just go with a full GNU replacement.

I think for compatibility reasons the essential stuff should be
"non-replaceable" so that developers do test against, notice and report the
Busybox incompatibilities.  That way we can avoid/fix nasty surprises for
normal users (something that installs on developers machine, breaks normal user
installation).

For non-essential/developer Busybox tools (like vi), yes, they should be easily
replaceable.


> There should be some tablet/busybox install test, but I noticed this before
> the recent SSU (I think with agps-ui/supld) but didn't track it down at
> the time.  I think doing a busybox install test might help, but I also
> wonder if there might be something that can go a bit farther since the
> tests tend to be to the equivalent of a newly flashed tablet.

Why that would be bad?  Newly flashed tablet like setup should best point out
any dependencies package is missing.


> Was the SSU in something like "extras-devel" first?  The only way to truly
> test is a release candidate perhaps two weeks before the official update to
> see how it works out on actual tablets with a wide variety of added software
> and configurations.

I hope to see something like that in Fremantle.  It's much better to be able to
release updates single package at the time in some experimental repo first than
just to have these large&infrequent "update everything" updates.  That way
people can test the fix-updates faster, we know faster whether something
publicly reported really got fixed and find broken packages faster.

(people using this kind of repo of course shouldn't blindly update anything
like they might do with the more infrequent & better tested "update everything"
updates).
Comment 7 tz 2008-12-30 16:19:05 UTC
ls -Q | xargs in invoke-rc.d:

The script does tests in two sections, first the symlinks from /etc/rc?.d, then
doing /etc/init.d directly.  The ls -Q fails the first test completely (e.g.
thinks there are NO symlinks even though there are).  When this fails, it finds
the /etc/init.d version of the script and runs it that way, though not as
intended.  Most (all that I checked) pre/post init/rm scripts check for
invoke-rc.d and just run /etc/init.d/xxx directly when the invoke-rc.d script
isn't there, so it would probably be safe just to get rid of the script
entirely and save a few bytes.  But if the script is doing something better, it
probably should be doing it the right way.

diff:

cp configfile configfile.bak (or just do a backup).

When upgrading or changing settings, the multipage config files may or may not
have changed anything or anything important.

diff X X.bak

even with the most basic of options will show me what changed.

Testing the Tablet-rasa:

The newly flashed tablet won't have everything running or in a configured state
as many things will not have been run.  When I restore my browser, I get
plugins which wouldn't be there for the test.  Other programs may change
support or load modules (I do that for Ogg and for ext2/iso).  And the GNU
colorized ls which sparked this discussion.
Comment 8 Andre Klapper maemo.org 2009-01-15 14:04:40 UTC
I wondered whether to file this upstream, but it's confusing as Fedora 10 and
Ubuntu 8.10 have different results:

Command:                                 echo \"x\"|xargs
Output on N810 (version 1.6.1):          "x"

Command:                                 busybox echo \"x\"|busybox xargs
Output on Ubuntu 8.10 (version 1.10.2):  "x"

Command:                                 busybox echo \"x\"|busybox xargs
Output on Fedora 10 (version 1.10.3):    x
Comment 9 Eero Tamminen (reporter) nokia 2009-01-15 15:26:18 UTC
> Command:                                 busybox echo \"x\"|busybox xargs
> Output on Ubuntu 8.10 (version 1.10.2):  "x"
> 
> Command:                                 busybox echo \"x\"|busybox xargs
> Output on Fedora 10 (version 1.10.3):    x

Thanks.  I don't see anything in the BB v1.10.3 updates:
  http://busybox.net/downloads/fixes-1.10.3/

...that could have fixed this, so I guess this is again BB configuration issue.

Current (Fremantle) configuration which has this issue doesn't have these
enabled:
---------------------
config FEATURE_XARGS_SUPPORT_QUOTES
        bool "Enable support single and double quotes and backslash"
        default n
        depends on XARGS
        help
          Default xargs unsupport single and double quotes
          and backslash for can use aruments with spaces.

config FEATURE_XARGS_SUPPORT_ZERO_TERM
        bool "Enable null terminated option -0"
        default n
        depends on XARGS
        help
          Enable input filenames are terminated by a null character
          instead of by whitespace, and the quotes and backslash
          are not special.
-----------------------

(somebody should really go through all BB FEATURE_* stuff and check whether
they increase or decrease BB compatibility with upstream before Fremantle's
released.  Somebody could then backport that BB back to Diablo.)
Comment 10 Andre Klapper maemo.org 2009-03-18 15:49:15 UTC
According to the internal ticket, the plan is to enable
CONFIG_XARGS_SUPPORT_QUOTES for Fremantle.
Comment 11 Lucas Maneos 2009-03-22 17:08:54 UTC
(In reply to comment #9)
> config FEATURE_XARGS_SUPPORT_ZERO_TERM
>         bool "Enable null terminated option -0"

IMHO this should also be enabled, since FEATURE_FIND_PRINT0 is.

> (somebody should really go through all BB FEATURE_* stuff and check whether
> they increase or decrease BB compatibility with upstream before Fremantle's
> released.  Somebody could then backport that BB back to Diablo.)

I started a table of all FEATURE_* options at
http://wiki.maemo.org/Talk:Task:Busybox, feel free to expand, move elsewhere,
rearrange etc.  "Upstream" is Debian obviously, but which version?
Comment 12 Andre Klapper maemo.org 2009-03-23 18:24:24 UTC
Upstream can either refer to the tarballs from busybox.net or Debian, yeah.
Might sometimes be confusing and depends on whether we refer to code bugs or
configuration settings.
Comment 13 Lucas Maneos 2009-03-23 22:12:36 UTC
In this context upstream compatibility refers to matching the behaviour of the
corresponding GNU tools (bash, coreutils, findutils etc) in Debian.  The reason
I'm asking is to have a specific target to test against.
Comment 14 Eero Tamminen (reporter) nokia 2009-03-24 18:35:19 UTC
(In reply to comment #11)
> > (somebody should really go through all BB FEATURE_* stuff and check whether
> > they increase or decrease BB compatibility with upstream before Fremantle's
> > released.  Somebody could then backport that BB back to Diablo.)
> 
> I started a table of all FEATURE_* options at
> http://wiki.maemo.org/Talk:Task:Busybox, feel free to expand, move elsewhere,
> rearrange etc.

Wow, great, thanks!

Maybe it would make sense to remove features for utilities that will never(?)
be added to Maemo Busybox like *HTTPD* and *HDPARM*?


> "Upstream" is Debian obviously, but which version?

Well, Fremantle has versions of software that correspond to both Etch and Lenny
and some few may be even newer than Debian Sid I think (X stuff?) and couple of
things might not have been updated since Sarge (if there are that old things, I
think it would be appropriate to create bugs about them)...  But I think by the
time Fremantle will be released, Lenny is probably the best target.


(In reply to comment #13)
> In this context upstream compatibility refers to matching the behaviour
> of the corresponding GNU tools (bash, coreutils, findutils etc) in Debian.
> The reason I'm asking is to have a specific target to test against.

Maybe the "Upstream" column should be something like "Would increase GNU/Debian
tools compatibility"?
Comment 15 Andre Klapper maemo.org 2009-03-25 11:33:05 UTC
This has been fixed for Fremantle.
Comment 16 Lucas Maneos 2009-03-25 23:42:04 UTC
(In reply to comment #14)
> Maybe it would make sense to remove features for utilities that will never(?)
> be added to Maemo Busybox like *HTTPD* and *HDPARM*?

I've left them in but grayed out at the moment, but you can get rid of them if
you prefer.   There are a few options I'm not sure about, but I finished going
through most of them.  Take the tomato colour with a pinch of salt (a lot of
these would be enchancement-level at best), but even with all of them enabled
the busybox binary is 359KiB vs 347KiB on 5.0alpha which isn't too bad (and
according to bug 419, 7K out of those are due to FEATURE_IPV6 which is going in
anyway).

We should probably continue this elsewhere (wiki?) though.
Comment 17 Eero Tamminen (reporter) nokia 2009-03-26 14:37:19 UTC
(In reply to comment #16)
> (In reply to comment #14)
>> Maybe it would make sense to remove features for utilities that
>> will never(?) be added to Maemo Busybox like *HTTPD* and *HDPARM*?
> 
> I've left them in but grayed out at the moment, but you can get rid of them if
> you prefer.   There are a few options I'm not sure about, but I finished going
> through most of them.

Btw. Was this with the Fremantle version of Busybox which had already following
extra things enabled (because BB claimed to provide the packages into which
these tools belong in Debian, their BB versions were option compatible and BB
already provided some of the tools for these packages):
---------------------
coreutils (essential):
    * cksum (1) - checksum and count the bytes in a file
    * comm (1) - compare two sorted files line by line
    * expand (1) - convert tabs to spaces
    * fold (1) - wrap each input line to fit in specified width
    * hostid (1) - print the numeric identifier for the current host
    * install (1) - copy files and set attributes
    * logname (1) - print user's login name
    * md5sum (1) - compute and check MD5 message digest
    * nice (1) - run a program with modified scheduling priority
    * nohup (1) - run a command immune to hangups, with output to a non-tty
    * od (1) - dump files in octal and other formats
    * printenv (1) - print all or part of environment
    * sha1sum (1) - compute and check SHA1 message digest
    * split (1) - split a file into pieces
    * stat (1) - display file or file system status
    * sum (1) - checksum and count the blocks in a file
    * tac (1) - concatenate and print files in reverse
    * unexpand (1) - convert spaces to tabs 

gzip (essential):
    * uncompress (1) - expand compressed files 

mount (essential):
    * losetup (8) - set up and control loop devices 

ncurses-bin (essential):
    * clear (1) - clear the terminal screen
    * reset (1) - terminal initialization
(these were provided in earlier releases but missing in Diablo)

util-linux (essential):
    * getopt (1) - parse command options
    * ipcrm (8) - remove a message queue, semaphore set or shared memory id
    * ipcs (8) - provide information on ipc facilities
    * setsid (2) - creates a session and sets the process group ID 

net-tools (non-essential):
    * nameif (8) - name network interfaces based on MAC addresses
    * slattach (8) - attach a network interface to a serial line 

procps (non-essential):
    * pgrep (1) - look up processes based on name and other attributes
    * pkill (1) - signal processes based on name and other attributes
    * watch (1) - execute a program periodically, showing output 

console-tools (non-essential):
    * deallocvt (1) - deallocate unused virtual terminals
    * kbd_mode (1) - report or set the keyboard mode
    * openvt (1) - start a program on a new virtual terminal (VT).
    * setkeycodes (8) - load kernel scancode-to-keycode mapping table entries 
---------------------

(Coreutils stuff was important, rest not so, but as they didn't increase BB
size that much...)


> Take the tomato colour with a pinch of salt (a lot of these would be
> enchancement-level at best) but even with all of them enabled
> the busybox binary is 359KiB vs 347KiB on 5.0alpha which isn't too bad

Great work, thanks!  This is really tiny difference i.e. I don't see any reason
why the features couldn't be added.

Was there anything that would affect performance (like e.g. sort -k support
does)?


> (and according to bug 419, 7K out of those are due to FEATURE_IPV6 which
> is going in anyway).
> 
> We should probably continue this elsewhere (wiki?) though.

Once the list has been verified a bit, there could be a separate bug for
"Enable features in Busybox to increase its tools GNU/Debian compatibility"
where this is discussed more.
Comment 18 Lucas Maneos 2009-03-26 15:55:32 UTC
(In reply to comment #17)
> Btw. Was this with the Fremantle version of Busybox which had already following
> extra things enabled

Yes:

---------------------
BusyBox v1.10.2 (Debian 3:1.10.2.legal-1osso16) multi-call binary
Copyright (C) 1998-2007 Erik Andersen, Rob Landley, Denys Vlasenko
and others. Licensed under GPLv2.
See source distribution for full notice.

Usage: busybox [function] [arguments]...
   or: function [arguments]...

    BusyBox is a multi-call binary that combines many common Unix
    utilities into a single executable.  Most people will create a
    link to busybox for each function they wish to use and BusyBox
    will act like whatever it was invoked as!

Currently defined functions:
    [, [[, ash, awk, basename, cat, chgrp, chmod, chown, chroot,
    chvt, cksum, clear, cmp, comm, cp, cut, date, dd, deallocvt,
    df, dirname, dmesg, du, echo, egrep, env, expand, expr,
    false, fgrep, find, fold, free, fsync, fuser, getopt,
    getty, grep, gunzip, gzip, halt, head, hostid, hostname,
    hwclock, id, ifconfig, ifdown, ifup, install, ipcrm, ipcs,
    kbd_mode, kill, killall, killall5, last, ln, logger, login,
    logname, losetup, ls, md5sum, mesg, mkdir, mkfifo, mknod,
    mkswap, mktemp, more, mount, mv, nameif, netstat, nice,
    nohup, nslookup, od, openvt, pgrep, pidof, ping, ping6,
    pivot_root, pkill, poweroff, printenv, printf, ps, pwd,
    readlink, realpath, reboot, renice, reset, rm, rmdir,
    route, run-parts, sed, seq, setkeycodes, setlogcons, setsid,
    sh, sha1sum, slattach, sleep, sort, split, stat, stty,
    su, sum, swapoff, swapon, sync, sysctl, tac, tail, tar,
    tee, test, time, top, touch, tr, true, tty, umount, uname,
    uncompress, unexpand, uniq, uptime, vi, watch, wc, which,
    who, whoami, xargs, yes, zcat
---------------------

> This is really tiny difference i.e. I don't see any reason
> why the features couldn't be added.

I just realised I built it on a Diablo SDK so the quoted sizes will be a bit
different in Fremantle, but the relative difference should be similar.

> Was there anything that would affect performance (like e.g. sort -k support
> does)?

Possibly FEATURE_TAR_UNAME_GNAME (adds calls to getpwnam(3)/getgrnam(3) for
each file in the archive), otherwise nothing too serious that I can see. 
FEATURE_LS_FILETYPE will make ls slightly slower and the various
FEATURE_*LONG_OPTIONS obviously add a bit of overhead in getopt32() but these
are trivial IMHO.  The rest don't do anything unless explicitly invoked.

> Once the list has been verified a bit, there could be a separate bug for
> "Enable features in Busybox to increase its tools GNU/Debian compatibility"
> where this is discussed more.

Sounds good, do CC me when that's opened.
Comment 19 Eero Tamminen (reporter) nokia 2009-03-26 17:07:38 UTC
(In reply to comment #18)
> > Once the list has been verified a bit, there could be a separate bug for
> > "Enable features in Busybox to increase its tools GNU/Debian compatibility"
> > where this is discussed more.
> 
> Sounds good, do CC me when that's opened.

Nobody at the Nokia end is really looking after this, I meant mainly that
anyone on CC for this bug could quickly check your list whether they notice
anything of issue there and that maybe you could then file the bug... I can
then drive this internally.


Only thing I noticed was FEATURE_FAST_TOP, why you've marked it "n" although
it's "y" in Fremantle?

Btw. maybe it would make sense to have on the list secondarily things that
don't change the command line API or functionality, but improve performance? 

Only ones I found were these though:
- FEATURE_FAST_TOP
- FEATURE_TEE_USE_BLOCK_IO 
- FEATURE_VI_OPTIMIZE_CURSOR
- FEATURE_LZMA_FAST
- MD5_SIZE_VS_SPEED
Changing them would require another bug though.  Except for md5, I don't think
they would really affect much things.
Comment 20 Lucas Maneos 2009-03-26 19:57:13 UTC
(In reply to comment #19)
> Nobody at the Nokia end is really looking after this, I meant mainly that
> anyone on CC for this bug could quickly check your list whether they notice
> anything of issue there and that maybe you could then file the bug... I can
> then drive this internally.

Sure, if there are no objections I'll file an enhancement request this weekend.

> Only thing I noticed was FEATURE_FAST_TOP, why you've marked it "n" although
> it's "y" in Fremantle?

It's marked "y" for Fremantle and "n" for "Would increase compatibility", but
maybe that should be "y" as well (it's forcibly enabled by FEATURE_TOPMEM so to
really disable it would decrease compatibility).

> Btw. maybe it would make sense to have on the list secondarily things that
> don't change the command line API or functionality, but improve performance? 

Can do.  Just to check: speed is preferred over size in general?
Comment 21 Eero Tamminen (reporter) nokia 2009-03-30 12:45:41 UTC
(In reply to comment #20)
> > Btw. maybe it would make sense to have on the list secondarily things that
> > don't change the command line API or functionality, but improve performance? 
> 
> Can do.  Just to check: speed is preferred over size in general?

It depends of course a bit how much the size increases and how commonly used
the speeded up functionality is.  In Busybox case I assume the size differences
are so small that they aren't important.
Comment 22 Lucas Maneos 2009-04-01 21:51:49 UTC
(In reply to comment #20)
> if there are no objections I'll file an enhancement request this weekend.

Posted as bug 4248 (and sorry for the delay, stuff got in the way).

(In reply to comment #19)
> Btw. maybe it would make sense to have on the list secondarily things that
> don't change the command line API or functionality, but improve performance? 
> 
> Only ones I found were these though:
> - FEATURE_FAST_TOP
> - FEATURE_VI_OPTIMIZE_CURSOR
> - MD5_SIZE_VS_SPEED

These are already enabled/set to the fastest option, 

> - FEATURE_LZMA_FAST

and this isn't relevant at the moment (CONFIG_UNLZMA & CONFIG_FEATURE_TAR_LZMA
are unset).  Which leaves just:

> - FEATURE_TEE_USE_BLOCK_IO 

Worth posting a bug for this?
Comment 23 Eero Tamminen (reporter) nokia 2009-04-02 10:39:26 UTC
(In reply to comment #22)
> Which leaves just: 
> > - FEATURE_TEE_USE_BLOCK_IO 
>
> Worth posting a bug for this?

----------
config FEATURE_TEE_USE_BLOCK_IO
        bool "Enable block I/O (larger/faster) instead of byte I/O"
...
          Enable this option for a faster tee, at expense of size.
----------

Not many users for that in Fremantle:
~# ./search-script-commands.sh tee
checking /etc/ files...
checking pre/postinst & pre/postrm files for packages...
/var/lib/dpkg/info/python-cairo.prerm:    dpkg -L python-cairo | tee $flist | \
checking scripts in *bin/ directories...

"tee" is mainly interesting for interactive, not automated script use, so I
think it's not worth a bug.

Thanks!
Comment 24 Andre Klapper maemo.org 2009-07-14 13:47:11 UTC
Fix should be included in Fremantle SDK beta 2 hence updating Target Milestone.
If you are the reporter of this bug: Feel free to verify the fix if possible.