<div dir="ltr">actually, this is the one outstanding patch you _shouldn't_ apply --- i had to revert the switch to ls late last night after it broke a surprising amount of infrastructure.<div><br></div><div>(the toolbox ls didn't columnate, and "adb shell ..." creates a pty on the remote side, so toybox ls sees that and defaults to -C rather than -1. callers can't use -1 to say what they want, because toolbox ls didn't support that, and even if we add it today they still need to deal with a mix of old and new devices. similarly, the pty creation is on the adbd side, so although i'll fix that to be like ssh(1), that will only help new devices. i suspect we'll have to disable the isatty test in ls_main for the next ten years. there's also code that parses the toolbox ls -l format, which doesn't have the "nlink" column, so i'll need to find and fix those regular expressions. but first i need to talk to the ddmlib folks to see why they're parsing ls output at all, when using the adb sync protocol queries would seem like a better idea...)</div><div><br></div><div>but there's plenty of other stuff like the hwclock fix and the find -inum addition and the xxd for pending to keep you busy, plus -- as you said -- there's smack for the flight :-) (rather than make things more confusing and risk slowing things down even further, i'm waiting until the smack changes are in before i worry about SELinux. what i've seen looks plausible though so i'm not anticipating problems.)</div><div><br></div><div>btw, on the subject of testing --- i noticed that a command that SEGVs gets a "PASS". i've been meaning to fix that and send a patch, but since it's been two weeks since i noticed already, i should at least report it...</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 16, 2015 at 10:26 AM, Rob Landley <span dir="ltr"><<a href="mailto:rob@landley.net" target="_blank">rob@landley.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 05/15/2015 08:17 PM, enh wrote:<br>
> roadmap update: Android switched to toybox ls today.<br>
<br>
</span>Sorry, been sucked away into $DAYJOB recently, flying back to Japan tomorrow<br>
and trying to get stuff done before then. I am _waaaaay_ behind on the<br>
list, and need to basically reread this whole month's web archive and<br>
deal with stuff in order. (I've downloaded smack-10 to look at on the plane.)<br>
<br>
The dirtree_parentfd() stuff not working is because the filehandle gets<br>
closed by the time dirtree_recurse() returns (see line 330 where we dup()<br>
one to avoid that), which means we have to read the xattr string and store<br>
it during the traversal. The actual callback that collects this data is<br>
filter(), so that's the logical place to snapshot it, but ->extra is already<br>
used to signal this argument came from the command line (I don't remember<br>
why). I can malloc a struct but don't want to if I can avoid it.<br>
<br>
Looking at ls_main() and the strange way we have an empty top of tree<br>
node crated with (0,0), I vaguely remember this was to get some aspect of<br>
the ls -R behavior right (when to print or not print directory labels?)<br>
and this is when, before I start fiddling with it, I REALLY want there to<br>
be a tests/ls.test with regression tests for all these weird corner cases<br>
I had to get right at the time and am worried about breaking now just because<br>
I don't remember what they all _are_.<br>
<br>
So I was briefly happy to see there's an ls.test, but it's an external<br>
contribution that doesn't actually test any of the things I'm worried about<br>
breaking here. (This is why I need a "pending" directory for the test suite.<br>
And really need to spend lots of time making what I consider to be proper<br>
test suite entries for each command.)<br>
<br>
So my next todo item there is working out why I implemented it that way,<br>
and if I can easily test that top-of-tree thing at runtime and thus<br>
repurpose dirtree->extra without mallocing an extra struct for it.<br>
(The painful bit would be mallocing _just_ the flag in the non-lsm-label<br>
case.) I think I can, but need to work through to be sure.<br>
<br>
But meanwhile, I'm back looking at the smack-10 branch starting from<br>
the new lib files, which is another message...<br>
<span class="HOEnZb"><font color="#888888"><br>
Rob<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">Elliott Hughes - <a href="http://who/enh" target="_blank">http://who/enh</a> - <a href="http://jessies.org/~enh/" target="_blank">http://jessies.org/~enh/</a><br>Android native code/tools questions? Mail me/drop by/add me as a reviewer.</div>
</div>