Mikhail wrote:
Simple way to reproduce the warning (just need to fix Attach: header
to proper path):
edge:~ cat live.letter EOF
From: Mikhail
Jerrad wrote:
It recreates text/plain alternative parts for me, and sometimes
creates new ones, but it fails to create them for HTML parts
with long lines, as Ken recapped above.
It turns out that the failure was not due to long lines, but to
non-ASCII characters in what was supposed to be an
I wrote:
It turns out that the failure was not due to long lines, but to
non-ASCII characters in what was supposed to be an ASCII html page.
Removing the -textcharset switch will allow the text/plain
part insertion to succeed.
David
___
Nmh-workers
Okay, so I looked at this. It looks like the simplest thing to do
is make init_decoded_content() set a default CTE (probably 7bit is
appropriate).
But 8bit would be safe more often. Is there any harm nowadays
in saying that a 7bit message is 8bit?
But as always ... there's a wrinkle. It
Anything else before we branch 1.6?
Nope, go for it.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Paul F. wrote:
david wrote:
Same for me. Your profile entry, Paul, looks like it works
properly for me. I even inserted tr '[a-z]' '[A-Z]' in the
tr 'a-z' 'A-Z'
do you have -concat set? the breakage is happening for me in
show_text, where buffer is set to either a display
Paul F. wrote:
the %s isn't getting dropped -- it's getting expanded to an empty
string. i.e., at this point, at the end of parse_display_string():
snprintf (buffer, buflen, ct-c_termproc, term);
the value of term is an empty string, and the value of ct-c_termproc
is this:
Jerrad wrote:
Trying to use mhfixmsg -reformat on some non-multipart text/html
messages sent as quoted-printable, I get the following when run with
-verbose:
mhfixmsg: 120 part 1, insert text/plain part
mhfixmsg: 120 part 1.1, will not decode because it is binary (line length
998)
Paul rote:
i currently have this in my mh_profile:
mhshow-charset-iso-8859-1: %s | /usr/bin/iconv -f ISO-8859-1 -t UTF-8 | less
whether i need it currently or not (do i? has the iconv conversion
been internalized?)
You shouldn't need that any more, depending on your locale:
- If nmh
Mikhail wrote:
- when I was attaching letters to my original message I got following
warning (?):
mhbuild: message/rfc822 type in message (null) should be encoded in 7bit
or 8bit, continuing...
I attached the message through whatnow prompt with 'attach ~/19'
command.
Was ~/19
Instead, what if I want to view text/html with a web browser?
-noconcat lets me. But without a pause after displaying the
headers, I don't see them until after I finish viewing the
message body.
Hm. What SHOULD happen is that the message headers should be displayed
with mhl (whihc uses
Hm. I also just tested it again with a barebones mh_profile, and it worked
for me. What happens if you unsetenv LESS? Just trying to figure it
out; I'm assumung that your mhl is invoking less, right?
Yes, and unsetting LESS got to the fix. I had -F in my LESS
and that was causing the
Ken wrote:
That's pretty much the last item on my to-do list for 1.6. The only
outstanding item (aside from some test suite fixups that the buildbot
has exposed) is David's locking fixes (which looked fine to me).
Test suite fixed, fix-locking branch merged to master.
Is there a way to get
When I get a calendar request, I want to first show it. Okay, that's
easy to understand. I could write something to take a text/calendar
object and convert it to something more easily readable.
docs/README-iCalendar has a very crude setup using calcurse
to show what's in a calendar request.
I noticed that locking of the sequences file was broken: the
program would proceed anyway after failing to acquire the lock.
I have fixed that on the fix-locking branch; reviews would be
appreciated.
Ken observed that this might be the cause of the sequence file
clearing that you experienced
Ralph wrote:
I'd expect nmh users to be Unix users familiar with cat(1). I'd expect
it to make sense to them for that alone?
On the question of whether the option should be named so the default is
the -no-less version, I don't think that matters. More important is a
negative term isn't
Also ... I don't think I've ever heard the word catenate
used in English. If you had asked me, I would have said
that I didn't even think that WAS a word.
It's in dictionaries. Maybe not commonly used, esp. on our
side of the pond.
It's just ... when I see -cat, I'd think that means run
Ken, should we move the mhparam details to mhparam(1) and then
add pointers to the three man pages that refer to iconv(3)?
I am thinking ... yes.
:-)
I updated the relevant man pages. I'm not feeling particularly
literary right now, so commits/comments welcome.
A few minor questions:
I wrote:
And, should program names be bold or italic in man pages?
Bold, according to README.manpages.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
Lyndon wrote:
On Mar 16, 2014, at 8:20 AM, David Levine levin...@acm.org wrote:
And, should program names be bold or italic in man pages?
We're inconsistent.
Actually I'm about to embark on another round of manpage cleanup, so
I will track these down and fix them.
Maybe there aren't
Paul F. wrote:
i've volunteered to set up an ARM box for the buildbot cluster.
Cool/thanks!
it's running fedora (F18 -- can't be upgraded easily). before i try
and chase the dependencies piecemeal, does anyone (david?) have a
list of what's needed?
Run-time package requirements:
Jerrad wrote:
mhn.defaults.sh checks for the presence of lynx before elinks.
It seems as though it should check for the availability of
more modern tools before falling back to old standbys, and that
they ought to be reversed.
mhn.defaults.sh looks for w3m, not elinks, for
Ken wrote:
[Jerrad:]
Not from the command line. It uses LANG/LC_CTYPE/LC_ALL,
and this can be overridden from the SetupCharacter set menu;
which could probably set in a dummy config pointed to be -config
if one were very keen to do so, though nmh understandly is not.
The way I read the
Norm wrote:
David Levine levin...@acm.org writes:
Is clobbering the only [mstore] security concern with -auto?
Wouldn't the '|' feature, combined with an mhstore-store-type in
.mh_profile, alllow the execution of arbitrary code?
If arbitrary means what the user put into their profile,
yes
Ralph wrote:
I'd say it's more a flawed design decision than a bug and should be
described as the behaviour of -list in DESCRIPTION so every user is
aware of it without having to read BUGS.
Done.
David
___
Nmh-workers mailing list
Ken wrote:
If arbitrary means what the user put into their profile,
yes, but we can't prevent that. Is there a way to get
mhstore to execute arbitrary code provided by the message?
It does occur to me that there might be security concerns with using
%a with '|', depending on shell
Paul F. wrote:
ken wrote:
That seems pretty straightforward to implement (just don't call rename()
and the hook at the appropriate place). I can work on that in a little
while. Although I'm not sure I'm in love with the switch name; anyone
else have a suggestion?
it's short for
Again, that's an issue with '|'
That reminds me, I removed this from mhn.defaults recently:
mhshow-show-application/PostScript: %plpr -Pps
(or lp -dps if lpr wasn't found). While PostScript attachments
are probably close to extinct, I didn't see a need for any
potential security
Ralph wrote:
The `storing message 42 to stdout' on stderr is annoying but I've
never looked into if it can easily be shut-up.
I just committed a fix for mhstore to obey -noverbose.
It clearly should be off by default unless running on VMS.
To not break anything that depends on it, I left
Ralph wrote:
sort(1) has this functionality. It's -c for check. -check? Don't see
why we should deviate.
sortm already has a -check, for a slightly different purpose.
It was recently added, though, so maybe its meaning could be
changed?
David
The man page for mhstore recommends that, for the sake of security,
I not put the -auto switch in .mh_profile. Whatever the security
risk is, would it not also be present if I invoke mhstore with that
switch? But the man page does not seem to recommend against that.
Yes, they're equivalent.
Jerrad wrote:
Try feeding mhstore from a file instead of a message, something like:
Alas, mhstore -file did not solve the problem;
Though it looks like mhstore causes the problem? I don't
understand why -file wouldn't solve it.
I seem to have found a workaround that works, even with the
Norm wrote:
So I wonder if I could prevail upon somebody to create and release an
nmh-1.6-RC1. I can't -- way about my pay grade.
Instead of that, how about trying the sequence of commands below?
You probably have some of the packages already installed, such as
openssl and readline. Just
Jerrad wrote:
In trying patch the last few nits in MIME-hooks, I seem to uncovered an
odd issue with mark. Despite the default behavior being to not zero a
sequence on -add, mark is clearing the sequence, even when -nozero is
explicitly given.
However I only see this behavior from mark
The only difference is ctxpath, which is to be expected since
MHCONTEXT is set in one instance. I've also unsuccessfully tried a
workaround of copying the sequence to another, then using mark -seq
unseen tmpseq $MSGNUM
Ken's theory seems most likely. Can you step through in a debugger
after
Ralph wrote:
My quick skim of
http://git.savannah.gnu.org/cgit/nmh.git/commit/?id=a0514c9a6f41ea1b0d60553ca
578312a9f3bd9abcontext=12
with the whole source at
http://git.savannah.gnu.org/cgit/nmh.git/tree/sbr/m_getfld.c?id=a0514c9a6f41e
a1b0d60553ca578312a9f3bd9ab#n620
suggests that buf
Jerrad wrote:
Hmm, on a hunch I just discovered that somehow the call to mhstore
in mime-add-hook's for loop is the trigger... of course that's the
raison d'etre of the script :-/
Try feeding mhstore from a file instead of a message, something like:
FILE=`mhpath $MSG`
for PART in
When you say the file was not new-line terminated, which file? If
it was your .mh_profile ... I guess that's the fault of m_getfld().
Good catch. Fixed.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
Lyndon wrote:
There is nothing that says we cannot undo transport encodings for
text/* parts when we write store a message into a folder.
mhfixmsg -decodetext 8bit
And despite the prevalence of QP and base64, I still find grep works
quite well for me.
Agreed.
If we undid the transport
Robert wrote:
| If the link named by the new argument exists, it shall be removed
| and old renamed to new. In this case, a link named new shall
| remain visible to other processes throughout the renaming
| operation and refer either to the file referred to by
Hi,
There are a few setuid/setgid calls remaining in nmh. They're
of three types. Using setuid as an example and not showing the
setgid analogues:
1) setuid(getuid());
This drops privileges before an exec and is normally a good
thing. Except here, the return value isn't checked. And, we
Lyndon wrote:
I would prefer to leave that bit of code in place. Presumably we
can still build and run on older systems that still need this. It's
a simple little snippet of code that's harmless even if left in
unconditionally.
OK.
David
___
Lyndon wrote:
On Feb 2, 2014, at 6:02, David Levine levin...@acm.org wrote:
Well, that's the way it's documented. This is when an existing
file is in the way of the new name.
Documented where? SUSv3 calls out the behaviour explicitly, as
inherited from the ISO C spec.
Well
Robert wrote:
And it is impossible for slocal to ever be used as the mail delivery
agent (the way procmail can be, or example) - so it gets run as root, but
told which user it is to deliver the mail for ?
Good point: I restored the setuid/setgid to slocal and added
checks of the return
Earl wrote:
On Sun, Feb 2, 2014 at 4:43 PM, David Levine wrote:
Documented where? SUSv3 calls out the behaviour explicitly, as
inherited from the ISO C spec.
Well, the SUSv2 spec says:
If the link named by the new argument exists, it shall be removed
and old renamed
While cleaning up the tmp files, I noticed a potential security
issue. mhshow, mhn, etc., used to create temporary files using
mkstemp(3) and then rename(3) them in order to add a filename
extension that reflects the content type. E.g.,
/tmp/mhshowXYZ123.html. rename allows the new filename to
Oliver wrote:
You could use mkstemps to create the temporary file directly with a
suffix. The only problem is that it'd need a configure test for
mkstemps because at least Solaris 10 (but not 11) lacks it. Where
mkstemps is lacking, I'd just do the rename.
Perfect! It even works on FAT
Ralph wrote:
heirloom-mailx's mail(1) has
maximum-unencoded-line-length
Messages that contain lines longer than the value of this
variable are encoded in quoted-printable even if they contain
only ASCII characters. The maximum effective value is 950. If
Ralph wrote:
Does the 76 historically come from 78 - strlen( ) to allow for a
simple single-level of quoting?
It's the encoded length, though of course would encode
without change. This is all I could find in a quick grep of the
RFCs, in Appendix B of RFC 1521:
The following guidelines
I concur, although I'm not sure what the option should be called,
because that thing is kinda long. Maybe -maxunencoded?
That's fine. Or maybe -maxlinelength or -maxlinelen, on the
theory that the user shouldn't care how long the encoded
line is.
Or -maxtextlinelen, more descriptive but
I wrote:
Here's what I'd like to change that to:
* The nmh-storage profile component, if set, will only be used by
mhstore(1) for its outputs, as currently documented in its man page.
* All nmh programs will put tmp files in the first non-null location
of {MHTMPDIR, TMPDIR, TMP, MH
Here's what we have now for placement of MH/nmh tmp files:
* The nmh-storage profile component, if set, tells mhstore(1) where to
put its output. If not set, mhstore uses the current directory.
This is documented in its man page.
* Most of the programs named mh*, which use the MIME parser,
Lyndon wrote:
I guess $TMP is a Windows thing? It shouldn't be used on UNIX systems.
It looks like this might have been added just 4 years ago.
Otherwise, I'd be reluctant to remove it. Earl?
* If MHTMPDIR is not an absolute path, interpret it as relative to the
MH Path directory.
It looks like this might have been added just 4 years ago.
Otherwise, I'd be reluctant to remove it. Earl?
The only place I've seen $TMP referenced is on Windows. We really
shouldn't proliferate this to UNIX when the convention since the
dawn of time has been $TMPDIR.
I agree, but it's
I expect that there are: anything that's relative to the MH Path
is susceptible. But again, there may be users out there who depend
on it, and moreso than $TMP.
I'm all for backwards compatibility, but in this case I'm with Lyndon:
I wouldn't even hesitate chucking this over the side.
I
I expect that there are: anything that's relative to the MH Path
is susceptible. But again, there may be users out there who depend
on it, and moreso than $TMP.
I'm all for backwards compatibility, but in this case I'm with Lyndon:
I wouldn't even hesitate chucking this over the
But my underlying concern with allowing a relative mhpath surrounds
taking advantage of $HOME leakage/confusion in the event you managed
to get something to call an MH command with elevated privileges.
I.e. $HOME != getpwuid(geteuid())-pw_dir. With absolute paths,
this is never an issue.
Jon wrote:
Don't know if anybody knows why this happens or cares enough to fix it,
but every once in a while I have to go into my Mail directory and remove
piles of mhshow and post temporary files. Would probably better to put
these into /tmp where they would automatically be cleaned up by
Jon wrote:
BTW, this reminds me, this is also the reason why I grumble about
having nmh make everything a MIME message by default. I seem to
recall that it's very hard or impossible to make pagers work
properly, especially if you want to pipe the output into something.
show -noc[heckmime]
Ken wrote:
So I think people know I've been working on the attach stuff, as part of
the always running mhbuild so we don't send out invalid messages all of
the time problem. As part of this, I've noticed that when you run
attach with -attachformat 0, you get a x-unix-mode MIME parameter.
My
Jon wrote:
Cool. Thanks. BTW, would it make sense to have a -v option on al
at whatnow where -v would mean verbose and show the mime type, etc?
That way the hard core among us could check and fall back to mhbuild
if they didn't like the way that it looked.
Done:
attach [-v [-a 0|1|2]]
Ralph wrote:
My rmmproc creates filenames like ,10139,1388316255.094920554
so as more of those pile up, less entries fit in the 32KiB and
more calls to it are needed and there's more entries starting
with `,' to be skipped over. Clearly, I need to switch to ','
+ base254-encoding. ;-)
Or
Ralph wrote:
I was thinking more of every nmh command optionally running under
valgrind for all the tests.
Done. If the NMH_VALGRIND environment variable is set when the
test suite is run (make check), it will try to use valgrind
when running the program under test.
It found a couple of
Robert wrote:
Norm,
I hope I speak for all of us when I say we all hope, and expect,
that you will be with us for many years to come.
I am certain that you do speak, and very well at that, for all of us.
Thank you, Norm, for MH and your contributions to its derivatives.
And, Happy
Jon wrote:
David Levine writes:
Paul F. wrote:
how do i use whatnow's attach to attach a file, like a mail
message, with a specific Content-Type? i.e., if i use this:
Nmh-Attachment: /home/pgf/Mail/inbox/2902
i get a Content-Type of text/plain rather than message/rfc822
Jon wrote:
Cool. Thanks. BTW, would it make sense to have a -v option on al
at whatnow where -v would mean verbose and show the mime type, etc?
That way the hard core among us could check and fall back to mhbuild
if they didn't like the way that it looked.
Yes, I'd use that. That's not a
Ken wrote:
Unless you're referring to really sending 8-bit content, but
is there demand for that?
Are you asking if people compose drafts with 8-bit characters in
them? Seems like the answer to that is yes. If you're asking if
people want a C-T-E of 8bit ... well, it would be friendlier,
I wrote:
Ken wrote:
Unless you're referring to really sending 8-bit content, but
is there demand for that?
Are you asking if people compose drafts with 8-bit characters in
them? Seems like the answer to that is yes. If you're asking if
people want a C-T-E of 8bit ... well, it
I agree that 8bit would be friendlier. The question is
whether we should try to get it into 1.6.
And another possible issue: I'm not sure that our MIME
parser can handle 8-bit input. I don't have evidence
at hand, but I tried quickly a while back and ran into
trouble.
I know Ralph
:
Actually, David Levine already agreed in private mail that
an audit would make sense
Well, my exact words were:
Maybe we'll get to that task some day. In the meantime,
the significant noise from the linker could obscure more
pressing problems. Therefore, I have suppressed it from
Ralph wrote:
I was thinking more of every nmh command optionally running under
valgrind for all the tests.
That's been on my wish list for a while. Patches welcome :-)
The test suite does run every undeprecated nmh command, that's a
start.
David
Ken wrote:
- Really, this overuse of strcpy/strcat results from our usage of fixed
sized buffers. We should be switching to dynamically-allocated strings
whenever possible. Fixing that means dealing with idea of who actually
owns a particular memory object and is responsible for
Paul F. wrote:
i'm having trouble with the next two points:
- If you try to attach after a mime, you get an error.
- send runs mhbuild -auto -nodirectives. -auto means, don't
error out if there's a MIME-Version header, just don't process the
draft. -nodirectives means
Paul F. wrote:
how do i use whatnow's attach to attach a file, like a mail
message, with a specific Content-Type? i.e., if i use this:
Nmh-Attachment: /home/pgf/Mail/inbox/2902
i get a Content-Type of text/plain rather than message/rfc822
I've been thinking about this. It's possible,
Jon wrote:
So my opinion is to live with it for now. If you're happy with
attach, then use it. If you want to use mhbuild, go ahead. Just
don't use both. Save your energy for a coding effort with a greater
value proposition.
The movtivation behind all this is to always produce MIME
Pascal wrote:
On Thu, 12 Dec 2013 19:52:54 -0500, David Levine wrote:
test-manpages fails because of a slew of these:
man8/post.8:1: warning: unbalanced .el request
Any ideas?
To me, this looks like it could be caused by a local patch to
an-old.tmac that's applied
Pascal wrote:
rand()/srand() are not cryptographically secure PRNGs. Some systems
have the much better suited arc4random() family of functions; there's no
reason to not use it if it is available. Make m_rand() just a wrapper
around arc4random_buf() in that case. (There's no need to ever
Ken wrote:
Well, let me make this alternate proposal:
- attach adds Nmh-Attachment headers as per usual. Maybe we'll add
something like: attaching foo.pdf to message as application/pdf so
the user can see what MIME type is being used (really, that's all
I care about).
- You can
Lyndon wrote:
I have added an OpenBSD 5.4 (amd64) buildbot slave to the mix.
Their auto{conf,make}s require some environment variables be set to
pick which version of the tools to run under the hood. For now I
have wired a hack into autogen.sh, but a better solution is
required.
Cool!
Paul F. wrote:
mainly it's because attach removes attachment from the flow of
composition -- i have to remember to attach _after_ i've written out
my draft, which to me is the ready to send point. i forget to
include the attachment often enough as it is -- i much prefer adding
an attachment
Ken wrote:
One question: would it make sense to put the entire mhbuild
directive in the Nmh-Attachment header instead of just the
path? Users could then edit it as they wish.
I feel the answer is no. I would like to give users the option to
add their own Nmh-Attachment headers; if
Paul wrote:
that's an interesting point, and i just realized that it's one reason
i've never been comfortable with attach. my editor supports enough
filename completion that when inserting the mhbuild directive (via a
helper script), i can be sure that the filename is spelled correctly
and
Ken wrote:
Can the people who want to have attach append mhbuild directives
explain what their thinking is, specifically why they think their
approach is preferrable? I went back and looked at the thread very
carefully, and none of the proponents of this approach really covered
why they
Valdis wrote:
On Sun, 08 Dec 2013 00:27:28 +0100, Rickard Carlsson said:
Forgive me for maybe being silly due to ignorance of Nmh internals, but
'elinks -dump' introducing leading whitespace might perhaps be remedied by
elinks -eval 'set document.browse.margin_width = 0' -dump
Robert wrote:
awk 'length($0) == 0 e == 1 { next }
{ e = length($0) == 0 }
{ print }'
results in:
awk: syntax error near line 2
awk: illegal statement near line 2
Ralph wrote:
Oh, line 1. `awk --posix' here suggests length would like parenthesis.
awk '!length() e
Rickard wrote:
Forgive me for maybe being silly due to ignorance of Nmh internals, but
'elinks -dump' introducing leading whitespace might perhaps be remedied by
elinks -eval 'set document.browse.margin_width = 0' -dump [...]
Nice, I added that option to the elinks command used by
Ralph wrote:
Apparently, /usr/xpg4/bin/awk is POSIX compliant. Can build and
test instructions for nmh on Solaris not state /usr/xpg4/bin needs
to be up the front of PATH?
Yes, but then our buildbot provider, maintainer, and
gracious host would have to actually do that :-) But
seriously,
Peter wrote:
Does anyone have an mts.conf setup that works with Fastmail.fm?
Ideally, I'd like to use their proxy server,
smtps-proxy.messagingengine.com, since my employer blocks outgoing
smtp connections.
Are you using SSL and authentication? If not, I expect
that you'll have to. Your
Lyndon wrote:
My preference would be for the configure script to detect it is
being run on Solaris and fudge $PATH appropriately. That way we get
consistent source builds on Solaris even when the person building
doesn't have the XPG4 tools at the front of their path.
At some point, the pain
Ken wrote:
I don't know anything about fastmail.fm, but does it actually speak
SMTP on port 80?
Sure looks like it. This is through an ssh tunnel:
$ telnet localhost 80
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mail.messagingengine.com ESMTP ready
Ken wrote:
Huh. Well, I can't speak to that ... when I try connecting to it remotely,
I get a web server on port 80.
See below, he's using a different server.
You would want this in your .mh_profile:
send: -server mail.messagingengine.com -port 587 -tls -sasl -user
usern...@fastmail.fm
Ken wrote:
[Ralph wrote:]
If attach instead appended an mhbuild directive to the draft, would
that make the path after that simpler?
No.
My feeling is that if you put a mhbuild directive in the draft,
you're prepared to deal with any issues arising from it. But I
don't think it's
Why wouldn't that be reasonable? The logic would be simpler:
In WhatNow?
- If you run mime, run mhbuild on the draft.
- If you attach, add the appropriate mhbuild directive. Do not do
this if there is a MIME-Version header.
In post(8):
- Run mhbuild -auto -nodirectives.
The
I think it'd be worth trying to solve that. Could we look for
false mhbuild directives and escape them if not already escaped?
I think it would be challenging; the code that does that is the regular
MIME parsing code. Also, the syntax is that if it's not something that
is recognized after
Jon wrote:
Gave this a bit more thought. What *exactly* is the issue?
I'll take a shot, but Ken can probably do better: we want
nmh to always produce mime messages without getting confused
by text that isn't a mhbuild directive but looks like it,
while still supporting attach.
Is it a lack
I wrote:
Valdis wrote:
Verdict: elinks is introducing the 3 blanks.
Thanks, I'll install elinks and see what I can do to handle it.
The test relies on diff -b to compare the text lines.
Two problems here:
1) POSIX diff only has -b (not -w), and it says that a line with
no space is
Ralph wrote:
sed 's/^/ /' on both files beforehand would make -b happy? Expected can
be done once, actual each time...
That works.
2) elinks inserts some non-breakable spaces (U+00A0), and GNU diff
doesn't recognize them as whitespace (my LANG is en_US.UTF-8).
Here, this elinks
I wrote:
I put in that awk magic.
Ah, but it busts on Solaris:
awk: syntax error near line 1
awk: bailing out near line 1
At least we know where the problem is. What's your sed
equivalent of cat -s?
David
___
Nmh-workers mailing list
Ralph wrote:
Hi Valdis,
! Need to go! Need ... to ... go!
!Need to go! Need ... to ... go!
I have zero clue why mhfixmsg is apparently adding 2 leading blanks to
the line.
Give us a clue about the third. ;-)
:-)
Valdis, what platform is this on? And what does the
Valdis wrote:
Verdict: elinks is introducing the 3 blanks.
Thanks, I'll install elinks and see what I can do to handle it.
David
___
Nmh-workers mailing list
Nmh-workers@nongnu.org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
901 - 1000 of 1394 matches
Mail list logo
