| Hi,
If I do an F$FILE_ATTRIBUTES(file_name,"RAT") and it comes back with CR
is this enough to assume that the file is an ASCII file, otherwise it's
a binary file. This is in an OpenVMS (both VAX and AXP) environment.
Thanks,
Mary.
|
|
<< What actually determines if a file is binary or ascii ?
Its data contents. At a simplistic level, binary contains unprintable
characters. It is the kind of file that when you type it by mistake,
you know it (drives terminal crazy)!
While there are sometimes clues (like if someone hasn't played games with
type/extension, .OBJ and .EXE contain binary), there is no infallible file
or record attribute (like CR) to indicate what the contents of the data
blocks contain. While it is more likely that a file created with a CR
attribute would be ASCII, there is no guarantee.
<< Is there a simple way from DCL to determine which a file is ?
No. It requires examining the contents of the data records themselves,
checking, for example, for unprintable characters and applying some
heuristic (e.g. if k of the n characters examined are unprintable,
classify as binary).
If in fact users need to be able to distinguish between ascii and binary,
there appears to be a need for some simple interface (like F$FILE_ATTRIBUTES)
to get an assessment like this done 'on the fly.'
<< For transfer protocols (i.e. ftp) I can understand why I might have to
<< transfer a binary file in binary mode, but I would have thought I could
<< transfer an ascii file in binary mode also.
Well, I have just used ftp to transfer executable images -- so I know I have to
do a binary transfer.
You imply that transferring an ascii file in binary mode doesn't work.
The question is whether you are correct. My use of FTP has been limited to
getting a remedial image to a customer so the transfer mode I do use is
binary. I just took an ascii file and followed the same steps (including
spool compress prior to the FTP) to do a "binary" transfer of the file. I
then retrieved the file, ran it to decompress it, and did a difference of it
to the original ascii file and there were no differences (either in contents
or file header attributes). I suspect the spool compress step helped.
What I would suggest is that you send your question in a mail message to
TSC::INTERNET. This will log it in CSC DSNLNK for FTP. We need someone
knowledgable on ftp for a more definitive answer.
-- Elinor
|
| I can easily see transferring an ascii file in binary mode
failing.
For example, I ran FTP on OpenVMS to PUT a two line file
(rfm=var,rat=cr) to a Digital UNIX system.
Record format: Variable length, maximum 0 bytes, longest 5 bytes
Record attributes: Carriage return carriage control
On the OpenVMS side both lines were five letters long, the
wrods "hello" and "world". On the Digital UNIX side the
received binary file was the ten bytes "helloworld" with no
newline characters (not between the words, not at the end).
When reading a (rfm=var,rat=cr) file on OpenVMS, the meaning
of the "rat=cr" is that the data in each record should be
considered as being different lines. For example, read my
(rfm=var,rat=cr) file one character at a time with the C
run-time library and you get the sequence
h e l l o '\n' w o r l d '\n'
The newline characters ('\n') are not in the records stored in
the RMS file, they are there because that is what "rat=cr"
*means*.
At least to the C run-time library, opening such a file in
binary mode means you ignore the "rat=whatever" and return
just the contents of the records,
h e l l o w o r l d
And that was exactly what was received on the Digital UNIX
side when the FTP PUT command was done from the OpenVMS side
in BINARY mode. The transfer did exactly what I told it to
do. This is the *meaning* of accessing the OpenVMS file in
binary mode. Feel free to argue that it really isn't and I've
just been working with VAX C and DEC C for too long. :-)
Dan
|
|
Look around for previous discussions containing `printable' -- there
have been questions from folks in the past seeking to prevent files
that are effectively not printable from reaching a printer...
As has been mentioned here, and before, there's no robust way to do
this under OpenVMS...
File extension (eg: MIME encoding) and some basic file attribute
filtering is about the closest one can get to this goal...
(It would have been nice if this attribute were present in VMS V1.0
and had been subsequently honored and maintained, but it wasn't...)
|