Date: Mon, 22 Sep 2003 01:43:23 -0700 (PDT) From: Mark Terribile <materribile@yahoo.com> To: freebsd-questions@freebsd.org, Karlsson Mikael HKI/SOSV <mikael.karlsson@hel.fi> Subject: Re: Cat a directory Message-ID: <20030922084323.83015.qmail@web21109.mail.yahoo.com> In-Reply-To: <20030922064221.5287716A4D7@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 pattern matches in this code work in ===
=== ksh and bash, but not in /bin/sh . Note ===
=== the absolute pathname. ---MaT ===
#!/usr/local/bin/ksh
for safecat_arg in ${@} ; do
safecat_ftype="$(file "${safecat_arg}")"
if [[ $safecat_ftype = *text* ]] ; then
/bin/cat "${safecat_arg}"
else
echo >&2 "${safecat_ftype}"
fi
done
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free, easy-to-use web site design software
http://sitebuilder.yahoo.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030922084323.83015.qmail>