To answer a bunch of emails on this topic:
Ralph Corderoy says:
>No `#'? How about just always send to the user's shell from the
>password entry with a -c, as distinct from /bin/sh.
I guess I wasn't thinking of #, but if perl doesn't check for it it makes
me think it's not really useful to check
Hi Paul,
> i think passing any moreproc entry that contains whitespace to
> "/bin/sh -c '%s'", and documenting it as such, would be fine.
IOW, system(3).
> processes aren't nearly as expensive as they used to be.
I think Perl goes to lengths to avoid it because you may be doing a lot
of them.
david wrote:
> Paul wrote:
>
> > p.s. incidentally, mh-profile.5 mentions $SHELL only in the context
> > of bbl, which no longer exists.
>
> Already fixed, prior to the 1.5 branch.
oops. i was looking at the .5 file, not the .man, and it was out of date.
paul
=-
paul
Paul wrote:
> p.s. incidentally, mh-profile.5 mentions $SHELL only in the context
> of bbl, which no longer exists.
Already fixed, prior to the 1.5 branch.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/list
valdis.kletni...@vt.edu wrote:
>
> > No `#'? How about just always send to the user's shell from the
> > password entry with a -c, as distinct from /bin/sh.
>
> The problem is that some people (at least in the Elder TImes) would have
> their login shell set to /bin/csh but they'd want thei
Ken Hornstein writes:
> >I need moreproc to be "less -force" but show (nmh-1.3) refuses
> >this.
>
> Yeah, I guess what happens there is mhl (or whatever) is trying to
> exec("less -force"). Which as you've noted doesn't work.
>
> Other people have complained about this as well. But in this ca
On 2012-05-29, at 7:19 PM, Paul Vixie wrote:
> for that we have getenv('SHELL'), which is far more closely related to
> the user's preferred command language than either their login shell or
> the posix standard are going to be.
This conversation is cool. It reminds me of a phone call I had wit
On 2012-05-29 10:36 PM, Tethys wrote:
> valdis.kletni...@vt.edu writes:
>
>>> No `#'? How about just always send to the user's shell from the
>>> password entry with a -c, as distinct from /bin/sh.
>> The problem is that some people (at least in the Elder TImes) would have
>> their login shell set
On 2012-05-29 2:46 PM, Kevin Cosgrove wrote:
> On 29 May 2012 at 8:00, valdis.kletni...@vt.edu wrote:
>
>> ...
>>
>> Does anybody still do that?
> Why yes, my login shell is /bin/tcsh and I program in sh, bash, perl.
me too, give or take a conditional "exec tcsh" in my .cshrc file.
_
>In which case, couldn't they just do "sh -c whatever" as the thing that
>would get passed to their login shell (i.e., csh)? It's a bit clumsy,
>but it should work for the few people that are in that situation.
Why do you want to use the user shell exactly?
Yes, the user might be more familiar wit
valdis.kletni...@vt.edu writes:
>> No `#'? How about just always send to the user's shell from the
>> password entry with a -c, as distinct from /bin/sh.
>
>The problem is that some people (at least in the Elder TImes) would have
>their login shell set to /bin/csh but they'd want their scripty t
Hi Valdis,
> > No `#'? How about just always send to the user's shell from the
> > password entry with a -c, as distinct from /bin/sh.
>
> The problem is that some people (at least in the Elder TImes) would
> have their login shell set to /bin/csh but they'd want their scripty
> things done in /
On 29 May 2012 at 8:00, valdis.kletni...@vt.edu wrote:
> On Tue, 29 May 2012 10:01:22 +0100, Ralph Corderoy said:
>
> > No `#'? How about just always send to the user's shell from the
> > password entry with a -c, as distinct from /bin/sh.
>
> The problem is that some people (at least in the E
On Tue, 29 May 2012 10:01:22 +0100, Ralph Corderoy said:
> No `#'? How about just always send to the user's shell from the
> password entry with a -c, as distinct from /bin/sh.
The problem is that some people (at least in the Elder TImes) would have
their login shell set to /bin/csh but they'd w
Hi Ken,
> for (s = cmd; *s; s++) {
> if (*s != ' ' && !isALPHA(*s) &&
> strchr("$&*(){}[]'\";\\|?<>~`\n",*s)) {
>
> Seems like that's a pretty good list; if we see one of those
> characters, it gets sent to /bin/sh -c. Otherwise we split and do it
> ourselves.
No `#'? H
>>Sure, it COULD do that. Sounds like you're volunteering to write
>>the code; great! :-)
>I hack perl, not C. I did quickly grep the perl code base for it though,
>but being on a tablet at the moment could not dive too deeply.
>nmh is non-GNU, but perl is dual-licensed under the Artistic License.
>Sure, it COULD do that. Sounds like you're volunteering to write
>the code; great! :-)
I hack perl, not C. I did quickly grep the perl code base for it though,
but being on a tablet at the moment could not dive too deeply.
nmh is non-GNU, but perl is dual-licensed under the Artistic License.
>kn
>Could nmh not do with such parameters what perl does for
>system()/exec(), auto-splitting the string? In the off
>chance that someone's installed binaries in a path with
>a space they can escape the space, same as they would in
>a shell...
Sure, it COULD do that. Sounds like you're volunteering
Could nmh not do with such parameters what perl does for
system()/exec(), auto-splitting the string? In the off
chance that someone's installed binaries in a path with
a space they can escape the space, same as they would in
a shell...
___
Nmh-workers ma
>I need moreproc to be "less -force" but show (nmh-1.3) refuses
>this.
Yeah, I guess what happens there is mhl (or whatever) is trying to
exec("less -force"). Which as you've noted doesn't work.
Other people have complained about this as well. But in this case you
could just set the environment
In the .mh_profile some entries specifies programs like:
Editor: vim-mail
moreproc: less
postproc: /usr/lib/mh/post
Some of those programs require options or parameters but
apparently this is not accepted.
I need moreproc to be "less -force" but show (nmh-1.3) refuses
this.
Workaround is to ma
21 matches
Mail list logo
