Date: Mon, 30 Apr 2001 10:54:56 +0200 From: Raymond Wiker <Raymond.Wiker@fast.no> To: stable@FreeBSD.ORG Subject: Re: tail Message-ID: <15085.10336.706403.988118@raw.grenland.fast.no> In-Reply-To: <20010430110352.A646@iv.nn.kiev.ua> References: <Pine.BSF.4.21.0104301632200.43352-100000@lists.unixathome.org> <KPECIILENDDLPCNIMLOFOEOICCAA.juha@saarinen.org> <20010429222205.A29058@praxis.lunabase.org> <20010430110352.A646@iv.nn.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
Valentin Nechayev writes: > Sun, Apr 29, 2001 at 22:22:05, faber (Ted Faber) wrote about "Re: tail": > > > > juha@cyrus:~$ tail / > > > tail: /: Is a directory > > > > > > More desirable behaviour, IMO. > > > > FYI, and maybe surprisingly, you're about to start a flame war. BSD > > tail and related tools have been treating directories as files for > > *many* years. > > Can you please prove nesessarity of such behavior, as really useful examples > of cat/tail of directory, or an example of needed compatibility? > If no (and I am sure that you has no such examples), you should consider > badness of writing arbitrary binary data to terminal. E.g., xterm & screen > terminals can be dropped to unrepairable state in such way. In that case, you also need to "fix" tail, cat etc so that you cannot use them on binary files, or even text files that contain character codes that *might* upset the current terminal. BTW: xterm can be repaired by selecting "Do Full Reset", possibly in combination with typing the command "reset", followed by a line-feed character (Ctrl-J). I cannot remember a case where this didn't work. > In the earliest UNIX systems, there were no network, VM, and even chdir > was an external command which modifies parent's current directory. > Do you really want to keep such legacy now? Your idea for unrestricted > directory reading is from the same series. chdir has never been, and couldn't possibly be, an external command in Un*x. (It *is* an external command in MS-DOS, though.) > There are too many programs in unix tool set which requires such > fixing, and it's better to fix them directly instead of total > wrapping, isn't it? If you require compatibility with bugs of > ancient crap, you'll work on crap. The problem is that being able to do tail on a directory is *potentially useful*. Disallowing the use of tail on a directory is *not* going to make the system noticeably more robust or user-friendly. //Raymond. -- Raymond Wiker Raymond.Wiker@fast.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15085.10336.706403.988118>