On Sat, Aug 10, 2013 at 3:36 PM, Glenn Fowler <[email protected]> wrote: > > it still has not been explained why special fs treatment like this > goes into ksh and not src/lib/libast/something > is this really something *only* ksh will trip over
IMO yes, because entering a NFSv4 xattr directory is unique for a shell. Otherwise the only way to do it is to run /usr/bin/runat <obj> <prog> which is cumbersome at best and useless if you have builtins. > or is it a more general problem that should be handled in a more general way No, I don't think so. The XATTR directory is a solution to implement filesystem forks (not fork(), file resource forks as http://en.wikipedia.org/wiki/Fork_%28file_system%29 describes). > if any other ast command/library/user could trip up over the same rigmarole > then it belongs in a common place > > and it still hasn't be explained how these fs extensions ignore > fs semantics and paradigms that until this point have been working fine since > 1970 Go and ask Apple, Novell, Microsoft why they did it? Sun only provided support for this so their servers can implement this feature to host files with these semantics. > in particular, just how many commands in the wild need -@ args now? cd(1), maybe ls(1). Roland may have a better overview. > is this an opportunity to do something like > /dev/rigmarole@.../... > and have it magically work for all ast commands/libs/plugins Hell NO. 1. In my opinion you're trying to overdesign this 2. You're breaking established features (first O_SEARCH, now cd -@). IMO it would be beneficial to get something working and then optimize it. Right now both feature are broken and that severely interrupts testing, development and operations on our side and cripples the ability to give feedback. Irek _______________________________________________ ast-developers mailing list [email protected] http://lists.research.att.com/mailman/listinfo/ast-developers
