Re: 0.95.3: How to use õ÷³ThÍLTÔÛ¯¶¹ÓÞý=¨ßÚݾ·dUVÈFuUVÊuuDHËd
Le Thu 04/03/1999, David DeSimone disait
> Vikas Agnihotri <[EMAIL PROTECTED]> wrote:
> >
> > Thats not right. If getenv("LANG") == NULL, applications are supposed
> > to deal with it by defaulting to the "C" locale or some such
> > appropriate default. Not croak and whine about it.
>
> I'm not saying that less should die. In fact, my version of less does
> not die; it simply prints inverse-video hex-codes for the characters
> that it believes are not printable (i.e. the characters with the
> high-bit set).
You can set the environment variable LESSCHARSET to specify
the charset.
--
Erwan DAVID| Domaine de Voluceau
Trusted Logic | BP 105, 78153 Le Chesnay CEDEX France
Je ne parle qu'en mon nom propre, et encore pas toujours.
Re: quoting and long lines
Or use Jed and get mail_mode.sl. It will reformat to standard line length using Alt Q and has some handy functions for adding and deleting quotes from lines and paragraphs, just read the begining of the slang file for instructions. Pat -- Patrick Colbeck email: [EMAIL PROTECTED] Senior Analysttel: you dont seriously expect me to Azlan Ltd give that out on the internet do you ?
Re: 0.95.3: Characters
On Thu, Mar 04, Vikas Agnihotri wrote:
> On Wed, Mar 03, 1999 at 02:17:25PM -0600, David DeSimone wrote:
>
> > If I set $LANG to this value, Mutt is then able to display ISO-8859-1
> [...]
>
> Solaris 2.6. I have never mucked around with the $LANG or locale stuff
> either in Mutt or my .profile, etc and everything works fine for me. I
> am able to display iso-8859-1 just fine.
>
> > Technically, your version of "less" is broken, or rather, not very
> > smart, because it is assuming that those ISO-8859-1 characters are
> > printable, when there is no such guarantee. Without a proper $LANG
> > setting, it *should* assume that they are not printable, the same way
> > that Mutt-0.95 does.
>
> Thats not right. If getenv("LANG") == NULL, applications are supposed
> to deal with it by defaulting to the "C" locale or some such
> appropriate default. Not croak and whine about it.
>
> > We've all had to do this.
>
> Not really. As I said, I have _never_ had to muck around with this.
>
> Vikas
Hi, I'm just joined the discussion, so maybe I'm missing something, but
this is a very important issue for me. I'm using Solaris 2.5.1 but I can't
see correctly Spanish characters. Mutt is version 0.95.1i
I've never played with Locale values but these are by default:
LANG=
LC_CTYPE="C"
LC_NUMERIC="C"
LC_TIME="C"
LC_COLLATE="C"
LC_MONETARY="C"
LC_MESSAGES="C"
LC_ALL=
What could be done to see those characters in the pager?
Thank you very much.
--
Tomas Calvo Gomez Telefonica I+D
mailto:[EMAIL PROTECTED]Centros de Servicio de Acceso
Tlf : +34 91 337 4489 C/Emilio Vargas, Num. 6
Fax : +34 91 337 4502 28043 - Madrid (SPAIN)
PGP Key Request:mailto:[EMAIL PROTECTED]
[bug, patch] Re: [Announce] Mutt 0.95.4 is out.
Thomas Roessler on Wed 3/03 21:35 +0100:
> Mutt 0.95.4 is out. This version should be considered BETA.
There is a bug in the `configure' script that comes with this
distribution.
1158 IFS="${IFS= . }"; ac_save_ifs="$IFS"; IFS="${IFS}:"
1159 for ac_dir in $PATH:/usr/sbin:/usr/lib$ac_dummy; do
1160 test -z "$ac_dir" && ac_dir=.
1161 if test -f $ac_dir/$ac_word; then
1162 ac_cv_path_SENDMAIL="$ac_dir/$ac_word"
1163 break
1164 fi
1165 done
1166 IFS="$ac_save_ifs"
This code is broken. According to SUS2, field splitting does not take
place on strings that are not otherwise expanded. In the second line
above, colons in $PATH do indeed cause the elements they delimit to
separate into distinct words, because expansion is performed. In the
rest of the string, however, the colons are not subject to IFS field
splitting because there is no expansion performed on them. Observe the
following code fed to /bin/sh:
IFS="${IFS}:"
PATH="~/bin:/bin:/usr/bin:/usr/local/bin"
for DIR in $PATH:/usr/sbin:/usr/lib; do
echo $DIR
done
whose execution results in
~/bin
/bin
/usr/bin
/usr/local/bin /usr/sbin /usr/lib
The last line is still split into spaces because it is expanded when
echoing $DIR, while $IFS is still set to include colons.
The results of this in line 1161 of `configure' are that `test' is given
too many arguments, and fails.
Note that, previous to bash-2.03 (to which my /bin/sh is a link), this
error was hidden by another bug in its "$@" expansion. It has been
fixed with the new release, and exposes this bug in the configure
script.
The fix would involve making `:/usr/sbin:/usr/lib' from line 1159 above
to be the value of a variable, defined before this line, and expanded in
the line instead of that string itself. While I am not familiar with
autoconf or m4, the attached patch for `configure.in' seems to produce a
correct `configure' script when `autoconf'ed.
--
Scott
Re: [bug, patch] Re: [Announce] Mutt 0.95.4 is out.
> The fix would involve making `:/usr/sbin:/usr/lib' from line 1159 above > to be the value of a variable, defined before this line, and expanded in > the line instead of that string itself. While I am not familiar with > autoconf or m4, the attached patch for `configure.in' seems to produce a > correct `configure' script when `autoconf'ed. No attached patch ... but the proposed fix is ok. Something like ac_aux_path_sendmail=/usr/sbin:/usr/lib AC_PATH_PROG(SENDMAIL, sendmail, no, $PATH:$ac_aux_path_sendmail)
Re: mark messages with an "expires" date in future?
On Thu, Mar 04, 1999 at 04:09:22PM +, Einar Indridason wrote: > Yes, I was looking for an easy way within mutt to "this message will expire > at this time in the future" without having to manually mess with the > 'Expire: ' header. (I'm still looking :-) Looks like another reason for having a scripting language builtin to Mutt. For those that case, check for Mutt patches at: http://www.katn.com/opensw/#mutt -- Later ... Rich Roth --- On-the-Net Direct: Box 927, Northampton, MA 01061, Voice: 413-586-9668 Email: [EMAIL PROTECTED] Url: http://www.on-the-net.com ~~~ www.i-depth.com lets you Add Instant Depth to your Website~~~ ~~~ Adding depths to Web presences and Internet providers ~
Re: Bothersome Reply-To header
According to Ron Johnson: > I've just made the switch from gnus to mutt, and so far I really like it. > The only real problem I've seen so far is getting rid of this bothersome > Reply-To header that is appended to my messages. It does not even seem Do you have a REPLYTO environment variable ? If yes, remove it. PS: please fix your lines, they're way too long. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] Mutt patches collection: http://mutt.frmug.org/>
Re: Bothersome Reply-To header
Ollivier Robert <[EMAIL PROTECTED]> writes: > Do you have a REPLYTO environment variable ? If yes, remove it. I do not have a REPLYTO environment variable. I do have the reply_to option set in my .muttrc, but according to the doco that is just used for replying to listmail. I've tried unsetting it just in case, but that did not help. > PS: please fix your lines, they're way too long. Sorry, smart_wrap does not do what I had anticipated. Cheers, Ron -- Ronald L. Johnson Sr. Systems and Networks Administrator, Perl Addict MERL - A Mitsubishi Electric Research Laboratory http://www.merl.com
Re: Bothersome Reply-To header
Ron Johnson <[EMAIL PROTECTED]> wrote:
>
> I do not have a REPLYTO environment variable. I do have the reply_to
> option set in my .muttrc, but according to the doco that is just used
> for replying to listmail. I've tried unsetting it just in case, but
> that did not help.
This is an odd problem. Mutt normally does not insert a Reply-To header
unless it has a value to assign the header. However, if you have
full-header editing turned on, a blank Reply-To header will be inserted
so that you can put something in, if you want to. But the header will
be removed if it is blank.
I suspect that something else is happening, like that your editor is
inserting a blank line before the Reply-To header, so that it gets
separated and appears to be part of the body afterward. Or perhaps
another my_hdr directive is adding a header which has a newline embedded
in it. I suppose it's possible.
Try running Mutt without your .muttrc ("mutt -F /dev/null") to see if
one of your settings is causing the problem, then work backwards from
there.
--
David DeSimone | "The doctrine of human equality reposes on this:
[EMAIL PROTECTED] | that there is no man really clever who has not
Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson
Convex Division |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
bounce! as opposed to bounce
How do I force bounce a mail message so as to avoid the prompt message: "Are you sure you want to bounce this message? (Y)es/(N)o" I am almost 37, all grown up now and if I press `b' that means I have made my decision and am prepared to suffer the consequences. GTFM but got nothing (no its not a typo:)) Thanx -- Eric Smith <[EMAIL PROTECTED]> Vodacom 082 780 7888
Re: Bothersome Reply-To header
David DeSimone <[EMAIL PROTECTED]> writes: > This is an odd problem. Mutt normally does not insert a Reply-To header > unless it has a value to assign the header. However, if you have > full-header editing turned on, a blank Reply-To header will be inserted > so that you can put something in, if you want to. But the header will > be removed if it is blank. Yes, I did have edit_headers set. If I unset that, everything looks OK. I think that it must be some kind of bad interaction between edit_headers and my editor (vim). When I edit mail everything looks OK and the Reply-To field is in the headers. It just seems to add a blank line before it is sent out. Thanks! Ron -- Ronald L. Johnson Sr. Systems and Networks Administrator, Perl Addict MERL - A Mitsubishi Electric Research Laboratory http://www.merl.com
Re: bounce! as opposed to bounce
Eric Smith <[EMAIL PROTECTED]> wrote: > > I am almost 37, all grown up now and if I press `b' that means I have > made my decision and am prepared to suffer the consequences. If you are man enough that you can always type the bounce-to address correctly before you press , you're a better man than I am. So you are probably also man enough to go into the source and edit out the offending prompt. :) Better yet, create a config variable for it, and submit a patch. :) -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson Convex Division |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: Bothersome Reply-To header
Ron Johnson <[EMAIL PROTECTED]> wrote: > > I think that it must be some kind of bad interaction between > edit_headers and my editor (vim). When I edit mail everything looks > OK and the Reply-To field is in the headers. It just seems to add a > blank line before it is sent out. What if you edit the message, return to the compose screen, then select edit again? Does the header move to the body of the message? If it doesn't, then I don't see how it could be the editor's fault. Strange, either way. -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson Convex Division |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: bounce! as opposed to bounce
On Fri, Mar 05, 1999 at 02:21:07PM -0600, David DeSimone <[EMAIL PROTECTED]> wrote: > Eric Smith <[EMAIL PROTECTED]> wrote: > > > > I am almost 37, all grown up now and if I press `b' that means I have > > made my decision and am prepared to suffer the consequences. > > If you are man enough that you can always type the bounce-to address > correctly before you press , you're a better man than I am. So > you are probably also man enough to go into the source and edit out the > offending prompt. :) > > Better yet, create a config variable for it, and submit a patch. :) Yeah, this is exactly what quad-options are for, just that nobody's ever requested that this be made a quad-option... Use the source, Luke! :-) -Daniel -- Daniel Eisenbud [EMAIL PROTECTED]
Re: Bothersome Reply-To header
Quoting David DeSimone <[EMAIL PROTECTED]>: > What if you edit the message, return to the compose screen, then select > edit again? Does the header move to the body of the message? If it > doesn't, then I don't see how it could be the editor's fault. > > Strange, either way. When I first edit the message, everything looks fine. If I return to the compose screen and then edit again, my original Reply-To header is in the body and I have a new Reply-To header in the headers. Most odd. I'm not using any my_hdr, so I don't think I'm adding any lines manually. Cheers, Ron -- Ronald L. Johnson Sr. Systems and Networks Administrator, Perl Addict MERL - A Mitsubishi Electric Research Laboratory http://www.merl.com
Re: Bothersome Reply-To header
Yup, if I do multiple edits, I get multiple Reply-To headers. Here is an example of editing, going to compose, and editing again 4 times over: From: Ron Johnson <[EMAIL PROTECTED]> To: Ron Johnson <[EMAIL PROTECTED]> Cc: Bcc: Subject: test Reply-To: Reply-To: Test 3 Reply-To: Test 2 Reply-To: Test 1 Each edit adds a Reply-To to the body. Cheers, Ron -- Ronald L. Johnson Sr. Systems and Networks Administrator, Perl Addict MERL - A Mitsubishi Electric Research Laboratory http://www.merl.com
Re: Bothersome Reply-To header
Oddly, if I reply to a message the Reply-To stays in the header. The problem only manifests itself when I compose a new message. Cheers, Ron -- Ronald L. Johnson Sr. Systems and Networks Administrator, Perl Addict MERL - A Mitsubishi Electric Research Laboratory http://www.merl.com
Re: Bothersome Reply-To header
Ron Johnson <[EMAIL PROTECTED]> wrote: > > When I first edit the message, everything looks fine. If I return to > the compose screen and then edit again, my original Reply-To header is > in the body and I have a new Reply-To header in the headers. Most > odd. What editor are you using? Is it configured to mess with the headers somehow? Sounds like some sort of exit-macro is running and changing things up a bit. Either that, or Mutt thinks there's something wrong with the line just previous to the Reply-To header, and so it thinks that that must be the end of the headers, and parses the Reply-To as if it was part of the body. On my system, the line just above Reply-To is the Subject header. Is there something odd on the Subject line? Is your editor word-wrapping the subject somehow? -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson Convex Division |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: Bothersome Reply-To header
> Either that, or Mutt thinks there's something wrong with the line just > previous to the Reply-To header, and so it thinks that that must be the > end of the headers, and parses the Reply-To as if it was part of the > body. On my system, the line just above Reply-To is the Subject header. It occurs to me that you might simply be pressing when you are finished typing the subject line. This enters a blank line into the header section, which is the marker between header and body. This will lead to the behavior you see. But then again I might be way off. :) -- David DeSimone | "The doctrine of human equality reposes on this: [EMAIL PROTECTED] | that there is no man really clever who has not Hewlett-Packard | found that he is stupid." -- Gilbert K. Chesterson Convex Division |PGP: 5B 47 34 9F 3B 9A B0 0D AB A6 15 F1 BB BE 8C 44
Re: [bug, patch] Re: [Announce] Mutt 0.95.4 is out.
Lars Hecking on Fri 5/03 12:35 +: > > The fix would involve making `:/usr/sbin:/usr/lib' from line 1159 > > above to be the value of a variable, defined before this line, and > > expanded in the line instead of that string itself. While I am not > > familiar with autoconf or m4, the attached patch for `configure.in' > > seems to produce a correct `configure' script when `autoconf'ed. > > No attached patch ... but the proposed fix is ok. Something like I seem to do that a lot when I don't get any sleep. Anyways, now it *is* attached. > ac_aux_path_sendmail=/usr/sbin:/usr/lib > AC_PATH_PROG(SENDMAIL, sendmail, no, $PATH:$ac_aux_path_sendmail) This won't work because the remaining colon will still end up in the expansion of the `for' mapovers; it has to be at the end or $PATH of the beginning of $ac_aux_path_sendmail to be parsed by the IFS pass. -- Scott --- configure.inThu Mar 4 18:21:48 1999 +++ configure.in.newFri Mar 5 06:38:19 1999 @@ -30,7 +30,8 @@ ;; esac -AC_PATH_PROG(SENDMAIL, sendmail, no, $PATH:/usr/sbin:/usr/lib) +ac_aux_path_sendmail=":/usr/sbin:/usr/lib" +AC_PATH_PROG(SENDMAIL, sendmail, no, $PATH$ax_aux_path_sendmail) AC_DEFINE_UNQUOTED(SENDMAIL, "$ac_cv_path_SENDMAIL") OPS='$(srcdir)/OPS'
Bothersome Reply-To header
Reply-To: Howdy, I've just made the switch from gnus to mutt, and so far I really like it. The only real problem I've seen so far is getting rid of this bothersome Reply-To header that is appended to my messages. It does not even seem to get put into the headers correctly (as can be seen above). I've picked over my .muttrc file, but do not see anything that looks like it turns the header off. Could anyone point me in the right direction? Cheers, Ron (mutt-convert) -- Ronald L. Johnson Sr. Systems and Networks Administrator, Perl Addict MERL - A Mitsubishi Electric Research Laboratory http://www.merl.com
