GNU bug report logs - #45357
[PATCH] * lisp/man.el (Man-getpage-in-background): always use shell-file-name

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 45357 in the body.
You can then email your comments to 45357 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Nika Otiashvili <nikaoto <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] * lisp/man.el (Man-getpage-in-background): always use
 shell-file-name
Date: Mon, 21 Dec 2020 23:24:13 +0400

[Message part 1 (text/plain, inline)]

Hello,
First time sending a patch to bug-gnu-emacs, not sure if this is the
correct format.
Please indicate any errors I made in my formatting of the email or the
attached patch file.

Regards,
Nika Otiashvili

[0001-lisp-man.el-Man-getpage-in-background-always-use-she.patch (text/x-patch, attachment)]

Message #8 received at 45357 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Nika Otiashvili <nikaoto <at> gmail.com>
Cc: 45357 <at> debbugs.gnu.org
Subject: Re: bug#45357: [PATCH] * lisp/man.el (Man-getpage-in-background):
 always use shell-file-name
Date: Tue, 22 Dec 2020 17:14:23 +0200

> From: Nika Otiashvili <nikaoto <at> gmail.com>
> Date: Mon, 21 Dec 2020 23:24:13 +0400
> 
> First time sending a patch to bug-gnu-emacs, not sure if this is the
> correct format.
> Please indicate any errors I made in my formatting of the email or the
> attached patch file.

In terms of formatting the patch, I see no problems with your
submission.

My problem is more a conceptual one: it is not trivial to replace
/bin/sh with any other shell, because they work differently.  The
command in question builds a complex shell command to run, and it
isn't obvious that any user shell will be able to run it.

OTOH, every Posix system I know about does have /bin/sh, so I'm
curious what kind of system did you see where /bin/sh is absent.

And finally, I don't think I understand the issue with .bashrc etc.:
if you launch /bin/sh, it is not supposed to process these init files,
they are processed by bash, zsh, and other shells.

Could you please elaborate on the specific problems you had and tell
more about your system configuration where you bumped into these
problems?

Thanks.

Message #11 received at 45357 <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Nika Otiashvili <nikaoto <at> gmail.com>, 45357 <at> debbugs.gnu.org
Subject: Re: bug#45357: [PATCH] * lisp/man.el (Man-getpage-in-background):
 always use shell-file-name
Date: Tue, 22 Dec 2020 19:50:05 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

Hi,

> My problem is more a conceptual one: it is not trivial to replace
> /bin/sh with any other shell, because they work differently.  The
> command in question builds a complex shell command to run, and it
> isn't obvious that any user shell will be able to run it.

That's true. But we could require that shell-file-name points to a Posix
shell, if used in man.el.

Btw, if we were to change man.el, I'd rather propose to use
start-process-shell-command, instead of composing the command manually.

> Could you please elaborate on the specific problems you had and tell
> more about your system configuration where you bumped into these
> problems?

This question still stands, yes.

> Thanks.

Best regards, Michael.

Message #14 received at 45357 <at> debbugs.gnu.org (full text, mbox):

From: Nika Otiashvili <nikaoto <at> gmail.com>
To: eliz <at> gnu.org
Cc: michael.albinus <at> gmx.de, 45357 <at> debbugs.gnu.org
Subject: Re: bug#45357: [PATCH] * lisp/man.el (Man-getpage-in-background):
 always use shell-file-name
Date: Wed, 23 Dec 2020 04:55:41 +0400

Hello,

Thanks for looking at the patch, Eli.

Regarding the rc files, it seems there was an error on my part.
I have (setq shell-command-switch "-cl") in my .emacs. The "-l" flag
runs sh as a login shell, thus it loads my .profile. From there I source my
.bashrc. Since I have bashisms in my .bashrc, sh simply sees them
as syntax errors and exits. I should have inserted a check of $0 inside my
.profile to prevent this.

> OTOH, every Posix system I know about does have /bin/sh, so I'm
> curious what kind of system did you see where /bin/sh is absent.

Initially, I thought Windows users wouldn't have /bin/sh, but the cygwin
and windows-nt checks I removed accounted for that and used
shell-file-name instead of sh.

So, I've concluded that the first two reasons described in my patch
are irrelevant and the last one is indeed very weak. I believe my
patch would not benefit anyone and it only solves a specific problem I
had with my
configuration.

Regards,
Nika Otiashvili

On Tue, Dec 22, 2020 at 10:50 PM Michael Albinus <michael.albinus <at> gmx.de> wrote:
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> Hi,
>
> > My problem is more a conceptual one: it is not trivial to replace
> > /bin/sh with any other shell, because they work differently.  The
> > command in question builds a complex shell command to run, and it
> > isn't obvious that any user shell will be able to run it.
>
> That's true. But we could require that shell-file-name points to a Posix
> shell, if used in man.el.
>
> Btw, if we were to change man.el, I'd rather propose to use
> start-process-shell-command, instead of composing the command manually.
>
> > Could you please elaborate on the specific problems you had and tell
> > more about your system configuration where you bumped into these
> > problems?
>
> This question still stands, yes.
>
> > Thanks.
>
> Best regards, Michael.

Message #21 received at 45357-done <at> debbugs.gnu.org (full text, mbox):

From: Michael Albinus <michael.albinus <at> gmx.de>
To: Nika Otiashvili <nikaoto <at> gmail.com>
Cc: 45357-done <at> debbugs.gnu.org, eliz <at> gnu.org
Subject: Re: bug#45357: [PATCH] * lisp/man.el (Man-getpage-in-background):
 always use shell-file-name
Date: Wed, 23 Dec 2020 09:17:54 +0100

Nika Otiashvili <nikaoto <at> gmail.com> writes:

> Hello,

Hi,

> So, I've concluded that the first two reasons described in my patch
> are irrelevant and the last one is indeed very weak. I believe my
> patch would not benefit anyone and it only solves a specific problem I
> had with my
> configuration.

Closing the bug.

> Regards,
> Nika Otiashvili

Best regards, Michael.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.