/me picks two things out of this long email to comment on.
On Sun, 25 Nov 2012 22:39:41 -0600 Rob Landley <[email protected]> wrote: > I had to redo which (from where I left off cleaning it up) because: > > A) getdate() didn't do what I thought it did. > > It hasn't got any built in date-guessing formats, you have to point > it at a file of them. There doesn't seem to be a system standard file > or anything built into libc, so it was kinda useless. The man page > for the gnu/dammit version of date says -d can guess an arbitrary > date code, but no idea how. > > So I've got to go to the two specific date formats posix lists for > -d and -t, but I don't have to open code it like the initial > contribution did, I can use strptime() out of libc. > > B) posix says touch should handle multiple files on the command > line, and this only handled one argument. > > I wanted to use loopfiles(), but that means opening the file to get > a filehandle, and touch should be able to change the date of chmod > 000 files, meaning it can't use futimes but has to use the > non-filehandle version. > > Posix also says [.frac] I.E. fractions of a second support. > (Computers are fast now.) > The man page has utime() and utimes() on it and utimes() supports > milisecond resolution. Modern linux supports nanoseconds but > miliseconds is probably fine for now. (Eh, I could switch to > utimensat(AT_CWD, ...) at some point.) > > C) It only supported about half the posix command line arguments, it > needs -a, -c, and -d. > > Note that supporting -a and -m means it needs to stat the existing > file to get the current date, modify it, and write it back out. > > I also wince when I see repeated code, and try to sit back and find > a way to just have _one_ call to utime() or similar. I don't always > manage it but I do stop and try. > > I had to dig a bit to find out that the T "time designator" is a > literal T. > > I've still got a couple todo items: allow space as a time > designator, allow , as a fraction indicator. (*shrug* Posix.) I would guess for those human languages that swap the usage of commas and periods as fraction / thousands separators. <useless anecdote> In the SecondLife (SL) based virtual world work I do, the major clone of the server side is called OpenSim. OpenSim has the option of creating your virtual world from a disparate collection of sim servers run by a motley collection of random people. A sim is the basic unit of geography in SL, 256x256 meters, starting at 0 meters, and extending all the way up to entirely useless heights. So for instance, one sim server could be in USA, with the server itself set to the USA variation of English as it's locale, while another sim server could be in Denmark, with it's locale set to Danish. English and Danish are two languages where the use of commas and periods for fraction / thousands separator is swapped. OpenSim developers like to do crazy things, like use human readable wire protocols, coz they drink the "humans being able to read wire protocols that 99.999999% of the time only computers need to read is a great idea for the 0.000001% of the time that a human needs to read it to debug it" kool-aid. Some of the things OpenSim sends as human readable wire protocol get filtered through the servers locale. Did I mention the OpenSim developers are crazy? The end result is that if you teleport from this Danish sim to that USA sim, the Danish sim says "send this avatar to a height of 20,123 meters" (a little over 20 meters, a typical ground level), and the USA sim server thinks "Hmmm, 20 thousand meters high, OK" and tosses the poor avatar waaaay up in the air. There is never anything up that high, and the avatar has a loooong fall to the ground where they thought they where going. Getting commas and periods right is important for humans, computers should not care so much on the damn wire. Getting it wrong can be painful and messy. </useless anecdote> > I can do a sysvinit. It would be really nice if there was SOME > standard, somewhere... > > Mostly I want to get a clear idea of the problem people are trying > to solve, and whether or not there's any installed base of expertise > out there I can leverage. (What are the expectations here? What do > sysadmins sit down and mangle today without having to learn new > stuff? I dunno, I need to talk to some sysadmins...) Long ago, for busybox, I did a Sys V init that tried to stick to what LSB said should be done. I can't recall why it was not accepted inte busybox. Possibly someone had done their own favourite style of init and Sys V init was not desired. shrugs It was described as "Clean room implementation of runlevel/init.d/SYS V init applets for busybox, aiming for LSB compliance." /me digs through his ancient projects ... http://urunlevel.sourceforge.net/ Oh ick that looks awful on a wide screen. If nothing else, it might provide one persons take on the LSB "standard", even if it was from seven years ago. One feature I added was the ability to write init "scripts" in C as well as the usual shell scripts. Toybox probably does not want that. -- A big old stinking pile of genius that no one wants coz there are too many silver coated monkeys in the world.
signature.asc
Description: PGP signature
_______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
