unix file system

[Curtis Jackson]

In article <3287 at decwrl.UUCP> jcampbell at mrfort.DEC (Jon Campbell) writes:
>    1.  The FORTRAN language requires that one be able to  have  "random
>    access"   files,  with  a  fixed  "recordsize".   The  obvious  UNIX
>    implementation is one which uses a fixed number  of  bytes  (perhaps
>    even with a <newline> at the end) for each "record".  However, there
>    is no way on UNIX that one can open such a file  and  find  out  the
>    size  of  each  record.  Thus it is impossible to write a utility to
>    look at, modify, or extract data from such a file without  the  user
>    having previous knowledge about the file.
> 
So write a teeny-weeny little function that calls fopen first and then
looks at the first word (16 or 32 bits, I don't care) that will contain
the record size because the writing program put it there.

>    2.  As you probably know, most FORTRAN output data files reserve the
>    1st  character  position of each output line for a "FORTRAN carriage
>    control  character".   When  the  file  is  printed  (or,  in   some
>    circumstances,  typed)  these  control characters are supposed to be
>    translated into corresponding vertical motion  characters  (such  as
>    one  or  more line-feeds, a form-feed, a vertical tab, etc.) and the
>    <newline> character at the end of the "record" is removed.
> 
>    So FORTRAN output files  are  "different"  than  other  files,  even
>    though  you  cannot  tell  that  by looking at them - they just have
>    "funny numbers" in the 1st character position of  each  line.   UNIX
>    provides   a  utility  for  piping  the  FORTRAN  output  through  a
>    translator module, so that the  vertical  motion  characters  appear
>    directly  in  the  output  file.   But  often  that  is  not what is
>    desirable.  Often one wants  to  leave  the  file  in  its  original
>    ("FORTRAN  data  file")  state, modify it many weeks later, and then
>    print it.  Again, as in the case above, the user must know that  the
>    file  was  produced  by  a  FORTRAN  program and pipe it to a filter
>    program on the way out to the printer or terminal.
> 
I don't just go around randomly printing files without knowing what they
are, do you?  I often use the 'file' command to see what type of file
I am dealing with -- nroff input, ascii data, C source, etc.  I can
see a addition to the 'file' command to recognize the types of FORTRAN
output files you are talking about, but nothing more.  "...the user must
know that the file was produced by a FORTRAN program..." -- the FORTRAN
user has to know that a file is random access before trying to open it
as such; what is the big deal?

>    3.  The ANSI Magnetic Tape Label Standard  defines  a  set  of  file
>    attributes  in the file labels which must be filled in when the tape
>    is written.   Among  them  are  record  size  and  carriage  control
>    (referred to in the Standard as "Form Control").
> 
And if I get a tape in 'tar' format I don't run cpio on it to extract it;
so if I get a tape that I know has byte-for-byte data on it I don't try
to read and process record size or carriage control fields.

>File type (for "data management" programs...)
>  Sequential (the default)
>  Others (user-definable, for various flavors of other types
>        of access, such as [ugh] indexed sequential, database, etc.)
> 

I've pulled the above example out of the original posting as a good
example of what Jon wants to do.  If the 'others' are user-definable,
then why not let the users define them?  Why should they be part of the
Unix filesystem?

Don't mess with my Unix to support archaic languages/formats!!
-- 

The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson	...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj
			...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj