On Fri, 30 Aug 2013 01:15:30 +0200 Roland Mainz wrote:
> On Thu, Aug 29, 2013 at 7:45 PM, Glenn Fowler <[email protected]> wrote:
> > the AT&T Software Technology ast alpha 2013-08-29 source release
> > has been posted to the download site
> >         http://www.research.att.com/sw/download/alpha/
> > the package names and md5 checksums are
> >             INIT  132e0403af573fa1cb1e202267fedeb8
> >         ast-open  334615fb3a652575106194c281d27b5c
> >          ast-ksh  ebcc56d9ab673aaafbb163d6eee1a93c
> > the md5 sums should match the ones listed on the download page

well that RELEASE note was optimistic

I had it and ls.c over there before I realized that ast ls has not been 
fts-ized yet
it uses the ancient ast pre-fts ftwalk() api

background: ast fts*() was unwound from ast ftwalk() and then proposed to posix
bsd joined in the proposal
ite never made it into posix (too much invention) but bsd retained it

anyway, for the next alpha the top of my list is to *at()-ize fts, add 
fts_dirfd,
eliminate chdir() calls by all of the libcmd -R commands, and then fts-ize ls 

the last part is non-trivial because it involves fts_children(), the trickiest
part of the fts api -- particularly maddening is the fact that the current
ast ftwalk() itself uses fts -- I tabled it for this release and hope to have
a better day when I get back to it

> Minor issue:
> 1. The annoucement email didn't contain any comments about libcmd changes
> 2. src/lib/libcmd/RELEASE says...
> -- snip --
> 13-08-11 ls.c: move from src/cmd/std
> -- snip --
> ... but there is no ls.c in the ast-ksh sources...

_______________________________________________
ast-developers mailing list
[email protected]
http://lists.research.att.com/mailman/listinfo/ast-developers

Reply via email to