[Toybox] New tests for dirname and wc

[David Seikel]

/me picks two things out of this long email to comment on.


On Sun, 25 Nov 2012 22:39:41 -0600 Rob Landley <rob at landley.net> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20121126/c72a3a7d/attachment-0002.sig>