Disabling start and stop keys

[Jeffery Small]

I have a script that fires up mutt in an xfce4-terminal window.  In my ksh
shell .kshrc file, I use stty to disable (undef) the stop (^S) and start
(^Q) characters.  However, when I run mutt as follows:

xfce4-terminal  -e /usr/local/bin/mutt &

I find that the stop/start characters remain active.  I have tried adding
multiple -e options to xfce4-terminal to disable the chars before running
mutt, but with no luck.

Is there some method to disable these keys in .muttrc which is processed
inside the running terminal?  I've looked for a something that will execute
a command in the current shell (rather than a sub-shell) but see nothing.

I'm guessing that this is a simple problem, and I'm missing the forest
for the trees.

Re: Key binding problem

[Jeffery Small]

"Kevin J. McCarthy"  writes:

>On Sun, Nov 06, 2022 at 07:31:44PM -0000, Jeffery Small wrote:
>>I just tried that, but the debug file reports the same thing shown on the
>>command line when the key is pressed.  Here are the results:
>>
>>Keypad / key:  Oo:   Char = A, Octal = 1101, Decimal = 577
>>Keypad * key:  Oj:   Char = C, Octal = 1103, Decimal = 579
>>Keypad - key:  Om:   Char = D, Octal = 1104, Decimal = 580
>>Keypad + key:  Ok:   Char = ?, Octal = 1077, Decimal = 575
>>Keypad Enter:  OM:   Char = , Octal = 527, \
>>Decimal = 343

>For these large octal values, you can try the syntax  in
>your muttrc.
>
>e.g.
>bind generic  <1101>first-entry
>bind generic  <1103>last-entry
>bind generic  <1104>select-entry
>bind generic  <1077>next-entry
>bind generic   next-entry

Great suggestion.  I was unaware that you could do that for large octal
values.  I made these assignments and the keys are now working in mutt.
One thing to note is that on the help page, these assignments are being
displayed as the characters A, C, D and ? which could generate confusion
since these are not the actual characters which also show up and are bound
to other actions.

>>So what is up with this?  Why is mutt seeing one thing output while other
>>programs such as vim and less see the escape code sequences?

>Mutt uses ncurses for terminal input/output interaction.  Those are the
>values the ncurses getch() function is returning to mutt.  Unfortunately,
>I couldn't tell you why this differs, but I'm fairly sure vim and less
>don't use ncurses.

I had already looked through the terminfo value for xterm-256color and
saw that these escape code sequences were not output for any entry.  In
fact, none of the keypad sequences were defined in the file.  Even the
five numeric keys, ka1, ka3, kb2, kc1 and kc3 had no relationship to the
actual codes issued:

