On Sat, Jan 17, 2015 at 11:53 AM, Rob Landley <r...@landley.net> wrote: > On 01/17/2015 12:09 AM, enh wrote: >> more progress... > > I need to update roadmap.html. > >> next to look at: >> >> df --- missing -h; column alignment broken. no need to support old >> Android output format. > > I have a half-finished rewrite of this to do the ls -l "buffer the > output, count up the sizes, output everything aligned to the size of the > longest entry in each column" trick. > > I'd genericize it in lib if I could figure out how. Maybe when a third > command does this it'll look like common code... > >> du --- our default block size was 512; -h output slightly >> different. [patch sent upstream] > > The only old one I have pending from you us the touch patch, although I > see there are some new ones this morning. (I may have lost track of this > one, might need a resend.)
i'll look it out and resend. iirc it was worded more as a query because i know BSD has a lot more options to its equivalent 'human_readable' and i suspect when we're done with all the -h options we'll have needed the lot, but i'm guessing you just want to add what's needed right now? > (I was trying to clear your patches so I could tackle Ashwini Sharma's > pending pile from October, but there's a strong appeal in staying > current as well. Although I found one more #*%&(# thing wrong with sed...) > >> ls --- missing -Z > > I don't have a patch for this and am not competent to do it myself: I > don't use selinux, dunno what's expected here. no worries. this is just me showing my own to-do list. (mostly the SELinux stuff is on a separate list that i don't even bother including. not sure why ls is on the wrong list.) actually, someone asked "when do we get toybox ls?" the other day because they were sick of -h not working. they were disappointed to hear that toybox doesn't support -h yet either, but that wouldn't be a regression. afaik, the lack of -Z is the only thing i need to address. it looked like the tizen guys found and fixed a number of existing bugs with ls output. did they send the patches to you? if so, i'll probably wait until that's done. https://git.tizen.org/cgit/platform/upstream/toybox.git/commit/?id=f7a1a508ee6c713e93c030bba3ce19999ba69c2a https://git.tizen.org/cgit/platform/upstream/toybox.git/commit/?id=54e0fb4d814aeb8ddd8584351cea8f4c4b8b8322 https://git.tizen.org/cgit/platform/upstream/toybox.git/commit/?id=131ea0f2410651754c442ce77eca67bbba5d271d btw, you can see in those patches that they (and i) need to add a temporary buffer for the security context. it's well documented that you don't like #if but -- as with the addition of declarations of functions that won't be defined -- it's not clear to me whether you're happy with unused locals, and if so, whether you want __attribute__((unused)) to keep things quiet? >> route --- superset? > > I haven't cleaned up route yet. I should do that, ifconfig's kinda silly > without it. (Last night I started cleaning up "fold" because it looked > small. I keep trying to do "smallest job first" scheduling of cleanups, > and it blows up into rewrites...) > >> touch --- ours has nonstandard -l (equivalent to standard -h), >> better resolution. [patch sent upstream] > > I spent some time yesterday merging the resolution increase patch. (You > noticed I had a pending "fix fractional seconds" patch in my tree that > wasn't fully debugged? Ideally I'd like both -d and -t to handle > fractional seconds. A lot of commands have half-finished patches, I keep > getting interrupted in the middle to go do other things. My tree's a > mess, I have "toybox/toybox" for pending work and "toybox/clean" to test > that what's checked in builds/works...) > > So anyway I checked that in, and now I'm porting your patch on top of > that change and I hit the _weirdest_ thing where "./touch nonexistent" > doesn't cause an error because utimensat() on a file that didn't exist > returned ok (file still doesn't exist afterwards), and when it does this > its argument variable becomes NULL (wasn't null before the call, is > after), and it's _weird_ and I think stack smashing is happening or > something and I'm trying to figure out what the blank is going on. (It's > gotta be that ts is wrong so the syscall is writing to the stack and > zeroing out the pointer but why didn't it return an _error_ for the > nonexistent file then...? I am now running my own code under strace > because sticking printfs into it is not being revealing. I'm -> <- this > close to doing objdump to look at the assembly and then tracing into the > #*%(&#@ C library. _I_HAVE_DONE_THIS_BEFORE_...) > > Debugging. If I knew what I was doing, I'd have done it already. > > Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
