Indeed, when invoking the command from the shell prompt using /dev/null as
input
 (pdftocio ... < /dev/null), then the command does not return an error
(i.e. exit code is 0).

So, indeed there is a difference between invoking it from Emacs and
invoking it from the
shell prompt (without the /dev/null input). This might not be considered a
bug, but it is not
trivial to me, that using call-process implies sending the null-device as
input.

Is there a way to call a process from elisp, without sending the input?
Otherwise, I would
probably change this into a 'documentation bug' report, in the sense that
it would be nice
if this detail was mentioned in the docs (I think it is not currently). I
am not sure, if this is a
case of a 'bad/wrongly designed' pdftocio command (I would say that the
command might
be well designed, but just it assumes that it is being used from the shell
prompt. However,
I am no expert on unix(/posix?) 'protocols').

On Sat, 17 Sept 2022 at 08:10, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: dalanicolai <dalanicolai@gmail.com>
> > Date: Fri, 16 Sep 2022 21:29:15 +0200
> > Cc: 57854@debbugs.gnu.org
> >
> > I don't understand the answer well (my knowledge about computers is very
> limited),
> > i.e. I do not immediately understand what it means for a file to be a
> tty.
> >
> > But also, I think the isatty() is about the TOC file, i.e. the file
> given as INFILE (after the `<`)
> > But I am not giving any INFILE (which would make the command add the TOC
> to the file given as
> > argument),
> > Instead I simply provide a single filepath as argument so that the
> command simply prints the TOC.
>
> I mentioned that aspect because it could be different between
> invocation from shell prompt and from call-process.  I didn't examine
> the Python code of the program more than look at the snipped you
> posted.
>
> Basically, I don't think this is an Emacs problem, because
> call-process faithfully reports the exit code of the program it runs.
> The reason for the different behavior is almost certainly in the
> program itself or in some factor that is different between how you
> invoke it from shell and how you invoked it from Lisp.
>