Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!chinacat!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: file attributes
Message-ID: <19441@rpp386.cactus.org>
Date: 30 Jun 91 18:17:31 GMT
References: <1833@sranha.sra.co.jp>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Cheeseburger in Paradise, Le Select, St Barts., FWI
Lines: 37

In article <1833@sranha.sra.co.jp> erik@srava.sra.co.jp (Erik M. van der Poel) writes:
>John F Haugh II writes:
>> What do you propose "grep" do with the infinite number of metadata items
>> that "data" could have associated with it?
>
>Well, grep won't even see any metadata if it calls open().

I think you just insured that your proposal is pretty useless if you aren't
going to have utilities such as grep know about your wonderful metadata.
Should grep know that grepping for text in a text file means something
different from grepping for text in a database file?

>> Programs that only take LRELC=60 text files don't know what to do with
>> an LRECL=80 text file.
>
>If you are referring to fixed record length files, you have missed the
>point completely.

No, I've not missed the point.  It doesn't matter if the attribute is
"ACCESS=keyed" versus "ACCESS=sequential" or "LRECL=variable" or whatever.
Once you start allowing =different= values for your different attributes,
any program that deals with that attribute has to be capable for dealing
with all known values of that attribute.  Users will rapidly tire of
commands that understand "keyed" and "sequential" but not "random" (or
some other example you will completely miss).

>> What makes you think UNIX could ever get it right?
>
>What makes you think UNIX could ever get anything wrong?

Gee, I don't know.  To name a topic on everyones mind right now - how
about job control?
-- 
John F. Haugh II        | Distribution to  | UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 255-8251 | GEnie PROHIBITED :-) |  Domain: jfh@rpp386.cactus.org
"UNIX signals are not interrupts.  Worse, SIGCHLD/SIGCLD is not even a UNIX
 signal, it's an abomination."  -- Doug Gwyn