Bug 426089

Created attachment 289889 [details]
conf files

The mime.types entry is this:

application/x-shell             sh printable(0,1024) + string(0,#!) +\
                                (contains(2,80,/bash) contains(2,80,/ksh)\
                                 contains(2,80,/sh) contains(2,80,/zsh))

which checks that the first 1k of the file contains printable characters, that
the first two characters are '#!' (the "shebang"), and that the first line
contains of those recognised shell names.

What does the first line of the shell script you are trying to print look like?

Hi,
The file is in the attached zip archive. It has 

#!/bin/ksh

as the first line.
Also, as I understand, in mime.types whitespace is 'OR'; Namely, the file should
be typed `application/x-shell' just because it end with `.sh' .
I tried renaming to `cups_selective_rm.ksh' - no change.
Then I split the application/x-shell entry in two:

application/x-shell             sh
application/x-shell             printable(0,1024) + string(0,#!) +\
                                (contains(2,80,/bash) contains(2,80,/ksh)\
                                 contains(2,80,/sh) contains(2,80,/zsh))

restarted cups and now both `cups_selective_rm.sh' and `cups_selective_rm.ksh'
(exact same content) are type correctly :).

The head of mime.types documents that:

    Multiple occurrences of a type will cause the provided rules to be appended
to the existing definition.

so the two forms should be equivalent. It seems not to be the case.

Hey, further testing showed this to work too!!

application/x-shell             sh sh printable(0,1024) + string(0,#!) +\
                                (contains(2,80,/bash) contains(2,80,/ksh)\
                                 contains(2,80,/sh) contains(2,80,/zsh))

notice `sh' is doubled.
(I noticed that .html files were being typed correctly - the difference being 
that `text/html' lists two extensions.)

I think this might be to do with a bug I just filed upstream:
  http://cups.org/str.php?L2659

Believed fixed in 1.3.6-2.fc8.

I don't believe this is so.
Please look at scheduler/ipp.c line 7637:
    doc_name = ippFindAttribute(con->request, "document-name", IPP_TAG_NAME);
    filetype = mimeFileType(MimeDatabase, con->filename,
                            doc_name ? doc_name->values[0].string.text : NULL,
			    &compression);

The scheduler is looking for an attribute "document-name", BUT the client ONLY sends this attribute when printing more than one file per job:
in cups/util.c this attribute is sent in cupsPrintFiles2, BUT
cupsDoFileRequest in cups/request.c does not.

Thanks for investigating this further.

This will be fixed in CUPS 1.4 (in Fedora 11).  The fix was introduced as a side effect of fixing STR #2261 in commit 7170:
  http://cups.org/str.php?L2261

I'm afraid the fat lady has not sung yet :)

Further code review revealed a bug(?) in function mimeAddTypeRule() in scheduler/type.c that is the *real* culprit. Please see STR #3059 (that I've filed upstream) for details.
The code for v1.4 is the same so this is not resolved for Fedora 11 either at this point.

Regards,
Opher Shachar.

Changing version to 9.

cups-1.3.9-4.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update cups'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2009-1082

cups-1.3.9-8.fc10 has been pushed to the Fedora 10 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing update cups'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-1091

cups-1.3.9-8.fc10 has been pushed to the Fedora 10 stable repository.  If problems still persist, please make note of it in this bug report.

cups-1.3.9-4.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.