On 08/14/2015 11:55 PM, enh wrote: > On Tue, Aug 11, 2015 at 2:09 PM, Rob Landley <[email protected]> wrote: >> On 08/11/2015 02:10 PM, enh wrote: >>> On Mon, Aug 10, 2015 at 11:58 PM, Rob Landley <[email protected]> wrote: >>>> On 08/10/2015 10:39 PM, enh wrote: >>>>> Fix several bugs in date. >>>> >>>> Sigh. I honestly did test it, although clearly not thoroughly enough. >>>> (That's how I set my clock to the year 2157, which networkmangler did >>>> _not_ like...) >>> >>> yeah, that's the advantage of having real unit tests. -d lets us test >>> the parsing reasonably well though (even if toybox's -d is >>> incompatible with coreutils'). >> >> If you mean "doesn't support multiple different fallback formats via >> some magic /etc file they only tell you about in the info pages", yes. >> If you mean something else, tell me more and maybe I can fix it? > > no, i think toybox is saner than GNU here. i was just obliquely > pointing out that these tests will fail when run against the host > tools.
I've never quite been sure how to handle those cases. I have two SKIP_HOST=1 tests in sed.test but should probably make it _say_ SKIP: for the status. (At some point, the test suite needs about as much work as the shell.) >> I admit that "date -D %s -d 1234567890 +%s" isn't something gnu date >> supports, although it can do date -d @1234567890 %s > > yeah, it's the "date -d 14081805" format that toybox supports (yay!) > but GNU doesn't (boo!). Posix is pretty explicit about that century _and_ year are optional: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/date.html mmddhhmm[[cc]yy] cc is the century and is the first two digits of the year (this is optional); yy is the last two digits of the year and is optional. If century is not specified, then values in the range [69,99] shall refer to years 1969 to 1999 inclusive, and values in the range [00,68] shall refer to years 2000 to 2068 inclusive. The current year is the default if yy is omitted. [Option End] That said, I documented a deviance from posix: * Note: setting a 2 year date is 50 years back/forward from today, * not posix's hardwired magic dates. Because the same magic date range is in the 1997 spec as in the 2013 update of the 2008 spec: http://pubs.opengroup.org/onlinepubs/7908799/xcu/date.html I.E. once again posix is stuck in the 90's, which ended 15 years ago now. >> Oh, side note: cpio doesn't store xattrs. It also has a 32 bit date >> (y2038) and 32 bit file lengths. This means initramfs is kinda limited. >> Do you care strongly about this? > > the ramdisk is on its way out. i think some of this work is already > visible in AOSP. there are certainly people internally running devices > that boot from a squashfs system image and although they do still have > a ramdisk, they only use it for the recovery image. (with the longer > term plan killing that too.) so "no, i don't think so". Except initramfs isn't a ramdisk, it's a dynamically resizing tmpfs instance populated by extracting an archive into it, and that archive can be part of the kernel image so you can boot a kernel without any external root filesystem. I wrote documentation about this long ago: https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt And then a couple years back I did: https://lwn.net/Articles/559176/ *shrug* Android not using it is fine, but the main reason "ramdisk" is obsolete is because "ramfs" replaced it, and they're really not the same thing. Rob _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
