143109 - [ps] If "Print Command" doesn't exist Mozilla doesn't tell anything.

Status: VERIFIED DUPLICATE of bug 102276

(Core :: Printing: Output, enhancement, P4)

Description

[Carles Pina i Estany]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0+) Gecko/20020505
BuildID:    2002050521

If I print some web page and the "lpr" or print command that I have configured
doesn't exist, Mozilla doesn't warn me.

Reproducible: Always
Steps to Reproduce:
1. Go to some Web page
2. Go to File - Print - Properties and write some "Print Command" that doesn't exist
3. Waits some error message...

Actual Results:  The page isn't printed, I am not warned, etc.

Expected Results:  Mozilla should warn me?

Comment 1

[sujay]

Boris, can you reproduce? DUP ?

Comment 2

[Roland Mainz]

Well, we do have error codes in the print system for this case
(|NS_ERROR_GFX_PRINTER_CMD_NOT_FOUND|) - but I did not know exactly if and how
we can get an error for this case from |popen()| (therefore I did not implement
it... ;-( ) ...

... does anyone have a suggestion how to implement this ?

Comment 3

[Carles Pina i Estany]

Hi Roland,

In what file from source code you do the "popen"?

In mozilla/gfx/src/ps/nsPostScriptObj.cpp , line 2092 you "test" if pipe is NULL
or isn't NULL, no?

This doesn't work? or the "print command" is in more parts of source code?

If the popen return some wihout sense, you can test if the file exist with
"fopen" , "stat" or something else, no?

Good luck; and man popen tells that if popen fails return NULL ¿?

Comment 4

[Roland Mainz]

Carles Pina i Estany wrote:
> In what file from source code you do the "popen" ?

mozilla/gfx/src/ps/nsPostScriptObj.cpp

> In mozilla/gfx/src/ps/nsPostScriptObj.cpp , line 2092 you "test" if pipe is 
> NULL or isn't NULL, no?
>
> This doesn't work? or the "print command" is in more parts of source code?

AFAIK it calls first the system's default shell (/bin/sh) which processes the
passed string (incl. arguments). We would have to use something different than
|popen()| to check for any errors...

> If the popen return some wihout sense, you can test if the file exist with
> "fopen" , "stat" or something else, no?

Nope. This will not work since the first word may be a variable expression and
not the command itself (think about constructs like "xyz=myfile_$(date
+%y%m%d%H%M%S).ps ; tee $xyz | tail" or "tee mypsfile.ps | lpr" as command
string).

The only fix I could imagine is to look (again) how Xprt handles the problem
(completly different solution) and port it over to our code - however this would
be incompatible(=nothing we could "fix" this close to the 1.0 release) to the
current solution since we loose the flexibility provided of the shell invoked by
popen() ...

Comment 5

[Carles Pina i Estany]

Look what returns pclose. pclose returns 0 if the command works fine, and
different of 0 (I think) if the command isn't execute:

int main () {
        FILE *a;
        int i;

        a=popen("/usr/bin/touch hola","w");

        i=pclose(a);
        printf("pclose: %d\n",i);
}

change "touch" by "asdf" and see the differences.

I must to go out now... 

Comment 6

[Carles Pina i Estany]

In mozilla/gfx/src/ps/nsPostScriptObj.cpp

    /*Modified by Carles Pina <is08139
    if(pclose(pipe)!=0) {
          printf("I cannot print!\n");
          return NS_ERROR_GFX_PRINTER_CMD_FAILURE;
    }

Printf works fine; but Mozilla doesn't show any dialog (althouth
NF_ERROR_GFX_PRINTER_CMD_FAILURE is returned). Later I will read more source code...

Comment 7

[Carles Pina i Estany]

I don't know why, but with my "little patch", if I print to some directory where
I haven't permision, Mozilla do a "Segmentation fault".

And If I try something like this:

------------
    /*Modified by Carles Pina <[e-mail]>*/
    if(pclose(pipe)!=0) {
          printf("I cannot print!\n");
          ret=NS_ERROR_GFX_PRINTER_CMD_FAILURE;
    }

    PR_LOG(nsPostScriptObjLM, PR_LOG_DEBUG, ("piping done, copied %ld bytes.\n",
job_size));
  }
  /*Modifed by Carles Pina*/
  return (ret==NS_ERROR_GFX_PRINTER_CMD_FAILURE?ret:NS_OK);
--------
where ret is int ret=NS_OK; too do "Segmentation fault".

Later I will study why, or if somebody knows it :-)
(It is possible that the source code without my modification do it too...; but I
doubt)

Comment 8

[Boris Zbarsky [:bzbarsky]]

Are you unconditionally calling pclose() without checking the return value of
popen() first?

Comment 9

[Carles Pina i Estany]

If popen fail return 0, and after popen there is an if:

Comment 10

[Carles Pina i Estany]

If popen fail return 0, and after popen there is an if:
if(!popen(pipe)) return bla bla bla;

then, when we do "pclose", pipe is valid...

After, I will compile with the original nsPostScriptObj.cpp ot see if too fails
when is printing to a invalid destination.

Is this the correct place to discuss it? (I don't know, so if is wrong excuse me
and tell me the right place)

Comment 11

[Carles Pina i Estany]

Oops...

With this system to check if print command works fine:
int main () {
        FILE *a;
        int i;

        a=popen("/bin/ls -la | /bin/cat > /dev/null","w");

        if (pclose(a)!=0) {
                printf("fail\n");
        }
        return 1;
}

If the last command (in the example "cat") don't exist, I can detect it.
But if the first command don't exist, I cannot detect it.

Then, this is the wrong way to do this.

Other system to do this with Xprt handles, as  Roland Mainz  commented at
comment 4. 

Other system should be if print command return data through stdout or only
through stderr. Should be this a correct way to do this? I suppose that Xprt
handles is better... 

Thank you very much for your patience.

Comment 12

[Carles Pina i Estany]

One comment more, without little patch about "if (pclose(pipe)!=0)" my build too
crash when I try to print to a file without write permision at directory. I
suppose that it is an old bug (my source is from some days, the nightybuild
works fine).

Comment 13

[Roland Mainz]

Taking myself...

Comment 14

[Roland Mainz]

Attachment: Patch for 2002-05-08-08-trunk which demonstrates that |pclose()| does not work

The patch demonstrates that |pclose()| does not work... ;-(
I am getting everytimes a value != -1 regardless what I enter as command.

Just look at this debug output (created via % export
NSPR_LOG_MODULES=nsPostScriptObj:5) - an attempt to print using the
(non-existing) command "sfsdfsdfsdfsd":
-- snip --
we don't handle eBorderStyle_close yet... please fix me
WEBSHELL+ = 4
Trying to position a sizeless window; caller should have called sizeToContent()
or sizeTo(). See bug 75649.
WEBSHELL- = 3
1[94518]: nsPostScriptObj::end_document()
1[94518]: piping job to 'sfsdfsdfsdfsd'
sh: sfsdfsdfsdfsd: not found
1[94518]: piping done, copied 285785 bytes; pclose() returned 256.
1[94518]: nsPostScriptObj::~nsPostScriptObj()
1[94518]: nsPostScriptObj::~nsPostScriptObj(): printing done.
-- snip --

Passing valid commands looks similar...

Comment 15

[Pete Zha]

I think this is dup of bug 102276

Comment 16

[Pete Zha]

*** This bug has been marked as a duplicate of 102276 ***

Comment 17

[sujay]

verified