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
>> 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
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to