| Summary: | exit status zero when ioerror closing pdfwrite device | ||
|---|---|---|---|
| Product: | Ghostscript | Reporter: | Karl Berry <karl> |
| Component: | PDF Writer | Assignee: | Ken Sharp <ken.sharp> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | ghostpdl-bugs |
| Priority: | P2 | ||
| Version: | 10.03.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Customer: | Word Size: | --- | |
| Attachments: | test-simple.eps | ||
|
Description
Karl Berry
2024-04-26 15:58:39 UTC
OK so there's a degree of confusion here, not surprisingly given the unfortunate number of Ghostscript parameters. PDFSTOPONERROR won't help you here, not at all. That's because PDFSTOPONERROR tells the **PDF** interpreter to stop and throw errors when something goes wrong, rather than carrying on. That's what the bug report 705506 is all about. Since your input is **PostScript** (EPS file) the PDF interpreter isn't involved. So adding PDFSTOPONERROR with -dNOPAUSE wouldn't help you, and we wouldn't do it anyway. The point of having fine-grained controls is so that you can make those decisions yourself. The pdfwrite device is correctly throwing a PostScript error, as we can see from the partial back channel you reported. Because that is happening when the PostScript interpreter is closing down (we don't close the pdfwrite device until then), it's too late for a 'normal' PostScript error report, which is why you don't get the full stack trace and so forth, but we can see the error. The problem you are running into is that the default example Ghostscript application is ignoring the error returned when the interpreter is closing down. I don't think this has changed(*) so any scripts that have been used for decades won't have become silently any more unreliable than they were previously. * It happens that this has already been reported in bug 707659 and I agreed with the reporter there that this was, at the very least, surprising behaviour. So I fixed the problem in commit 2472a03535634164f902acb49517e46e1b6766e7 Now I don't happen to have a full file system to check this on, but I altered the pdfwrite device to return an ioerror on close and checked that. With the commit above in place the exit code is now -1, whereas with 10.03.0 it was 0. Thanks for the explanations. 1) The behavior (exit status) of the stated invocation did change between 10.02.0 (status=1) and 10.03.0 (status=0). That's why I put 10.03.0 as the version for this report, though I see I forgot to explicitly say so. Sorry about that. 2) You can use /dev/full to check full filesystem behavior on at least some systems, as shown in my example. But I'm guessing you already know that. 3) Very glad to hear about the fix being already committed. Although a negative exit status confuses me. I thought exit statuses, on Unix, were unsigned numbers between 0 and 255, which I imagine you also know perfectly well. I suppose -1 will end up being 255, so fine ... Thanks again, Karl (In reply to Karl Berry from comment #2) > 1) The behavior (exit status) of the stated invocation did change between > 10.02.0 (status=1) and 10.03.0 (status=0). That's why I put 10.03.0 as the > version for this report, though I see I forgot to explicitly say so. Sorry > about that. Odd, I didn't find a change like that when I made the commit. > 2) You can use /dev/full to check full filesystem behavior on at least some > systems, as shown in my example. But I'm guessing you already know that. Doesn't work on Windows though, which is what I'm using. > 3) Very glad to hear about the fix being already committed. Although a > negative exit status confuses me. I thought exit statuses, on Unix, were > unsigned numbers between 0 and 255, which I imagine you also know perfectly > well. I suppose -1 will end up being 255, so fine ... Its 255 on Linux, in any event it's non-zero. |