[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Nmh-workers] [Patch] Relative MH variable lossage

From: Richard M Kreuter
Subject: Re: [Nmh-workers] [Patch] Relative MH variable lossage
Date: Wed, 20 Jan 2016 07:22:13 -0500

Lyndon Nerenberg writes:
> > It seems that using a non-absolute MH variable doesn't work when an MH
> > program chdir's and exec's a child that needs to read the
> > profile. (Example below involving show and mhshow.)
> My first impression is that everything should assume 'defpath'; it
> shouldn't be necessary to export MH explicitly like that.  This will
> take some digging through the code to verify, though ...

Correct: it looks like MH programs do use defpath, but when $MH is
non-absolute, context_read resolves $MH against the program's current
working directory at the time of context_read. So if one program chdir's
and then exec's another, the the two programs will resolve $MH to
different pathnames. (The example in my previous message evinces this
with show and mhshow.)

As for my patch, the idea is that assuming that context_read's defpath
resolution is idempotent, exporting the result as MH will cause
successor programs set their defpath values to same pathname as the
first program that resolves $MH, even across chdir'ing. But is there
some other way that MH programs are meant to communicate defpath to each

Thank you,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]