Re: [Nmh-workers] More than one parameters in .mh_profile
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 case you could just set the environment variable LESS to f, right? Not quite. In fact I need -force only in show, to enforce silently displaying incompatibile charsets. Workaround is to make the shell script like vim-mail which is in fact call to vim -c :set ft=mail . Is it possible to do such thigs simpler? Right now ... no. To start, I have no idea how this interface should look like. Suggestions here are welcome; code is even more welcome :-) It does not seem too difficult to implement function which splits any string into separate pieces and prepend them to exec* parameters. But discussion shows that fundamental question is rather: should it be passed to the shell (and gives chance to use !$ or some such) or replace the shell job and interpret string inside the code? Finally, I think it is not worth to solve it now. max ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] More than one parameters in .mh_profile
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/listinfo/nmh-workers
Re: [Nmh-workers] More than one parameters in .mh_profile
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 fox, p...@foxharp.boston.ma.us (arlington, ma, where it's 69.1 degrees) ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] More than one parameters in .mh_profile
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. With nmh, it's going to be one or two per human action? Cheers, Ralph. ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] More than one parameters in .mh_profile
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 for it (I mean, really, what
are you trying to do there?) Also, I think I'm with others ... what
is the advantage to using the user's shell here? Like Jerrad Pierce
said, /bin/sh seems to be the LCD here.
(As an aside ... didn't know there was a shell called Zoidberg! Hah!)
Valdis Kletniecks says:
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
/bin/sh. (I used to do that myself, way back when csh had ! history and sh
didn't until it became bash).
Does anybody still do that?
Yeah, I still do that (and I guess I'm not the only one).
Paul Vixie says:
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.
Is it? I always thought SHELL was set by the shell itself. My SHELL
is /bin/tcsh, but I prefer to write in /bin/sh.
Lyndon Nerenberg says:
This conversation is cool. It reminds me of a phone call I had with
somebody in the pit at ATT tech support, arguing about why they could
never drop '^' as the pipeline separator in their SVR1 /bin/sh. The
lad was absolutely convinced '|' was an expression of the new heretics,
and would not stand past the next corporate quarter.
Man, I had to look that up ... SVR1 came out in 1983 :-) And I can
barely find any mention of ^ as the pipeline separator character.
Aleksander Matuszak says:
It does not seem too difficult to implement function which splits
any string into separate pieces and prepend them to exec*
parameters. But discussion shows that fundamental question is
rather: should it be passed to the shell (and gives chance to use
!$ or some such) or replace the shell job and interpret string inside
the code?
Well, the problem is that one of the examples you posted wouldn't work
with simple space splitting; we'd need to interpret quotes. Then we'd
need to specify how to escape quotes, then we'd want complete backslash
escape support it just gets awful quickly. If we can say, it's
run under /bin/sh -c then that lets people use the Bourne shell syntax
which is actually standardized.
Paul Fox says:
summary: i think passing any moreproc entry that contains whitespace
to /bin/sh -c '%s', and documenting it as such, would be fine.
processes aren't nearly as expensive as they used to be
I'll probably work on it in a few weeks ... I might just do the
space-splitting anyway since the code has mostly been written.
Ralph Corderoy says:
IOW, system(3).
Not exactly. In the case of moreproc it's actually a popen clone (m_popen).
In the case of Editor it's closer to system(), but some extra stuff happens
after the fork and before the exec(), so we can't just use system().
--Ken
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [Nmh-workers] UTF-8 message bodies
I've been thinking a bit of this and I can see (as a user not programmer) a couple of possibilities. It is possible to keep almost unchanged state with addition of one more clause to mhbuild like pair #off #on which marks the region where ^# is not interpreted as directive. Yeah, to me that's just simply making the problem only slightly better. Here's what I'm thinking: - As you have pointed out, it's kinda lame that nowadays we don't include MIME headers; sure, they're not required but it would be good to include them today anyway. - We already have a tool to generate the right headers: mhbuild. So why aren't we using it always? Well, some people do. My question to everyone who uses automimeproc: 1 is: are you doing this for character set issues, or do you really use mhbuild directives that much? Or a combination of both? - If we assume both of the above statements are true, then it seems logical that we should always be running mhbuild. But to me it seems dumb that # characters can't be in the beginning of a line, and having people have to know about #on/#off directives just seems like the wrong solution. So that's why I'm proposing that the automatic run of mhbuild doesn't process those directives at all. But if you run mime at a WhatNow? prompt then presumably you're smart enough to know you have to escape any leading # characters. --Ken ___ Nmh-workers mailing list Nmh-workers@nongnu.org https://lists.nongnu.org/mailman/listinfo/nmh-workers
