Re: Re:Re: Cat a directory
> > > Now, either contribute something or be done with it. > > I contributed a few clear, well-argumented reasons in favor of my position ^^^ wrong reasons > that "cat" should change its default behavior. You, otoh, have only > demonstrated that you are a bully, and that you can yell real loud. Well, > that don't impress me much. Just some people seem to need it. Get a life. Bye, jerry > > - Mark > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re:Re: Cat a directory
[it seems I forgot a paragraph] - Original Message - From: "Jerry McAllister" <[EMAIL PROTECTED]> To: "Mark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, September 25, 2003 4:21 PM Subject: Re: Re:Re: Cat a directory > > I would like to see a switch added to cat, like "-d", which specifically > > allows it to operate on directories too, for that once-in-a-million > > chance I actually need a hex dump on the directory as file. In fact, > > that behavior is already incorporated in the "rm" command: > > Again, rm is something very different. But nonetheless very illustrative of how the OS takes into consideration an unexpected, and probably unintended, behavior; namely, unlinking a directory, whereas the user expects it to operate on regular files. Hence, by default, it does NOT unlink directories, and only does so when you specifically add the -d (-r) override. And that, to me, makes perfect sense. Moreover, I feel the same logic should apply to "cat". > If you want a special flag to make cat treat directories specially, > then go ahead and write it and submit it. BUT DO NOT CHANGE THE > DEFAULT BEHAVIOR OF CAT OR YOUR MODIFICATION WILL BE REJECTED BECAUSE IT > WOULD BREAK THOUSANDS OF SCRIPTS AND BE FOOLISH AND UNNECESSARY Uh-uh; and no default behavior has ever been changed over the years, eh? :) And what is with these "thousands of scripts" that would suddenly break horribly? So far, I have only heard one good scenario: a specific instance where one would wish to obtain a hex-dump on the actual contents of the directory file; and I even doubt such a use would find its way to a script (as it would probably be a one-time use for debugging/finding lost files or something). In 99.9 percent you will find that "cat" is used on regular files. That figure is actually probably closer to 99.9 percent; but I'll be mild. When you spell it out like that, what should be allowed to call itself "default behavior" becomes clear. > Now, either contribute something or be done with it. I contributed a few clear, well-argumented reasons in favor of my position that "cat" should change its default behavior. You, otoh, have only demonstrated that you are a bully, and that you can yell real loud. Well, that don't impress me much. - Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re:Re: Cat a directory
- Original Message - From: "Jerry McAllister" <[EMAIL PROTECTED]> To: "Mark" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Thursday, September 25, 2003 4:21 PM Subject: Re: Re:Re: Cat a directory But nonetheless very illustrative of how the OS takes into consideration an unexpected, and probably unintended, behavior; namely, unlinking a directory, whereas the user expects it to operate on regular files. Hence, by default, it does NOT unlink directories, and only does so when you specifically add the -d (-r) override. And that, to me, makes perfect sense. Moreover, I feel the same logic should apply to "cat". > If you want a special flag to make cat treat directories specially, > then go ahead and write it and submit it. BUT DO NOT CHANGE THE > DEFAULT BEHAVIOR OF CAT OR YOUR MODIFICATION WILL BE REJECTED BECAUSE IT > WOULD BREAK THOUSANDS OF SCRIPTS AND BE FOOLISH AND UNNECESSARY Uh-uh; and no default behavior has ever been changed over the years, eh? :) And what is with these "thousands of scripts" that would suddenly break horribly? So far, I have only heard one good scenario: a specific instance where one would wish to obtain a hex-dump on the actual contents of the directory file; and I even doubt such a use would find its way to a script (as it would probably be a one-time use for debugging/finding lost files or something). In 99.9 percent you will find that "cat" is used on regular files. That figure is actually probably closer to 99.9 percent; but I'll be mild. When you spell it out like that, what should be "default behavior" becomes clear. > Now, either contribute something or be done with it. I contributed a few clear, well-argumented reasons in favor of my position that "cat" should change its default behavior. You, otoh, have only demonstrated that you are a bully, and that you can yell real loud. Well, that don't impress me much. - Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re:Re: Cat a directory
> > However, the purpose of "cat" is to write the contents of a file to STDOUT. > And yes, in UNIX pretty much everything is considered a file. But that does > not change the fact that people do not experience a directory as a file, and > in their use of language also clearly differentiate between the two. You > too. Besides, for the regular use of writing the contents of a directory to > STDOUT, "ls" was created. > > Using "cat /bin" is a poor example, because everybody KNOWS /bin is a > directory. But how about using a more realistic example? Say, "cat > /usr/libexec/sendmail"? That happens to be a directory, but could easily be > mistaken for a regular file (when found in a find output, for instance). And > then a lot of crap scrolls through your terminal, which is potentially > DANGEROUS. Just because you cannot fathom a legitimate situation in which a > cat on a directory was unexpected and unintentional, does not mean that > situation never occurs. > > I would like to see a switch added to cat, like "-d", which specifically > allows it to operate on directories too, for that once-in-a-million chance I > actually need a hex dump on the directory as file. In fact, that behavior is > already incorporated in the "rm" command: Again, rm is something very different. You just don't get it do you?! If you want a special flag to make cat treat directories specially, then go ahead and write it and submit it. BUT DO NOT CHANGE THE DEFAULT BEHAVIOR OF CAT OR YOUR MODIFICATION WILL BE REJECTED BECAUSE IT WOULD BREAK THOUSANDS OF SCRIPTS AND BE FOOLISH AND UNNECESSARY Now, either contribute something or be done with it. jerry > > The options are as follows: > > -d Attempt to remove directories as well as other types of files. > > So, in like fashion for "cat": > > -d Attempt to write the raw contents of a directory too. > > - Mark > ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re:Re: Cat a directory
- Original Message - From: "Matthew Hunt" <[EMAIL PROTECTED]> To: "Karlsson Mikael HKI/SOSV" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Monday, September 22, 2003 6:26 PM Subject: Re: Re:Re: Cat a directory > "cat /bin" on Solaris 9 does exactly the same thing as on FreeBSD; shows > the contents of the directory, just like you're asking it to. Just because > you can't fathom a use for this behavior doesn't mean it's wrong. If you > don't want to see it, don't ask "cat" to show it to you. Answers like this are not uncommon. I guess because it evokes the old "This separates the men from the boys" attitude. However, the purpose of "cat" is to write the contents of a file to STDOUT. And yes, in UNIX pretty much everything is considered a file. But that does not change the fact that people do not experience a directory as a file, and in their use of language also clearly differentiate between the two. You too. Besides, for the regular use of writing the contents of a directory to STDOUT, "ls" was created. Using "cat /bin" is a poor example, because everybody KNOWS /bin is a directory. But how about using a more realistic example? Say, "cat /usr/libexec/sendmail"? That happens to be a directory, but could easily be mistaken for a regular file (when found in a find output, for instance). And then a lot of crap scrolls through your terminal, which is potentially DANGEROUS. Just because you cannot fathom a legitimate situation in which a cat on a directory was unexpected and unintentional, does not mean that situation never occurs. I would like to see a switch added to cat, like "-d", which specifically allows it to operate on directories too, for that once-in-a-million chance I actually need a hex dump on the directory as file. In fact, that behavior is already incorporated in the "rm" command: The options are as follows: -d Attempt to remove directories as well as other types of files. So, in like fashion for "cat": -d Attempt to write the raw contents of a directory too. - Mark ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re:Re: Cat a directory
> > Read my first post before reading this thing so you'll be on the right track > > > > >> Other *NIX systems seem to have done this to their cat program so why > >> can't FreeBSD? > > > >See above. FreeBSD has a better view of the world than some of the kiddie OSes. > Try to run for example "cat /bin" in Linux, HP-UX, Solaris and other *NIXes > and > I'm 90% certain that they will not show the directory but an error message > saying something. But then FreeBSD spits out crap which I can't see the point > of ever using anywhere even when piping a tube up your ass! But since newbies > do this frequently it shouldn't be possible to do so. > > >> and why is this already done to less and not cat? > > > >less is made to display files. It's the correct tool for the job. > > And you mean that cat is built to show directories and that's the right job > for > cat. Man I must of mised that in school as I thought ls was meant to show > directories, but hey that's my problem, right? So you mean you use ls to show > file contents and cat to show directories which workes fine, Or? You need to review your thinking. Cat's job is to take the contents of a file and send it to STDOUT. It has a small number of options as to for form of the output, but otherwise, that is it. It is not intended or designed to care if the file is a text, binary, directory, etc file. Just to copy file's contents to stdout, period, done, end, get a life! > > Ruben de Groot wrote (19.9.2003 13:34): > > > >So why don't you for example alias cat to cat -v in your system profile > >and login scripts? This will display non-printing characters so they are > >visible and don't mangle terminal settings. Yah, do that. It is a reasonable pervsion of cat's mission. > So it's better for a newbie to get understandable jibrish from cat when run > on > directories then an error message stating that they are trying to run cat on > a > directory like ls says when they try to run ls on a file. But as I said > earlier > who cares, right? Other OSs have only had this for "a couple" of year so why > would we!!! ls writes a formatted display of file information. That is its purpose in life. It doesn't dump contents of files to stdout. Just because another OS takes the wrong road doesn't mean that FreeBSD should also get lost. > > > >Why not? I regularly use constructs like this: > > > >cat somebackup.tgz | ssh someserver "cd /somedir; tar xzf -" > > > > Yes, but do you regularly pipe "cat /bin" to another program. If so, why? > Because isn't cp ment to copy files and directories! Different thing. Yes, cat is very often used to pipe file contents to other programs. > > >Because less != cat. It has a completely different functionality. > > I'm aware of that! But as less doesn't show directory contents like ls doesn't > show file contents I thought it would be a good example. They are very different things from cat. They both are intended to created formatted displays. > > > > >> Dan Nelson wrote (18.9.2003 17:33): > >> > > >> >I find that hard to believe. Do you also want to block catting of > >> >executables, gzipped files, jpeg files, database files, and audio > >> >files? No OS does that by default. Maybe you should teach them how to > >> >reset their terminals when they cat binary data; ^Jreset^J should work, > >> >assuming your TERM variable is set right. > > No, I don't necessarily want to add all of that but the directory part would be > a good start. And while we're on the subject of different file types why > doesn't ls support coloring of different file types like in Linux. As it would > make finding certain files easier by coloring them differently depending on > their ending. > Doesn't it?How many file types do you want to make different colors? Anyway, that seems to depend on shell. I can get color differences. jerry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re:Re: Cat a directory
On Mon, Sep 22, 2003 at 09:06:00AM +0300, Karlsson Mikael HKI/SOSV wrote: > Try to run for example "cat /bin" in Linux, HP-UX, Solaris and other > *NIXes and I'm 90% certain that they will not show the directory but > an error message saying something. "cat /bin" on Solaris 9 does exactly the same thing as on FreeBSD; shows the contents of the directory, just like you're asking it to. Just because you can't fathom a use for this behavior doesn't mean it's wrong. If you don't want to see it, don't ask "cat" to show it to you. -- Matthew Hunt <[EMAIL PROTECTED]> * Science rules. http://www.pobox.com/~mph/ * ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
