From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: dalanicolai Newsgroups: gmane.emacs.bugs Subject: bug#57854: 29.0.50; Different exit code in Emacs and terminal for identical process Date: Sat, 17 Sep 2022 15:37:08 +0200 Message-ID: References: <83a66z4m9o.fsf@gnu.org> <83fsgq3517.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000e211dc05e8df9339" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17973"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 57854@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Sep 17 15:38:11 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oZY1L-0004XL-08 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Sep 2022 15:38:11 +0200 Original-Received: from localhost ([::1]:54570 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oZY1J-0007sb-RL for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 17 Sep 2022 09:38:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35814) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oZY1C-0007sT-PJ for bug-gnu-emacs@gnu.org; Sat, 17 Sep 2022 09:38:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:46307) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oZY1C-00034T-FS for bug-gnu-emacs@gnu.org; Sat, 17 Sep 2022 09:38:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oZY1C-0005SY-9n for bug-gnu-emacs@gnu.org; Sat, 17 Sep 2022 09:38:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: dalanicolai Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 17 Sep 2022 13:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 57854 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 57854-submit@debbugs.gnu.org id=B57854.166342184820943 (code B ref 57854); Sat, 17 Sep 2022 13:38:02 +0000 Original-Received: (at 57854) by debbugs.gnu.org; 17 Sep 2022 13:37:28 +0000 Original-Received: from localhost ([127.0.0.1]:45385 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZY0d-0005Rj-B1 for submit@debbugs.gnu.org; Sat, 17 Sep 2022 09:37:27 -0400 Original-Received: from mail-ej1-f49.google.com ([209.85.218.49]:46813) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oZY0b-0005RW-NC for 57854@debbugs.gnu.org; Sat, 17 Sep 2022 09:37:26 -0400 Original-Received: by mail-ej1-f49.google.com with SMTP id bj12so55054437ejb.13 for <57854@debbugs.gnu.org>; Sat, 17 Sep 2022 06:37:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date; bh=RvT+JCgWm8IgReHmYUseViYMPaRQtIrGa8+41KOlPqQ=; b=o/ZlG39szjXsaNIWNd145huwNihoGpzKRdZ3Sj/8qmnpsFewAV7hpiRPqD0nphL0/p Rr8ITqVZuBTsRsdJAU9kw74CXJa+Mt4Qk/vVm8vxUkS3zfWn30RBC4KqaQ5NlZO0N+IQ G0aog2S63Lr5MrvdrwZObnfUU0r7LHb224odDoEpNSoxL0qaSEc82UvSd30fhY/RPfBb M602Ylb6maRbFDOKCsjBnvvqHed+yD7QVO5eyN6rS/4wgbtOTYG1+XTEHGTl+NNow9vx SDM2WtIEk1GKPJJzVRrVsunkH4pN5swUGS9IhgEUJxEPCoGfm6uIumeSGVJxCdDcI/Xv 98iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date; bh=RvT+JCgWm8IgReHmYUseViYMPaRQtIrGa8+41KOlPqQ=; b=U71LvFpZokdqYkhK6o9YfdFbIJynnhQYJcLWG7Mk33nswkgMhnK72DrQAYT+kxIhWw 4WBp1KcNTRLdO/g1hhn5kBv5Ds+8HFeZwOvfpjxyhp6md1YABLDtiEfZkhQUW0R0LDIy k/oNU9PUZYlyHm4uUxbTEL4+9X1RDurjadzG+POVsF26xU9xlzxrIquH5WktcT6nirlB nf9aoSG+i/iMuMUIxOHICQbRSFtxDaGrHV94pA1jDTUX4SF7Wyilq4HlfgJrqbXz4nAp b4BbyCxPfnEMDdqCMYPjwyIyCPmRfTwAVp3S45Xub2Xt5w0NDx/Sjc/PTWn2heh+qogc fKGQ== X-Gm-Message-State: ACrzQf1ZUn3qNHwcP2t2LWX64GaBpsmAs93HReN/3T3liAsvY5CFGrcy +h+EK6RCIQDF3F21jeSuHRwRnEiQPCGwUqZaB+4tzOfd X-Google-Smtp-Source: AMsMyM4GkW0RFmXoUanlhgrvCMeDmT1dIBtFY/KV73i+83HJc14AVxhrZq3ik4fTHm5auGbkBSXT0Y1OFJP8jKuAQoU= X-Received: by 2002:a17:906:fd85:b0:77b:b538:6472 with SMTP id xa5-20020a170906fd8500b0077bb5386472mr6786442ejb.48.1663421839969; Sat, 17 Sep 2022 06:37:19 -0700 (PDT) In-Reply-To: <83fsgq3517.fsf@gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:242870 Archived-At: --000000000000e211dc05e8df9339 Content-Type: text/plain; charset="UTF-8" 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 wrote: > > From: dalanicolai > > 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. > --000000000000e211dc05e8df9339 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Indeed, when invoking the command from the shell prom= pt using /dev/null as input
=C2=A0(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 Em= acs 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, withou= t 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 curren= tly). I am not sure, if this is a
case of a 'bad/wrongly desi= gned' pdftocio command (I would say that the command might
be well designed, but just it assumes that it is being used from the shel= l 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&g= t;
> Date: Fri, 16 Sep 2022 21:29:15 +0200
> Cc: 57854@d= ebbugs.gnu.org
>
> I don't understand the answer well (my knowledge about computers i= s 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 gi= ven as INFILE (after the `<`)
> But I am not giving any INFILE (which would make the command add the T= OC to the file given as
> argument),
> Instead I simply provide a single filepath as argument so that the com= mand simply prints the TOC.

I mentioned that aspect because it could be different between
invocation from shell prompt and from call-process.=C2=A0 I didn't exam= ine
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.
--000000000000e211dc05e8df9339--