>>That really seems like overkill. Also, none of those scripts are
>>regularly tested, or even supported. I would much rather see those
>>copied into /usr/local/share/nmh/contrib, with a post install note
>>pointing out that directory.
>
>They might not be tested nmh-workers, but I expect we are al
>> Possibly more of an issue is the contributions following out of
>> sync with updates. Perhaps a note should be included with each pointing
>> to any official project page/other source for the latest and greatest?
>
>If it's hosted somewhere, I don't see a need to redistribute it.
Path of least r
Jerrad wrote:
> Possibly more of an issue is the contributions following out of
> sync with updates. Perhaps a note should be included with each pointing
> to any official project page/other source for the latest and greatest?
If it's hosted somewhere, I don't see a need to redistribute
it. The
>That really seems like overkill. Also, none of those scripts are
>regularly tested, or even supported. I would much rather see those
>copied into /usr/local/share/nmh/contrib, with a post install note
>pointing out that directory.
They might not be tested nmh-workers, but I expect we are all eati
>
>On Apr 16, 2014, at 4:29 AM, Mikhail wrote:
>
>> I really like all three contrib scripts and plan to add separate port
>> option for each one, which will install needed dependencies. Like
>> p5-MIME tools, par, w3m for replyfilter (which is absolute requirement
>> for me, as I'm non-english use
>That really seems like overkill. Also, none of those scripts are
>regularly tested, or even supported. I would much rather see those
>copied into /usr/local/share/nmh/contrib, with a post install note
>pointing out that directory.
BTW, those scripts are already installed by Automake, although t
On Apr 16, 2014, at 4:29 AM, Mikhail wrote:
> I really like all three contrib scripts and plan to add separate port
> option for each one, which will install needed dependencies. Like
> p5-MIME tools, par, w3m for replyfilter (which is absolute requirement
> for me, as I'm non-english user).
Th
>I really like all three contrib scripts and plan to add separate port
>option for each one, which will install needed dependencies. Like
>p5-MIME tools, par, w3m for replyfilter (which is absolute requirement
>for me, as I'm non-english user).
As long as there's not a requirement for those things
>
>On Apr 15, 2014, at 9:59 AM, Mikhail wrote:
>
>> If script authors do not object, I'd like to propose a patch, which
>> replaces direct paths with indirect '/usr/bin/env' call. It will make
>> code a little bit more portable between the systems.
>
>Yes please. And while you're in there, it woul
>I will note these scripts are in contrib, and at least one of the
>perl ones (replyfilter) is designed to be copied into your own directory
>and modified.
Fair enough. I'll keep it as local patch for FreeBSD port.
Just always try to give back even a small changes to upstream.
___
On Apr 15, 2014, at 9:59 AM, Mikhail wrote:
> If script authors do not object, I'd like to propose a patch, which
> replaces direct paths with indirect '/usr/bin/env' call. It will make
> code a little bit more portable between the systems.
Yes please. And while you're in there, it would be ni
ken wrote:
> part text/plain 631
> >i've just pushed a runtime check to docs/contrib/ml to make it work
> >correctly on most shells, with slightly reduced functionality on
> >strict-posix /bin/sh variants. (namely, the absence of the "read -n
> >N" feature.) i'm leaving
>i've just pushed a runtime check to docs/contrib/ml to make it work
>correctly on most shells, with slightly reduced functionality on
>strict-posix /bin/sh variants. (namely, the absence of the "read -n
>N" feature.) i'm leaving the #! line as /bin/bash, since that's how i
>wrote and tested.
FY
ken wrote:
> part text/plain 603
> >FWIW, use of "env" in this way is a bit of a religious issue; some people
> >think it's good and others say differently.
>
> Sigh. I lack the energy to make a decision regarding this issue; if someone
> wants to make a change and com
>FWIW, use of "env" in this way is a bit of a religious issue; some people
>think it's good and others say differently.
Sigh. I lack the energy to make a decision regarding this issue; if someone
wants to make a change and commit it (and thus take responsibility for it)
please feel free.
I will
Hi Ken,
> I have mixed feelings about this; I think /bin/bash is wrong, but I
> thought that /bin/sh should actually work everywhere.
If it's a bash script, as opposed to a dash, sh, or zsh one, then it
should specify bash. And if bash is somewhere other than /bin then the
user probably has the
Jerrad Pierce writes:
> P.S. Although env is noted as a portability measure for scripts,
> it's worth noting that it is reliant upon a properly configured PATH.
FWIW, use of "env" in this way is a bit of a religious issue; some people
think it's good and others say differently. My former employe
earl wrote:
> part text/plain 896
> On Tue, Apr 15, 2014 at 3:00 PM, Ken Hornstein wrote:
>
> > I have mixed feelings about this; I think /bin/bash is wrong, but I thought
> > that /bin/sh should actually work everywhere. I know perl is all over
> > the place, but I th
>I have mixed feelings about this; I think /bin/bash is wrong, but I thought
>that /bin/sh should actually work everywhere.
It depends on the script. If it needs bash, then it should be specified as
bash since bash will operate with a simpler feature set if invoked as sh.
>I know perl is all over
On Tue, Apr 15, 2014 at 3:00 PM, Ken Hornstein wrote:
> I have mixed feelings about this; I think /bin/bash is wrong, but I thought
> that /bin/sh should actually work everywhere. I know perl is all over
> the place, but I thought /usr/bin/perl was pretty standard. What do
> others think?
/bin/
>I started to prepare patch for FreeBSD port and during preparation
>I noted that contrib scripts use direct paths, like /bin/bash or
>/usr/bin/perl. Last one can be handled by FreeBSD, but first one will be
>broken.
I have mixed feelings about this; I think /bin/bash is wrong, but I thought
that
>Greetings all,
>
>I am pleased to announce that after close to two years, we are finally
>starting the release cycle for nmh 1.6 and the first release candidate is
>now available! You can download it here:
>
> http://download.savannah.gnu.org/releases/nmh/nmh-1.6-RC1.tar.gz
I started to prepar
On behalf on nmh users, everywhere, thank you so very much.
Norman Shapiro
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Greetings all,
I am pleased to announce that after close to two years, we are finally
starting the release cycle for nmh 1.6 and the first release candidate is
now available! You can download it here:
http://download.savannah.gnu.org/releases/nmh/nmh-1.6-RC1.tar.gz
(I've also included a MIME
Greetings all,
I am pleased to announce that after close to two years, we are finally
starting the release cycle for nmh 1.6 and the first release candidate is
now available! You can download it here:
http://download.savannah.gnu.org/releases/nmh/nmh-1.6-RC1.tar.gz
(I've also included a MIME
25 matches
Mail list logo
