Hi Valdis,
> > ISTM it's also a bug to ignore problems opening a file that exists,
> > and to ignore a file given in an environment variable not existing.
>
> I agree on the first. The second probably need to be more nuanced,
> and "a *specific* file given in the environment". Consider how *PATH
Hi Stewart,
> I used dnf to install nmh-1.7.1-2.fc28.x86_64 from a repository.
> So I guess the bug was in there too.
From
https://fedora.pkgs.org/28/fedora-x86_64/nmh-1.7.1-2.fc28.x86_64.rpm.html
I got
http://download-ib01.fedoraproject.org/pub/fedora/linux/releases/28/Everything/x86_64/os/Pac
I've been having a problem when occasionally at a What now? prompt when
I use the "send" command the process will get killed with a -9 out of
nowhere (this is on MacOS X High Sierra). I finally realized that the
same problem is causing the test suite to fail for the dist test, so I
decided to trac
Hi Ken,
> Can anyone think of a reason that for this specific case closefds()
> should NOT be moved from whatnowbr.c (and send.c) into sendsbr.c, and
> just in the child process?
IT does seem odd to have it in the parent rather than just the child.
The only thing I can think of is if it's cleanin
Ken wrote:
> Can anyone think of a reason that for this specific
> case closefds() should NOT be moved from whatnowbr.c (and send.c) into
> sendsbr.c, and just in the child process?
That looks like a good change. The callers of sendsbr() shouldn't be
concerned with its fork/exec.
Those two clos
Ralph wrote:
> Hi Stewart,
>
> > send: -port 2525 -alias /home/wilson/.mh_aliases -server mail.eskimo.com
>
> Yes, that would work, though only for you and not any other users.
The port can't be set in mts.conf, so it wouldn't be straightforward
to support that for all users. Though it sounds li
>I understand why functions like closefds() are used right before exec(),
>but in this case a fair amonut of stuff happens before exec is called,
>and it's way before fork() is eventually called as well. The other uses
>of closefds() are after a fork() occurs, or right before exec() happens
>(see
>> Looks like a bug in nmh's Makefile; it produces mts.conf by
>> re-directing the output of sed, but a umask of 077 would leave the
>> file as 600.
>
>ISTM it's also a bug to ignore problems opening a file that exists, and
>to ignore a file given in an environment variable not existing.
I discove
Ken wrote:
> I suggest we simply remove closefds() completely.
Great idea!
Ralph's suggestion of looking for only open fds addresses the
suboptimality of closefds(), though only for systems that use /proc.
I'd prefer to see the application take better care of its resources,
but that's much easie
David Levine writes:
> Ken wrote:
>> I suggest we simply remove closefds() completely.
> Great idea!
Makes sense from here. You could back-fill use of CLOEXEC anywhere
it seemed important.
regards, tom lane
--
nmh-workers
https://lists.nongnu.org/mailman/listinfo/nmh-
>David Levine writes:
>> Ken wrote:
>>> I suggest we simply remove closefds() completely.
>
>> Great idea!
>
>Makes sense from here. You could back-fill use of CLOEXEC anywhere
>it seemed important.
Alright, done.
In the "weird things I discovered while doing this" ... I saw in slocal
that when
11 matches
Mail list logo
