Jim Meyering wrote: > Actually, ever since find got its -printf option, I've thought of > adding the same to ls. But the size of the code addition as well as > the logistics (this was before gnulib) were off-putting, not to mention > the fact that this is ls, after all. That combined to make the overall > cost/benefit ratio appear way too high. > > Here are my questions: > > - is it worthwhile to add a --printf option to ls? > I don't like the --user-format name) > > - if so, should it use use a find -printf-compatible format string > or one compatible to stat --printf? Either way, it'll need a few > extensions.
So there would be 3 large interfaces to try and find commonalities in and maintain. > I'm still on the fence. On the one hand, I don't like to bloat > ls further, even if it ends up using code that's shared with GNU find. > On the other, I understand and sympathize with the desire to make ls > output more useful/readable. > > Finally, if investing in ls, I'd rather invest in converting it to use > fts for its hierarchy traversal. I'm on the fence too, but more on the bottom rung. I don't think the interface pollution cost to the benefit gained is worth it. ls -l has good defaults for me. Infrequently I want other info which other options to ls, or stat provide already. I'm also reminded of http://examples.oreilly.com/upt2/#sls The main use case there is for processing by scripts, which find --printf is sufficient for now. Going forward I would add extra formats to `find --printf`, with a view to keeping them in sync with `stat --printf`. cheers, Pádraig. _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils
