Re: Cat a directory

2003-10-19 Thread Nicholas Holley
Karlsson Mikael HKI/SOSV wrote:

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.
Try http://www.mandrakelinux.com/en/

___
[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

2003-09-23 Thread Jerry McAllister
 
 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.

I hate all those colors.  Most of them are very hard to see and
make the whole thing harder to read.  And, if you adjust them to
be readable, they mostly look too much alike to be of any significant
help.  So, don't change the default shell or ls.

jerry

 --
 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: Cat a directory

2003-09-22 Thread Mark Terribile

I hesitate to step into the fray; it appears that
the phrase `more heat than light' now applies.  But
...

 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: ...

(One of my favorite bugs: the key-bug: ``If the
complex
hyperbolic arctan2 routine didn't give the wrong
answer
for arguments of ( -1, -1 ), ( -1, -1 ) the operating
system scheduler would lock up.'')

 ... my problem is people using cat on directories. 

Is your problem that people use cat on directories,
or that your purpose is to cater to people who, for
want of training that you are yet to give them,
don't know not to use cat on directories?

 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 ... But then FreeBSD spits out crap ...

One program's crap is the file system's meat.

My recollection, which I cannot test at the moment,
is that on at least some of those OS's it is the OS
itself which refuses to allow cat(1) to open the file,
giving an EISDIR on the attempt.  One could argue
that Linux found it necessary to do so because Linux
supports so many file system types that you couldn't
interpret the directory contents anyway; they all have
different internal structures; and that this indicates
that Linux is, in this area, more advanced.  It's
certainly a plausible argument--when applied to this
part of the OS's interface.  (Aside to the BSD team:
does the Linux personality module get this right?)

 ... which I can't see the point of ever using
 anywhere even when piping a tube up your ass!

Why do we call it blue language when it is in the
deep infrared?  It really looks bad in print; let's
please just avoid it.

 But since newbies do this frequently it shouldn't
 be possible to do so.

If you're providing the accounts to them, then put
the appropriate alias in their  .profile  or  .login
files, or add a path component pointing to a nubi-bin.
When they take off the training wheels, they can
remove the alias or the path component.  Until then
their safety is your concern.

If someone else is providing the accounts, perhaps
the someone else is open to suggestions, especially
if they also have to deal with this problem?

 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
 ... Man I must of mised that in school ... right?

Please, this is something about which reasonable
people can disagree.  Linus and his team obviously
disagree with the FreeBSD team; I think they are all
reasonable people, even though I sometimes disagree
with one or another of them.  There, you see: several
proofs-by-example.

[Ruben de Groot]
 So why don't you for example alias cat to cat -v
 in your system profile ...

 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 ...

The case CAN be made both ways.  If these are CS
majors, they probably should get used to learning
by picking up clues from their environment; that's
how most programs are debugged and they have to learn
the skills.  If they are admins-in-training, the case
is even stronger.  So long as the terminal doesn't
lock up, this is a good chance for them to develop
trained curiousity.  On the other hand, if you are
serving accounting majors or paralegals, they would
probably be better served by the error message.
(Race car drivers and taxicab drivers go to different
schools, except in NYCity and Boston.)

It's easy to write a script that runs file(1) on the
targets and cat(1)s those when the output includes
[tT]ext but puts a message on 2 (standard error)
otherwise.  Install that as an alias, or in a path
component, and the job is done, probably in less
time than we've spent writing these essays.

Now think about having to do that on a non-UNIX OS.
It might be very hard.  It might even be impossible.

 ... And while we're on the subject... 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.

Well, I think it's the file type, not the suffix, that
determines the color, but my only concern is to shut
the frotzenglarken color off whenever I meet a Linux
system, since it makes it harder for me to read the
screen rapidly.  I don't deprive all users of it, I
just free myself from it.

You see, reasonable people can disagree.  Unreasonable
people argue, fume, fulminate and fester.  And yes,
from time to time I get unreasonable, too.  Not that
I'm proud of it.  It's putting immediate satisfaction
ahead of reaching my goals.  And it looks really bad
in print.

  Mark Terribile
 === The 

Re: Cat a directory

2003-09-22 Thread Chris Pressey
On 22 Sep 2003 09:06:00 +0300
Karlsson Mikael HKI/SOSV [EMAIL PROTECTED] wrote:

 [...]
 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.
 
 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!!!

Mikael,

Please understand that FreeBSD is more oriented towards classicists,
luddites, and other sticks-in-the-mud, than propellerhead early
adopter users-to-be-friendly-to.  (At least, it used to be; I honestly
have no idea what's going on in 5.x these days.)

Anyway, why not write a script for these users along the lines of:

  #!/usr/bin/perl

  foreach $f (@ARGV)
  {
if (-d $f) {
  print cat: $f: is a directory\n;
  exit 1;
}
  }
  system cat @ARGV;

Also, I believe 'GNU ls', in the ports, supports coloured directory
listings.

-Chris
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Cat a directory

2003-09-22 Thread Damian Gerow
Thus spake Chris Pressey ([EMAIL PROTECTED]) [22/09/03 11:54]:
 Also, I believe 'GNU ls', in the ports, supports coloured directory
 listings.

As does FreeBSD's ls.  From 'man 1 ls':

-G  Enable colorized output.  This option is equivalent to
defining CLICOLOR in the environment.  (See below.)

I'll leave the rest for you to read.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Cat a directory

2003-09-22 Thread Matthew Seaman
On Mon, Sep 22, 2003 at 08:54:16AM -0700, Chris Pressey wrote:
 
 Also, I believe 'GNU ls', in the ports, supports coloured directory
 listings.

Have you tried typing 'ls -G' using the system ls(1) recently?

Cheers,

Matthew

-- 
Dr Matthew J Seaman MA, D.Phil.   26 The Paddocks
  Savill Way
PGP: http://www.infracaninophile.co.uk/pgpkey Marlow
Tel: +44 1628 476614  Bucks., SL7 1TH UK


pgp0.pgp
Description: PGP signature


Re: Cat a directory

2003-09-22 Thread Chris Pressey
On Mon, 22 Sep 2003 12:01:15 -0400
Damian Gerow [EMAIL PROTECTED] wrote:

 Thus spake Chris Pressey ([EMAIL PROTECTED]) [22/09/03 11:54]:
  Also, I believe 'GNU ls', in the ports, supports coloured directory
  listings.
 
 As does FreeBSD's ls.  From 'man 1 ls':
 
 -GEnable colorized output.  This option is equivalent to
   defining CLICOLOR in the environment.  (See below.)

Yes, but actually, I was mistaken; neither FreeBSD's ls nor GNU ls seems
to support coloured directory listings in the style the OP indicated:

 [Mikael Karlsson]
 As it would make finding certain files easier by coloring them
 differently depending on their ending.

I can't find any way to get either of these ls programs to colour based
on (say) sh-style regexps.  But there's probably a program out there
somewhere that does...

-Chris
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Cat a directory

2003-09-22 Thread Warren Block
Karlsson Mikael HKI/SOSV [EMAIL PROTECTED] wrote:

 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!!!

This might all be based on a misunderstanding.  Using cat on a directory
is not producing useless garbage.  For example, try

cat /etc | hexdump -C   # UUOC, I know

Section 18.02 in O'Reilly's Unix Power Tools (if you don't have it
already, get it) describes this in more detail.

Modifying cat so it couldn't do this would not be an improvement.

I hope this helps, and thanks for giving me the motivation to look it
up.

-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

2003-09-19 Thread Ruben de Groot
On Fri, Sep 19, 2003 at 08:27:00AM +0300, Karlsson Mikael HKI/SOSV typed:
 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.
 
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.

 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.

Why not? I regularly use constructs like this:

cat somebackup.tgz | ssh someserver cd /somedir; tar xzf -

 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?

Because less != cat. It has a completely different functionality.

Ruben

 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]
 

-- 
The world is coming to an end.  Please log off.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]


Re: Cat a directory

2003-09-18 Thread Dan Nelson
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]


Re: Re: Cat a directory

2003-09-18 Thread Bill Campbell
On Fri, Sep 19, 2003, Karlsson Mikael HKI/SOSV wrote:
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.

Teach them to use ``less'' instead of cat.  It doesn't have a problem with
binary files (and DOS/WIN users have to be retrained in any case since they
would normally use ``type'').

Bill
--
INTERNET:   [EMAIL PROTECTED]  Bill Campbell; Celestial Software LLC
UUCP:   camco!bill  PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186  Mercer Island, WA 98040-0820; (206) 236-1676
URL: http://www.celestial.com/

``Find out just what people will submit to, and you have found out the
exact amount of injustice and wrong which will be imposed upon them; and
these will continue until they are resisted with either words or blows, or
both. The limits of tyrants are prescribed by the endurance of those whom
they oppress.'' -- Frederick Douglass.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to [EMAIL PROTECTED]