Key:TerminfoActual
7:  ka1=\EOw[44~
9:  ka3=\EOy[46~
5   kb2=\EOu[42~
1   kc1=\EOq[26~
3   kc3=\EOs[31~

Yet, all these keypad keys work.  Why does ncurses report these actual
values, but not those for the rogue keys?  I even tried redefining one of
the function keys in the terminfo definition to issue the Ok sequence
for the keypad + key, but even when defined, the key didn't work.

The problem is solved, but just in case you want to investigate further,
I include the terminfo entry below.

Thanks for the help.  It's nice to get the keys working again.  I have
decades od muscle memory working againt change!  :-)


#   Reconstructed via infocmp from file: /lib/terminfo/x/xterm-256color
xterm-256color|xterm with 256 colors,
am, bce, ccc, km, mc5i, mir, msgr, npc, xenl,
colors#0x100, cols#80, it#8, lines#24, pairs#0x1,
acsc=``aaffggiijjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~,
bel=^G, blink=\E[5m, bold=\E[1m, cbt=\E[Z, civis=\E[?25l,
clear=\E[H\E[2J, cnorm=\E[?12l\E[?25h, cr=\r,
csr=\E[%i%p1%d;%p2%dr, cub=\E[%p1%dD, cub1=^H,
cud=\E[%p1%dB, cud1=\n, cuf=\E[%p1%dC, cuf1=\E[C,
cup=\E[%i%p1%d;%p2%dH, cuu=\E[%p1%dA, cuu1=\E[A,
cvvis=\E[?12;25h, dch=\E[%p1%dP, dch1=\E[P, dim=\E[2m,
dl=\E[%p1%dM, dl1=\E[M, ech=\E[%p1%dX, ed=\E[J, el=\E[K,
el1=\E[1K, flash=\E[?5h$<100/>\E[?5l, home=\E[H,
hpa=\E[%i%p1%dG, ht=^I, hts=\EH, ich=\E[%p1%d@,
il=\E[%p1%dL, il1=\E[L, ind=\n, indn=\E[%p1%dS,

initc=\E]4;%p1%d;rgb:%p2%{255}%*%{1000}%/%2.2X/%p3%{255}%*%{1000}%/%2.2X/%p4%{255}%*%{1000}%/%2.2X\E\\,
invis=\E[8m, is2=\E[!p\E[?3;4l\E[4l\E>, kDC=\E[3;2~,
kEND=\E[1;2F, kHOM=\E[1;2H, kIC=\E[2;2~, kLFT=\E[1;2D,
kNXT=\E[6;2~, kPRV=\E[5;2~, kRIT=\E[1;2C, ka1=\EOw,
ka3=\EOy, kb2=\EOu, kbeg=\EOE, kbs=^?, kc1=\EOq, kc3=\EOs,
kcbt=\E[Z, kcub1=\EOD, kcud1=\EOB, kcuf1=\EOC, kcuu1=\EOA,
kdch1=\E[3~, kend=\EOF, kent=\EOM, kf1=\EOP, kf10=\E[21~,
kf11=\E[23~, kf12=\E[24~, kf13=\E[1;2P, kf14=\E[1;2Q,
kf15=\E[1;2R, kf16=\E[1;2S, kf17=\E[15;2~, kf18=\E[17;2~,
kf19=\E[18;2~, kf2=\EOQ, kf20=\E[19;2~, kf21=\E[20;2~,
kf22=\E[21;2~, kf23=\E[23;2~, kf24=\E[24;2~,
kf25=\E[1;5P, kf26=\E[1;5Q, kf27=\E[1;5R, kf28=\E[1;5S,
kf29=\E[15;5~, kf3=\EOR, kf30=\E[17;5~, kf31=\E[18;5~,
kf32=\E[19;5~, kf33=\E[20;5~, kf34=\E[21;5~,
kf35=\E[23;5~, kf36=\E[24;5~, kf37=\E[1;6P, kf38=\E[1;6Q,
kf39=\E[1;6R, kf4=\EOS, kf40=\E[1;6S, kf41=\E[15;6~,
kf42=\E[17;6~, kf43=\E[18;6~, kf44=\E[19;6~,
kf45=\E[20;6~, kf46=\E[21;6~, kf47=\E[23;6~,
kf48=\E[24;6~, kf49=\E[1;3P, kf5=\E[15~, kf50=\E[1;3Q,
kf51=\E[1;3R, kf52=\E[1;3S, kf53=\E[15;3~, kf54=\E[17;3~,
kf55=\E[18;3~, kf56=\E[19;3~, kf57=\E[20;3~,
kf58=\E[21;3~, kf59=\E

Re: Key binding problem

[Jeffery Small]

"Kevin J. McCarthy"  writes:

>Have you tried running mutt with '-d 1', running , and looking
>at ~/.muttdebug0 as you press those keys?  That might list the full
>sequence of keys mutt is seeing when you press the non-working keys and
>give a clue.

I just tried that, but the debug file reports the same thing shown on the
command line when the key is pressed.  Here are the results:

Keypad / key:  Oo:   Char = A, Octal = 1101, Decimal = 577
Keypad * key:  Oj:   Char = C, Octal = 1103, Decimal = 579
Keypad - key:  Om:   Char = D, Octal = 1104, Decimal = 580
Keypad + key:  Ok:   Char = ?, Octal = 1077, Decimal = 575
Keypad Enter:  OM:   Char = , Octal = 527, Decimal = 343

Notice the large octal codes.

Now, for comparison, here is what I get for some other keys:

Keypad Num_Lock:
Char = , Octal = 33, Decimal = 27
Char = O, Octal = 117, Decimal = 79
Char = I, Octal = 111, Decimal = 73

Keypad 7 key:
Char = , Octal = 33, Decimal = 27
Char = [, Octal = 133, Decimal = 91
Char = 4, Octal = 64, Decimal = 52
Char = 4, Octal = 64, Decimal = 52
Char = ~, Octal = 176, Decimal = 126

Keypad . key:
Char = , Octal = 33, Decimal = 27
Char = [, Octal = 133, Decimal = 91
Char = 3, Octal = 63, Decimal = 51
Char = 2, Octal = 62, Decimal = 50
Char = ~, Octal = 176, Decimal = 126

So what is up with this?  Why is mutt seeing one thing output while
other programs such as vim and less see the escape code sequences?

Just to be sure that some other setting in mutt wasn't interfering,
I emptied the .muttrc file of all options save a single keypad key
binding, but got the same result for that key.

The Num_Lock key has always been disabled for my keyboard so it is not
playing a role in what's going on.  However, I do notice that in a standard
xfce4-terminal with TERM=xterm-256color, when I press the following keys,
on the command line they output:

Key Output
-   -
Num_Lock
Keypad //
Keypad **
Keypad --
Keypad ++

All other keypad keys issue the expected escape sequences.

And finally, I have LC_ALL=C.UTF-8
I tried setting LC_ALL=C, but it made no difference in mutt's operation.

I'm still at a loss to understand exactly where the problem lies.

Regards,
-- 
Jeff

Key binding problem

[Jeffery Small]

Ever since upgrading from Xubuntu 20.04 to Xubuntu 22.04.1, I've been
having a problem with certain key bindings for some keypad keys.  These are
properly defined in my .muttrc file and used to work under the previous
version of the OS, but now report "Key is not bound," even though when I
type "?", the bindings are all properly listed.

I was running mutt 2.1.4 which was the latest version in the repository.
I downloaded the just released 2.2.8, compiled and installed it, but it
made no difference.

I'm using a Sun Type-6 keyboard with the full keypad on the right.  The
majority of the keys work, while others do not.  For example, in .muttrc I
have the following:

bind  generic   [25~   previous-entry  # Keypad 0 Key
bind  generic   [26~   previous-entry  # Keypad 1 Key
bind  generic   [28~   last-entry  # Keypad 2 Key
bind  generic   [31~   next-entry  # Keypad 3 Key
bind  generic   [33~   previous-entry  # Keypad 4 Key
bind  generic   [42~   select-entry# Keypad 5 Key
bind  generic   [43~   next-entry  # Keypad 6 Key
bind  generic   [44~   previous-page   # Keypad 7 Key
bind  generic   [45~   first-entry # Keypad 8 Key
bind  generic   [46~   next-page   # Keypad 9 Key
bind  generic   OI first-entry # Keypad Num_Lock Key
bind  generic   Oo first-entry # Keypad / Key
bind  generic   Oj last-entry  # Keypad * Key
bind  generic   Om select-entry# Keypad - Key
bind  generic   Ok next-entry  # Keypad + Key
bind  generic   [32~   next-entry  # Keypad . Key
bind  generic   OM next-entry  # Keypad Enter Key

Keys 0-9, period and Num_Lock work, but Keys /*-+ and Enter do not, despite
having the accurate escape sequences here and showing up properly defined
on the help page.  Notice that the Num_Lock key has  followed by two
letters and that works, but the others with the same format fail.

I realized that my keys emit different codes if, for example, Alt is
pressed, so I added the following entries as a test.

bind  generic   O3ofirst-entry # Keypad / Key
bind  generic   O3jlast-entry  # Keypad * Key
bind  generic   O3mselect-entry# Keypad - Key
bind  generic   O3knext-entry  # Keypad + Key
bind  generic   O3Mnext-entry  # Keypad Enter Key

Now, using Alt, the /*+ and Enter Keys work but the minus (-) key still
fails.

I tried using the what_key function, but it's of little use as it only
reports the last character of the escape sequences.

I've had a long running discussion over on comp.mail.mutt with no results
so far, so I wanted to ask here and see if anyone has a clue as to what
might be wrong.

And BTW, I use custom mappings of all the keypad keys when editing using
vim, and another set of mappings for the less pager and everything works
perfectly in these cases, so the problem seems to be specific to mutt.

Thanks for any insights.

Regards,
-- 
Jeffery Small

New mutt GPGME error

[Jeffery Small]

I just upgraded to Ubuntu 17.04 and got a new version of mutt: 1.7.2.1

I now frequently get the following error message for delivered mail:

"GPGME: CMS protocol not available"

I'm not using gpg and would like to stop the continual generation of these
messages.  I'm hoping that there is something that can be placed in the
config file that can control this.  Any pointers would be appreciated.
Thanks.

-- 
Jeff Small

Re: Using mixmaster

[Jeffery Small]

John:

Thanks you for all the great information.
--
Jeff

John Long <codeb...@inbox.lv> writes:

>On Mon, Feb 15, 2016 at 08:32:18PM -0800, Jeffery Small wrote:
>> 
>> I just installed mixmaster on my Ubuntu 15.10 system and am trying it out.
>> I have a question.  The mutt manual says:
>> 
>> "To use it [i.e., mixmaster], you'll have to obey certain restrictions.
>> Most important, you cannot use the Cc and Bcc headers."

>I think this must be a newer version of Mixmaster. I would question the
>worthiness of that. See if you can find an older version. It compiles easily
>on Linux. Look on sourceforge or elsewhere. Get a known good copy of PGP,
>preferably 6.5.8 command line and/or 2.6 Disastry (2.6.3?). Disastry is 2.6
>with new hashes and ciphers to bring you up and in some cases past 6.5.8.

>Mixmaster strips headers. If you are concerned send a few test posts to
>yourself at various email addresses. You can test it by creating fake mix
>nodes and a fake nodes file (forgot what it's called but it is the stats
>file that Mixmaster uses to select remailers) with your own keys and use the
>outfile option. The mail won't be sent. Then you can repeatedly decrypt it
>with the keys for the fake nodes and see exactly what is being sent.

>> 
>> When I look in my /etc/mixmaster/filter.conf

>Seems to me this is a new thing. I played around with mixmaster back in the
>day and I don't remember this. I could be wrong.

>> So what are the restrictions on Cc: and Bcc: as it seems that mixmaster is
>> prepared to use (or at least pass) them?  Mostly, I'm just asking out of
>> curiosity.

>Normally Mixmaster will strip all headers that could leak info. If you want
>to just post to a newsgroup use the newsgroups header. If you want to mail
>anonymously I don't know why you couldn't use cc or bcc also.

>If you want to communicate two way via Mixmaster you'll have to learn to
>create a reply block. The new nyms at Steve Crook's site are ok if you think
>about what you are doing and use Mixmaster to set it up and don't ever view
>the website except over TOR or known good proxy.. I'm not sure how many old
>school nym servers are still around but they are better if you know what
>you're doing. Plenty of info around on this but you'll have to put the
>pieces together. Not much has changed, the old info is still valid.

>You'll need to get handy with command line gpg and pgp and you should also
>keep in mind the 1024 mix pubkeys are no longer safe for serious use and
>also if you are going to communicate securely you need end-to-end
>encryption with big pubkeys.  

>/jl

>-- 
>ASCII ribbon campaign ( ) Powered by Lemote Fuloong
> against HTML e-mail   X  Loongson MIPS and OpenBSD
>   and proprietary/ \http://www.mutt.org
> attachments /   \  Code Blue or Go Home!
> Encrypted email preferred  PGP Key 2048R/DA65BC04 

Using mixmaster

[Jeffery Small]

I just installed mixmaster on my Ubuntu 15.10 system and am trying it out.
I have a question.  The mutt manual says:

"To use it [i.e., mixmaster], you'll have to obey certain restrictions.
Most important, you cannot use the Cc and Bcc headers."

When I look in my /etc/mixmaster/filter.conf, it is set up with the
following defaults:

-
ALLOW

To
Cc
Bcc
Subject
In-Reply-To
References
Newsgroups
Chain
Mime-Version
Content-Type
Content-Disposition
-

So what are the restrictions on Cc: and Bcc: as it seems that mixmaster is
prepared to use (or at least pass) them?  Mostly, I'm just asking out of
curiosity.

Regards,
--
Jeff

Re: Problem with key bindings

[Jeffery Small]

The post below was supposed to go to the mutt-dev list but accidentally got
posted to mutt-users.  (Don't ask!)

Anyway, for those following along, with the help of Vincent Lefevre and
Ian Collier, the answer turned out to be that the troublesome keys were
actually defined in the xterm terminfo definition as function keys.  Once
the escape sequences in the .muttrc file were replaced with  through
, the keys were then recognized within mutt.  So the problem has been
solved.

Thanks to everyone who responded.  All the ideas were helpful in getting me
to a solution.

Regards,
--
Jeff


Jeffery Small <j...@cjsa.com> writes:

>Vincent Lefevre <vinc...@vinc17.org> writes:

>>> I wrote:
>>> However, none of the bindings or macros that have a ";" in them are working
>>> when mutt runs.

>>I have no such problem. For instance, I have:

>>bindindex,pager "\e[1;3A"   previous-unread

>>so that I can type Meta-Up to trigger this function.

>>> Outside of mutt, on the command line I can type ^V and the key and see that
>>> it is definitely issuing the proper string.

>>No, this does not guarantee to give the same string because Mutt
>>runs in app mode, and escape sequences can be different in this mode.
>>You can check with "tack". In "tack", type n f n then try your keys.

>>For instance, on the commande line (or in cooked mode), the left arrow
>>yields ^[[D, but in app mode (e.g. in tack), it yields ^[OD.

>I installed tack(1).  When pressing the keypad keys I get (for example):

>^[[20;2~(kf21)
>^[[1;5P (kf25)

>as well as the expected result for all other keys.  All of these keys with
>';' in them work without problem in every other program I use, such as
>vim(1) and my nn(1) news reader.

>>> All key assignments without a ';' in them work fine and all that
>>> include a ';' fail.

>>You can try to type the individual keys like Esc [ 2 0 ; 2 ~ to
>>see if these key assignments actually work. If they work, then this
>>is because the special key does not give the sequence you expect.

>I tried this for quite some time with different key combinations.  It
>almost always fails with mutt reporting:  "Key is not bound.  Press '?' for
>help."

>However, every once in a while, these manually entered sequences DO work!
>They might work two or three times in a row and then stop working again.  I
>have tested over and over and I cannot find any sequence of actions that
>will reproduce the condition where they start or stop working.  I have
>never yet seen a case where the actual keypad key worked.

>Remember that mutt is reporting that these sequences are properly defined
>in its internal tables.

>Does any of this shed additional light on what might be wrong.  I'm
>perplexed by the fact that the manual entry very occasionally works.  This
>seems very odd.

>>-- 
>>Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
>>100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
>>Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: Problem with key bindings

[Jeffery Small]

Vincent Lefevre  writes:

>> I wrote:
>> However, none of the bindings or macros that have a ";" in them are working
>> when mutt runs.

>I have no such problem. For instance, I have:

>bindindex,pager "\e[1;3A"   previous-unread

>so that I can type Meta-Up to trigger this function.

>> Outside of mutt, on the command line I can type ^V and the key and see that
>> it is definitely issuing the proper string.

>No, this does not guarantee to give the same string because Mutt
>runs in app mode, and escape sequences can be different in this mode.
>You can check with "tack". In "tack", type n f n then try your keys.

>For instance, on the commande line (or in cooked mode), the left arrow
>yields ^[[D, but in app mode (e.g. in tack), it yields ^[OD.

I installed tack(1).  When pressing the keypad keys I get (for example):

^[[20;2~(kf21)
^[[1;5P (kf25)

as well as the expected result for all other keys.  All of these keys with
';' in them work without problem in every other program I use, such as
vim(1) and my nn(1) news reader.

>> All key assignments without a ';' in them work fine and all that
>> include a ';' fail.

>You can try to type the individual keys like Esc [ 2 0 ; 2 ~ to
>see if these key assignments actually work. If they work, then this
>is because the special key does not give the sequence you expect.

I tried this for quite some time with different key combinations.  It
almost always fails with mutt reporting:  "Key is not bound.  Press '?' for
help."

However, every once in a while, these manually entered sequences DO work!
They might work two or three times in a row and then stop working again.  I
have tested over and over and I cannot find any sequence of actions that
will reproduce the condition where they start or stop working.  I have
never yet seen a case where the actual keypad key worked.

Remember that mutt is reporting that these sequences are properly defined
in its internal tables.

Does any of this shed additional light on what might be wrong.  I'm
perplexed by the fact that the manual entry very occasionally works.  This
seems very odd.

>-- 
>Vincent Lefèvre  - Web: 
>100% accessible validated (X)HTML - Blog: 
>Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Bind and Macro problem

[Jeffery Small]

OS: Xubuntu 15.10
mutt:   1.5.23 

I have been running mutt on a Solaris system for years.  I am now
transitioning to a Ubuntu machine.  I am using the same Sun Type 6 keyboard
on moth machines, however, on the new system these are some escape
sequences issued by keys that include a semicolon which did not occur on
the Sun system.  Here is an example:

Keypad 5 Key:^[[20;2~

In the .muttrc file, these sequences cannot be unquoted so I have entries
like:

bind generic   "[20;2~"select-entry
bind attach"[20;2~"view-attach

However, none of the bindings or macros that have ";" in them are defined
when mutt runs.

I have tried various alternatives in the .muttrc file such as:

[20\;2~

and

"^[[20;2~"

but nothing works.  Furthermore, when I am in mutt and hit "?", the bindings
escape sequences are properly shown in the list!

I'm running mutt in an xfce4-terminal but I get the same results when I
use an xterm.

What is the trick for getting these escape sequences recognized?

Regards,
--
Jeff Small

Embedding a photograph within an email message (not attaching)

[Jeffery Small]

Is there any convenient way to craft an email message using mutt that
embeds a jpeg image within the body of the message for those reading
with an HTML mail program, while still attaching it for others who use a
text-based reader like mutt?

I assume that this would require somehow formatting a message with text and
HTML parts, but I'm unclear how to formally do this within mutt when using
the vim editor.

Thanks for any pointers you can offer.
--
Jeff

Re: Embedding a photograph within an email message (not attaching)

[Jeffery Small]

m...@raf.org writes:

Jeffery Small wrote:

 Is there any convenient way to craft an email message using mutt that
 embeds a jpeg image within the body of the message for those reading
 with an HTML mail program, while still attaching it for others who use a
 text-based reader like mutt?

raf wrote:

you don't need to resort to html parts. you just need to make sure that
the content disposition of the image attachment is inline rather than
attachment. to do this, after attaching the image file, while viewing
the list of parts before sending the message, use the arrow keys if
necessary to navigate to the image attachment and press Ctrl-D which
toggles the disposition between inline and attachment. each time you press
Ctrl-D, the first character on the left hand side toggle between A and
I to indicate the disposition.

cheers,
raf

raf:

Thanks for the great reply.  I did not realize that this could be done in
mutt!  However, I tried this out and it did not work.  I composed a message
and then attached a jpeg file which was listed in the compose menu as:

-- Attachments  
- I   1 /tmp/mutt-cjsa2-102-11172-13795190124143   [text/plain, 7bit, 0.1K] 
  A   2 Image.jpg[image/jpeg, base64, 367K]

I toggled the jpeg to inline:

-- Attachments  
- I   1 /tmp/mutt-cjsa2-102-11172-13795190124143   [text/plain, 7bit, 0.1K] 
  I   2 Image.jpg[image/jpeg, base64, 367K]

And then sent the message to someone using Outlook on Windows XP.
Unfortunately, the message still appears to the recipient as a text message
with and attached jpeg file rather than displaying the image inline with
the message.  Is there something obvious that I am missing?

Regards,
--
Jeff

Re: How to automatically send jpeg files as attachments?

[Jeffery Small]

Will Yardley mutt-us...@veggiechinese.net writes:

On Sat, Dec 01, 2012 at 05:12:05AM +, Jeffery Small wrote:
 Within a script, I would like to use mutt to automatically email a JPEG
 file as an attachment without user intervention.  Is there any way to
 accomplish this?  (And if not with mutt, then possibly with mail(1) or
 mailx(?))
 
 When I try to use the -a option to mutt, it always responds: unable to
 attach file.
 
 Also, from the commandline, I don't know how to tell mutt to base64 encode
 the file.  I could encode the file manually before passing it to mutt, but
 I'm still at a loss as to how to get mutt to properly attach it to the
 message.

You shouldn't need to do any special encoding, and mutt -a should do
what you want.

What is the exact command line you're using, and what's the *full*
error? Searching for the error message you're getting briefly, it looks
like this error may come up when the -a argument is specified before the
recipient rather than after (and if that's the case, you'll notice that
the recipient address, rather than the filename, is what it can't
attach). Otherwise, it could be a permissions or file path related
problem.

Something like this should work:
% echo 'This is my body' | mutt -s 'file attached' \ 
  m...@example.com -a image001.jpg 

Whereas this gives an error:
% echo 'This is my body' | mutt -s 'file attached' -a \
   image001.jpg m...@example.com
Can't stat m...@example.com: No such file or directory
m...@example.com: unable to attach file.

Will:

Thanks so much for your quick reply.  You are exactly right, the problem was
that the -a file argument was before the address argument and it was taking
the address as a file to be attached.  I was confused by the error message
because when it gave the message (using your example):

m...@example.com: unable to attach file.

I thought the m...@example.com: part was simply identifying the recipient
and that it was complaining about the other file being unable to be
attached.  I didn't realize that this was trying to tell me that it thought
m...@example.com was a non-existent file.

I was further confused because it turns out that there is also an older 1.4
version of mutt on this machine, and when I read the manual page, I was getting
the old documentation.  This read:

mutt  [-nx] [-e cmd] [-a file] [-F file] [-H file] [-i file]
  [-s subj] [-b addr] [-c addr] addr [...]

which clearly shows the -a option before the address and with only a single
file argument.  When I corrected things and got to the proper manpage, it 
reads:

mutt [-nx] [-e cmd] [-F file] [-H file] [-i file] [-s  subj]
 [-b addr] [-c addr] [-a file [...] --] addr|mailto_url [...]

which shows the support for the multiple arguments to the -a option, which
can be terminated with -- which also works in my tests.

I'm back in business thanks to your help which is very much appreciated.

Regards,
--
Jeffery Small

How to automatically send jpeg files as attachments?

[Jeffery Small]

I'm using mutt 1.5.21 on a Solaris 10 machine.

Within a script, I would like to use mutt to automatically email a JPEG
file as an attachment without user intervention.  Is there any way to
accomplish this?  (And if not with mutt, then possibly with mail(1) or
mailx(?))

When I try to use the -a option to mutt, it always responds: unable to
attach file.

Also, from the commandline, I don't know how to tell mutt to base64 encode
the file.  I could encode the file manually before passing it to mutt, but
I'm still at a loss as to how to get mutt to properly attach it to the
message.

Thanks for any insight you can offer.

Regards,
--
Jeffery Small
jeff (at) cjsa (dot) com

Re: Problem with Fcc: saved mailbox

[Jeffery Small]

I wrote:

 However, in some circumstances while editing the original message, I
 alter the From: line to an alternative address I use with a different
 domain name.  In this situation, when I exit the text editor, mutt
apparently does not scan the hook file and simply sets Fcc: to the
default value.

Richard richard.zidli...@googlemail.com and
Gregor Zattler telegr...@gmx.net suggested:

 send2-hook is matched every time a message is changed, either
 by editing it, or by using the compose menu to change its
 recipients or subject.  send2-hook is executed after send-hook,
 and can, e.g., be used to set parameters such as the $sendmail
 variable depending on the message's sender address.

 use send2-hook.

Thank you both very much for the suggestion.  I had recently upgraded
from mutt version 1.4 and was not even aware of this variable.

I have looked over the manual and I am still confused as to how to use
send2-hook in this case.  When I edit my message and change the From:
line while leaving the To: line alone, I do not understand why mutt is
then failing to set the appropriate Fcc: box based upon the fcc-save-hook
entries in my hook file.  Why does mutt care if the From: line is altered
since the fcc-save-hook should be matching on the To: line?  In my
hook file I have hundreds of fcc-save-hook patterns for different email
addresses and I don't actually see how I would use send2-hook to address
this problem because it seems like I would need a send2-hook entry for
every pattern, and I don't know what command I would execute anyway
in order to get the hook file reread.

However, after looking through an updated version of the manual, I did
notice the alternates command and gave that a try.  I set it to a list of
all the addresses I am using and then tested out mutt doing the procedure I
described above, and that seems to take care of the problem!  I'm still not
clear why changing the From: line confuses mutt, but I guess, after editing
the message, mutt no longer remembers who I am, so it no longer knew where
to look for the appropriate config and hook files until I informed it of
my identity with the alternates command.  Please feel free to clarify my
understanding of this if I am wrong.

Thanks again.
--
Jeffery Small

Problem with Fcc: saved mailbox

[Jeffery Small]

When composing a normal message in mutt (1.5.21), after exiting the text
editor and returning to the header/attachment page prior to sending,
the Fcc: box is properly set based upon value in the hook file for the
recipient.

However, in some circumstances while editing the original message, I alter
the From: line to an alternative address I use with a different domain
name.  In this situation, when I exit the text editor, mutt apparently does
not scan the hook file and simply sets Fcc: to the default value.

What can I do in the configuration file to force mutt to set the proper
Fcc: regardless of which From: address I am using?

Thanks for any insights.
--
Jeffery Small

Re: Problem with mutt and mailbox changes

[Jeffery Small]

Erik Christiansen dva...@internode.on.net wrote about open ticket items
related to the new mail reporting bug:

Erik:

Thanks for the information.  It looks like this is a similar problem.  I
hope that this can get addressed soon as it is a real hassle, and I cannot
go back to mutt 1.4 because there is a serious 256-character buffering
problem with the earlier version that is constantly truncating saved mail
and attachments.  This has been fixed in 1.5.

Regards,
--
Jeff Small

Re: Problem with mutt and mailbox changes

[Jeffery Small]

On Sun, Aug 08, 2010 at 04:27:53AM +, I wrote:

 I have been using mutt 1.4.2.1i for quite some time on my Solaris 10 system
 with the Gnome desktop manager.  Gnome has an inbox monitor program that
 was working perfectly with mutt 1.4.  It would indicate new mail, and when
 I double-clicked on the monitor icon, it would launch mutt in a pop-up
 xterm window and immediately stop indicating new mail.  I would read and
 process my mail and exit mutt without any problems.

 I just switched to mutt 1.5.20 which is working fine, except that I now
 have a strange new problem with the Gnome mail monitor.  When it indicates
 new mail I double-click on the icon and it launches the new version of mutt
 just fine and stops indicating new mail.  However, if I do anything that
 changes the inbox file, such as deleting a message, then the Gnome mail
 monitor sees this change and begins indicating that there is new mail, when
 in fact, there is none.  This happens whether mutt is still running or has
 been exited.

 I can understand that the monitor is seeing an update on the inbox file
 timestamp due to the content changing, but my question is why didn't this
 ever happen with mutt version 1.4.2.1i?  What was the old version doing that
 the new one is not?  I'm using pretty much the same config file settings.

Charles Jie ch...@keya.com.tw wrote:

Thank you for your question and hints. I have seen similar problem with
mutt 1.5.20 since half an year ago. (And reported it the other day)

You said: if I do anything that changes the inbox file, such as
deleting a message, then the Gnome mail monitor sees this change and
begins indicating that there is new mail. This is a good discovery. It
looks that mutt 1.5.20 forgets to clear or set something which would
avoid the mail monitor or mutt itself think there is new mail.

(I've rewound my mutt back to 1.5.18, which runs perfectly.) Would you
please check the file status of the mailbox with the 'stat' command?

This is my test on mbox.mutt with mutt 1.5.18:

(1) Before I leave the mail box 'mbox.mutt':
[23:45:20] $ stat mbox.mutt
  File: `mbox.mutt'
  Size: 38403  Blocks: 80 IO Block: 4096   regular file
Device: 805h/2053d Inode: 687405  Links: 1
Access: (0600/-rw---)  Uid: (  500/ jie)   Gid: (  500/ jie)
Access: 2010-08-08 23:45:10.0 +0800
Modify: 2010-08-08 23:35:02.0 +0800
Change: 2010-08-08 23:35:02.0 +0800

(2) After I left the 'mbox.mutt':
[23:46:36] $ stat mbox.mutt
  File: `mbox.mutt'
  Size: 13651  Blocks: 32 IO Block: 4096   regular file
Device: 805h/2053d Inode: 687405  Links: 1
Access: (0600/-rw---)  Uid: (  500/ jie)   Gid: (  500/ jie)
Access: 2010-08-08 23:45:10.0 +0800
Modify: 2010-08-08 23:35:02.0 +0800
Change: 2010-08-08 23:46:47.0 +0800

Note: The time of 'Change' is updated to newer than the time of 'Acesss'.
  (Because I deleted a message in it.)

Please help check if your mutt 1.5.20 does the same thing or not.
(You need to delete a message in it.)

I do not have stat(1) on Solaris 10, but used the various flags to ls(1) to
extract the time info.  When I open the /var/mail file using mutt 1.5.20,
the timestamps are:

Access: 2010-08-08 11:29:52.572974000 -0700
Modify: 2010-08-08 11:28:44.0 -0700
Change: 2010-08-08 11:29:52.568102000 -0700

I then delete a message and close mutt and the time stamps are:

Access: 2010-08-08 11:30:11.512795000 -0700
Modify: 2010-08-08 11:30:11.512869000 -0700
Change: 2010-08-08 11:30:11.512869000 -0700

So the question is should mutt be updating the access time every time it makes
a change to the spool file?  What has changed in this regard from 1.4 to 1.5?

Can any of the developers comment on this issue?  Thanks.

Regards,
--
Jeff

Problem with mutt and mailbox changes

[Jeffery Small]

I have been using mutt 1.4.2.1i for quite some time on my Solaris 10 system
with the Gnome desktop manager.  Gnome has an inbox monitor program that
was working perfectly with mutt 1.4.  It would indicate new mail, and when
I double-clicked on the monitor icon, it would launch mutt in a pop-up
xterm window and immediately stop indicating new mail.  I would read and
process my mail and exit mutt without any problems.

I just switched to mutt 1.5.20 which is working fine, except that I now
have a strange new problem with the Gnome mail monitor.  When it indicates
new mail I double-click on the icon and it launches the new version of mutt
just fine and stops indicating new mail.  However, if I do anything that
changes the inbox file, such as deleting a message, then the Gnome mail
monitor sees this change and begins indicating that there is new mail, when
in fact, there is none.  This happens whether mutt is still running or has
been exited.

I can understand that the monitor is seeing an update on the inbox file
timestamp due to the content changing, but my question is why didn't this
ever happen with mutt version 1.4.2.1i?  What was the old version doing that
the new one is not?  I'm using pretty much the same config file settings.

Thanks for any insights.

Regards,
--
Jeffery Small

Enhance mutt to recognize window resizing

[Jeffery Small]

Has there ever been any discussion regarding this issue?  Other programs,
such as the vim editor, can deal with the terminal window being resized
while the program is running, but mutt is unforgiving.  Mutt recognizes
the terminal size when started, but if you stretch or shorten the terminal
height or width during a running session, then the display can get totally
screwed up.  Couldn't mutt be made to respond to these size changes the
same way vim does?  It would make the program much more flexible.

Regards,
--
Jeff

Re: Enhance mutt to recognize window resizing

[Jeffery Small]

Anders Rayner-Karlsson and...@trudheim.co.uk writes:

* Jeffery Small j...@cjsa.com [20090401 09:15]:
 Has there ever been any discussion regarding this issue?  Other programs,
 such as the vim editor, can deal with the terminal window being resized
 while the program is running, but mutt is unforgiving.  Mutt recognizes
 the terminal size when started, but if you stretch or shorten the terminal
 height or width during a running session, then the display can get totally
 screwed up.  Couldn't mutt be made to respond to these size changes the
 same way vim does?  It would make the program much more flexible.

I don't know what version of mutt you are using, but the 1.5 branch
have handled this for as long as I can remember using it. It could be
dependent on your OS version, terminal program or factors outside of
mutt's control.

Ah yes, you are correct.  I'm still using version 1.4.2.1i because all
later versions have serious keyboard mapping problems on my Sun Solaris 10
SPARC system.  I'm sure that it is related to ncurses and that there is
probably some solution for the problems I have, but I now remember spending
a huge amount of time trying to get my macros assigned to the function and
keypad keys to work under 1.5 and finally gave up and went back to 1.4.  It
has been so long that I have been living with 1.4 that I forgot that I was 
using the old version.  Thanks for setting me straight and I'm sorry for
bringing up an old subject like this.

Regards,
--
Jeff

Two questions

[Jeffery Small]

I'm using mutt version 1.2i on a Solaris 7 platform with Sendmail 8.9.3
and have the following two questions:

1:  When I compose a new message or reply, the message header in my editor
has the following line:

From: Jeffery Small jeff@

Notice the missing domain portion of the address.  When the message is
mailed the line ends up reading:

From: Jeffery Small 

This is new behavior in this recent version of mutt.  Is this a change
that was made as some form of anti-spam measure?  Is there a variable I
can set to restore the proper behavior of inserting the correct address
on the From: line?



2:  I mentioned this once before but never got a reply.  In most cases,
I can use either TAB or SPACE for filename completion.  However,
when I 'c'hange to a new mailbox, the TAB key works but the SPACE
key will not perform filename completion.  Do other people observe
this behavior?  If not, is there some variable that controls this
behavior?


Thanks for your responses.

Regards,
-- 
Jeff

C. Jeffery Small   ArchitectCJSA LLC (206) 232-3338
[EMAIL PROTECTED]   7000 E Mercer Way, Mercer Island, WA  98040

group reply problem

[Jeffery Small]

I posted this a week or so ago and got no response, so I thought I would
try again with a different (and hopefully more appropriate) subject line.

I am using mutt 1.0i and am have a problem with group reply.  In my .muttrc
file I have remapped the g and ^G keys as follows:

bind  generic   "g" first-entry
bind  attach"g" first-entry
bind  index "g" first-entry
bind  pager "g" top

bind  index "\cg"   group-reply
bind  pager "\cg"   group-reply

When I am in the index or pager and type ? it reports:

^G  group-replyreply to all recipients

However, when I type ^G nothing happens.  I am running mutt in an xterm
window on a Sun/Solaris7/OpenWindows platform.

Does anyone have a suggestion as to what might be wrong?

Thanks.
-- 
Jeff

C. Jeffery Small   ArchitectCJSA LLC (206) 232-3338
[EMAIL PROTECTED]   7000 E Mercer Way, Mercer Island, WA  98040