1

In the following example using a terminal window (Ubuntu 20.04), the program ocrmypdf produces some progress bars while it is running and the last two (2) lines are printed when the program finishes. Using the Emacs function call-process and the optional arguments of DESTINATION (non-nil) and DISPLAY (non-nil), only the last two (2) lines are output to the target buffer when the program finishes. Is there a way to see progress bar output while the program is running when using the function call-process?

$ ocrmypdf input.pdf output.pdf
Scan: 100%|██████████████████████████████████| 11/11 [00:00<00:00, 229.81page/s]
OCR: 100%|████████████████████████████████| 11.0/11.0 [03:09<00:00, 17.26s/page]
JPEGs: 0image [00:00, ?image/s]
JBIG2: 100%|██████████████████████████████████| 11/11 [00:00<00:00, 11.61item/s]
INFO - Optimize ratio: 1.28 savings: 22.1%
INFO - Output file is a PDF/A-2B (as expected)
lawlist
  • 18,826
  • 5
  • 37
  • 118

1 Answers1

1

My initial thought was that the progress bars were being sent to stderr and you were only seeing stdout, but (elisp)Synchronous Processes indicates that when DESTINATION is a buffer you would get both streams interspersed; so it doesn't sound like that's the specific issue.

Nevertheless, you could try using the (REAL-BUFFER STDERR-FILE) form of DESTINATION and see if you end up with anything in your error file.

(And/or ocrmypdf ... 2>/dev/null in your proper terminal.)

Another possibility is that ocrmypdf is detecting the dumb terminal and refraining from outputting any progress bars. See whether it documents any behaviour regarding that. You could then let-bind a process-environment to pretend you're offering a more capable TERM and see what happens. (Or conversely, env TERM=dumb ocrmypdf ... in your proper terminal to see if the progress bars go away.)

If you do get it to output progress bars, you may then find yourself in need of a filter to handle that output (depending on what the process is sending).

phils
  • 48,657
  • 3
  • 76
  • 115