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: 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
[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
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
- 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: Cat a directory
Matthew Seaman wrote (22.9.2003 19:01): Have you tried typing 'ls -G' using the system ls(1) recently? Yes, I have and I even have it aliased in my .bashrc file like this alias ls='ls -F -G' so that ls will always use colors and type endings. But my point was that native BSD system ls only colors these types, outclip from man pages: 1. directory 2. symbolic link 3. socket 4. pipe 5. executable 6. block special 7. character special 8. executable with setuid bit set 9. executable with setgid bit set 10. directory writable to others, with sticky bit 11. directory writable to others, without sticky bit which are all supported in for example GNU/Linux ls, except 10 and 11, but then they have an extra option to put different coloring on files with a special ending. So that archives, moviefiles, soundfiles etc. have a special color while in BSD they're all grey/white. I know that this might seem like irritating for some and unnecessary for others but shouldn't people be given the possibility to choose for themselves and not by the big people if they want to use colors on special file endings. And I'm in no way saying that it has to come on at the same time as the normal coloring. But wouldn't it be time for people to try to expand their minds on how to make BSD a little more friendly to others then unixpros and hackers. 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. Well it might be dependent on the shell as I'm not sure about it, but as I already wrote above I think it should be up to the user to decide how many different filetype colors should be used and not to some BSD developer to say NO, won't happen! cause he doesn't like the idea. He should say Hey, that might be a good idea, why not try to see if it's possible to do. or Sure, why not, the public should get what they want.. This is exactly why open-source was started so that the people would have the power to decide what they want and not some money obsessed Gates. But it seems that development on FreeBSD has taken a turn towards dictator reign or maybe always been that way. 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. Yes, you're absolutly right that FreeBSD has a better view of the world then other OSes. But what says that there couldn't be a flag that either allowes or doesn't allow cat to read directories and maybe other files. As somebody said cat only has a few flags so far. This way cat would be able to fill both experts and newbies wishes and needs. Then FreeBSD would really have a better view on the world than GNU/Linux as it can't cat directories at all but FreeBSD users would be able to decide if they want it to be possible or not by simply using a flag. Just because another OS takes the wrong road doesn't mean that FreeBSD should also get lost. No, I agree but wouldn't it be better if a few small things like what this topic has been about could be solved rationaly. Just so that FreeBSD wouldn't get on the wrong road but still satisfy both experts and newbies. I think my suggestion about a flag to cat would be a solution and that file-ending coloring in ls wouldn't lead FreeBSD straight in to the woods, as it would be possible to turn on/off these features on demand. Modifying cat so it couldn't do this would not be an improvement. Yes, it would if it was possible to turn it on with a flag. 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. OK, as I said that I was only 90% sure that it wouldn't do that. But the thing is that I don't have a problem with using cat, but the people I help do. The thing is that most books on *NIX systems start out with simple commands like ls and cat. Most of the people I help think it's the only way to read files and by mistake specify a directory insted of a file or just for fun test it out on a directory. Then their problem becomes my problem as their terminal locks. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re:Re: Cat a directory
On Tue, 23 Sep 2003, Karlsson Mikael HKI/SOSV wrote: [...] which are all supported in for example GNU/Linux ls, except 10 and 11, but then they have an extra option to put different coloring on files with a special ending. So that archives, moviefiles, soundfiles etc. have a special color while in BSD they're all grey/white. ...so install the GNU ls port. Configure as you wish. The End. Hey, *I* think that bash ought to be the default shell in FreeBSD. But it's not. So I install bash and get on with life. -- David Fleck [EMAIL PROTECTED] ___ [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]
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: Cat a directory
On Thu, 19 Sep 2003, Karlsson Mikael HKI/SOSV wrote: I personally think that some of these tests should be added to the real distributable version of cat that comes with FreeBSD cause I can't be the only one that this bugs. I mean what could a little more code hurt to the program since cat isn't supposed to read binary files. Says who? cat works fine on binary files. The problem you are having is that people are using cat to *display* files. Fixing that problem could break cat for its more standard use: cat binaryfile | filter | etc. Other *NIX systems seem to have done this to their cat program so why can't FreeBSD? See above. 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. -Warren Block * Rapid City, South Dakota USA ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re:Re: Cat a directory
OK! I admit that it isn't THE BIGGEST problem for me BUT it is A problem. What I ment in my last mail was that it is the biggest problem concerning cat. Since someone always seems to cat a binary file without having the knowledge of what it causes. I personally think that some of these tests should be added to the real distributable version of cat that comes with FreeBSD cause I can't be the only one that this bugs. I mean what could a little more code hurt to the program since cat isn't supposed to read binary files. I could add the code myself to cat's source file and compile it so my users won't be able to cat binary files and stuff like that but what happens to the thousands of other people that is bugged by the same problem, are they supposed to do the same re-coding that I did? Or couldn't this simply be added to the distribution source file so others won't be bugged. Other *NIX systems seem to have done this to their cat program so why can't FreeBSD? and why is this already done to less and not cat? Dan Nelson wrote (18.9.2003 17:33): In the last episode (Sep 18), Karlsson Mikael HKI/SOSV said: What I just wanted to ask was if it's absolutely necessary for cat to be able to work on directories. Or if it would be possible to simply add a check to cat that tests if the file being opened is a directory and then exits with an error message if that is the case. The source is in /usr/src/bin/cat; add some code to stat the file and fail if it's a directory. The biggest problem for me as a Unix help-person at a company is to always explain to newbies and less experienced users not to cat directories as it usually scrambles or locks the whole terminal and as they then turn to me to undo their mistakes. These small simple things give our users bad thoughts about FreeBSD and often drives them to use other OSs! 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. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
