Date: Mon, 15 Dec 2003 13:04:29 +0200 From: Sheldon Hearn <sheldonh@starjuice.net> To: Alexey Dokuchaev <danfe@nsu.ru> Cc: cvs-all@freebsd.org Subject: Re: cvs commit: src Makefile.inc1 Message-ID: <20031215110429.GR13737@starjuice.net> In-Reply-To: <20031215105909.GA97471@regency.nsu.ru> 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> <20031215105909.GA97471@regency.nsu.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
On (2003/12/15 16:59), Alexey Dokuchaev wrote: > > 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. Agreed. > 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. Well, either way, the script relies on extensions to the POSIX environment. To me, providing stat(1) seems like a tidier move forward. ls(1) is already bloated. However, this is a gut feeling, and thus bikeshed fodder. NetBSD already has stat(1). So in the face of a bikeshed decision, I'm happy to paint ours the same colour as theirs. :-) Ciao, Sheldon.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20031215110429.GR13737>