From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Raj Krishnan Newsgroups: gmane.emacs.bugs Subject: bug#48579: 28.0.50; Spawning an emacs process using call-process results in inconsistent behavior between GNU/Linux and macOS Date: Sat, 22 May 2021 17:05:58 +0530 Message-ID: References: <83a6onkq7s.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000003a5ea205c2e995e8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1903"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Alan Third , 48579@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat May 22 14:46:15 2021 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 1lkR1C-0000Hw-GM for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 May 2021 14:46:14 +0200 Original-Received: from localhost ([::1]:59824 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lkR1A-0007mC-I5 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 22 May 2021 08:46:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51044) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lkR11-0007la-5n for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 08:46:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:55180) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lkR10-0004GK-U6 for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 08:46:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lkR10-0007sp-SN for bug-gnu-emacs@gnu.org; Sat, 22 May 2021 08:46:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Raj Krishnan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 22 May 2021 12:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48579 X-GNU-PR-Package: emacs Original-Received: via spool by 48579-submit@debbugs.gnu.org id=B48579.162168754930270 (code B ref 48579); Sat, 22 May 2021 12:46:02 +0000 Original-Received: (at 48579) by debbugs.gnu.org; 22 May 2021 12:45:49 +0000 Original-Received: from localhost ([127.0.0.1]:38492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lkR0n-0007s4-1b for submit@debbugs.gnu.org; Sat, 22 May 2021 08:45:49 -0400 Original-Received: from mail-ot1-f54.google.com ([209.85.210.54]:39756) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lkPvU-0003z3-0k for 48579@debbugs.gnu.org; Sat, 22 May 2021 07:36:17 -0400 Original-Received: by mail-ot1-f54.google.com with SMTP id d25-20020a0568300459b02902f886f7dd43so20492901otc.6 for <48579@debbugs.gnu.org>; Sat, 22 May 2021 04:36:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=XUp5JJbTtrpsKUGmmazIPeagf2M8wKfh9aWoWiIuroo=; b=YzOePNt3JDdKl76gso+0KPeUK+0X8QyXPJWqqPxhpvui9LoeEyZeXJXzRZL5VX9f12 W3o9/guNRBAyr4UHs6F0yzHsEkPdEds1MfQ2xSejR/49vogiY9AzKWydfZ7FtVheoinQ 0IB63nyUa2AXHzXKHJxCzBHirM/XXv1OgbAsuOp+nxFQF/YXNIppQ/jGGykGeiJsMhA/ BL+UtitGoQ1hzlaGvGuzGIgk0cXdGt1G2VZxUng7HE6ItK2pGfDZXTM14hxh/05AYnqV H3ix9nl8bZy4L4UZGlC0AlNicQLLSSy+krQ+tgDTgk3cVx1VGUkRBn2f/yRgMicsfD9m tLcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=XUp5JJbTtrpsKUGmmazIPeagf2M8wKfh9aWoWiIuroo=; b=a3133koSp209Agfwwmj5XkHcAmyYgWi8cgCcj7q+RdX6dKOOd/+4tSh/7qmvCiJ9nU 0sv91REh0uS1K+3fhpjG/ejIdO8K8t/JKC/t9UgFU7eMLSaF2N6Jmdmb2PGNKH95XS2R PSAQLvPvJ6oXvHkF1C4GgEBXueCYn53/+qBcwlDezQJkzu3Emiq6P2BrlpkOTmJBBKYo QdWudgGh2D3ZTvt9uXH25ofU/mYYUvig/uef9tmahXBJd0iFPILaJ30XCUvp6rlnTL2X 7K2+WbQ+lJ0Lx2W2IUK++AENvNIglo51THbvugOLsRqp0rOLKXE5/KoRjfmtrQNd9K87 /Aaw== X-Gm-Message-State: AOAM532n5cHW2azDYOyXkEJonmAC5Q82PO0N4XOjPZpwYAVdPembu5uM +DQPuBESFAPkdNRGl9o2XpbH7wuv/YOVxjP+7j9uEeK+59Y= X-Google-Smtp-Source: ABdhPJxJSQ3WZsZp3e2cqJB+AdfbRCxwL2NugcroGRcP+B8WaFLEECWtrcejVcB0pd7NeSiUYP6jMXm68boG1AYmtyo= X-Received: by 2002:a05:6830:1155:: with SMTP id x21mr11600888otq.303.1621683370351; Sat, 22 May 2021 04:36:10 -0700 (PDT) In-Reply-To: <83a6onkq7s.fsf@gnu.org> X-Mailman-Approved-At: Sat, 22 May 2021 08:45:45 -0400 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:207043 Archived-At: --0000000000003a5ea205c2e995e8 Content-Type: text/plain; charset="UTF-8" Thanks Alan, Eli! Adam's comment seems to be the root cause of this. One extra dot on your point Eli: this happens in case we run the command in a regular buffer as well, not just in the scratch buffer. Explicitly specifying the directory we expect to be in seems cleaner, and we shall pass along a chdir flag to call-process, in order to switch directories. On Sat, May 22, 2021, 4:09 PM Eli Zaretskii wrote: > > Date: Sat, 22 May 2021 11:26:16 +0100 > > From: Alan Third > > Cc: 48579@debbugs.gnu.org > > > > > 5. Behavior on GNU/Linux: The directory matches the value shown in (2) > > > Behavior on macOS: The default directory has changed to the user's > > > home directory > > > > > > The behavior was spotted when we noticed inconsistent behavior in > > > [[https://github.com/minad/affe][affe.el]], which was subsequently > > > reproduced using =emacs -Q= > > > > The NS port checks if it's connected to a TTY when it starts, and if > > not assumes it's being run from finder and so sets the starting > > directory to something useful ($HOME), instead of / or whatever it > > defaults to. > > I think any Lisp program that assumes something about the directory of > the *scratch* buffer based on where Emacs was invoked is buggy. E.g., > on MS-Windows one can specify a starting directory for Emacs via the > properties of the Emacs desktop icon, and Lisp programs have no way of > knowing where that is. > > Lisp programs that want rely on the value of the default directory > should explicitly call 'cd' to change to that directory (passing it > via command-line arguments if necessary, as it probably is in the case > in point). > > Bottom line: I don't see any Emacs bug here. > --0000000000003a5ea205c2e995e8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks Alan, Eli!


