Date: Mon, 15 Dec 2003 16:59:09 +0600 From: Alexey Dokuchaev <danfe@nsu.ru> To: Peter Jeremy <PeterJeremy@optushome.com.au>, Mark Murray <mark@grondar.org>, Dag-Erling Sm?rgrav <des@des.no>, src-committers@freebsd.org, cvs-all@freebsd.org, cvs-src@freebsd.org Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <20031215105909.GA97471@regency.nsu.ru> In-Reply-To: <20031215104647.GO13737@starjuice.net> References: <xzp7k101xfd.fsf@dwp.des.no> <200312141136.hBEBa2pD043994@grimreaper.grondar.org> <20031215083703.GB956@cirb503493.alcatel.com.au> <20031215095049.GA78800@regency.nsu.ru> <20031215104647.GO13737@starjuice.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Dec 15, 2003 at 12:46:47PM +0200, Sheldon Hearn wrote: > On (2003/12/15 15:50), Alexey Dokuchaev wrote: > > > Frankly, adding an option to ls(1) or writing ls(1) -l/awk(1) combo > > takes my vote, rather than adding yet another foo(1) utility to the > > base; especially provided that its functionality isn't strictly > > orthogonal. > > Hmmm, I don't know. POSIX suggests that scripts should not rely on the > output of formatted ls(1) output. Yes, that's why having stat(1) in -CURRENT is OK. Since we hardly can claim 4.x as fully POSIX-compliant, dealing with "ls/stat" trade-off via ls(1) is not that bad. After all, if we hack needed (minor) functionality into ls(1) and provide new command line option, we can avoid cumbersome parsing of `ls -l' output, yet not pulling stat(1) from -CURRENT at the same time. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031215105909.GA97471>