I sent a more detailed response via e-mail. This is a more general
reply to the list because I believe this represents an interesting
problem.
Printing apparently uses the "magic rules" in /usr/share/magic to
determine file type for printing.
The original Unix "magic" system used the first two bytes of a file
to identify type, and the "magic numbers" chosen for binary files
did not correspond to valid ASCII characters, so arbitrary ASCII
files could not be mistaken for a binary file type, e.g. an executable.
This was fairly robust.
Gradually, the "magic system" has been extended to include rules for
a large number of file types, some of which don't have very distinctive
characteristics. If I read the current rules correctly, any ASCII file
in which bytes 1082 and 1083 are "CH" will be a ...sound file. This is
not very robust, and with Linux being used by large numbers, a certain
percentage of ASCII files are going to be mis-identified. These files
will then fail to print correctly.
I don't have a solution. I do agree that it is useful for the printing
system to automatically identify files and treat them with the
appropriate
filter. It is good to have the "file" utility make a guess as to file
type. I don't like the idea of having a separate "more robust" file
identifier for printing. I don't like having random print failures of
ASCII files which just happen to have "CH" at the "wrong place".
Perhaps this will start a discussion which will produce a clever
improvement
to the printing system.
John DeDourek
Faculty of Computer Science
University of New Brunswick
Fredericton, N.B. Canada
Steve Dixon wrote:
>
> We have had a number of instances over the last month where we have
> received the following message when our application has output reports
> to the lpr subsystem on RedHat Linux 6.0:
> No way to print this type of input file: ES-channel Fasttracker
> "oktalyzer" module sound
>
--
To unsubscribe:
mail -s unsubscribe [EMAIL PROTECTED] < /dev/null