Adam's comment seems to be the root cause o= f this.

One extra do= t on your point Eli: this happens in case we run the
command in a regular buffer as well, not just in the scratch buffer.
=

Explicitly specifying the dir= ectory we expect to be in seems cleaner,
and we shal= l pass along a chdir flag to call-process, in order
= to switch directories.

On Sat, May 22, = 2021, 4:09 PM Eli Zaretskii <eliz@gnu.or= g> wrote:
> Date: Sat, 22= May 2021 11:26:16 +0100
> From: Alan Third <alan@idiocy.org>
> Cc: 48579@debbugs.gnu.org
>
> > 5. Behavior on GNU/Linux: The directory matches the value shown i= n (2)
> >=C2=A0 =C2=A0 Behavior on macOS: The default directory has changed= to the user's
> >=C2=A0 =C2=A0 home directory
> >
> > The behavior was spotted when we noticed inconsistent behavior in=
> > [[https://github.com/minad/affe]= [affe.el]], which was subsequently
> > reproduced using =3Demacs -Q=3D
>
> The NS port checks if it's connected to a TTY when it starts, and = if
> not assumes it's being run from finder and so sets the starting > directory to something useful ($HOME), instead of / or whatever it
> defaults to.

I think any Lisp program that assumes something about the directory of
the *scratch* buffer based on where Emacs was invoked is buggy.=C2=A0 E.g.,=
on MS-Windows one can specify a starting directory for Emacs via the
properties of the Emacs desktop icon, and Lisp programs have no way of
knowing where that is.

Lisp programs that want rely on the value of the default directory
should explicitly call 'cd' to change to that directory (passing it=
via command-line arguments if necessary, as it probably is in the case
in point).

Bottom line: I don't see any Emacs bug here.
--0000000000003a5ea205c2e995e8--