Bug 103396 - mutt fails to launch editor
mutt fails to launch editor
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: mutt (Show other bugs)
9
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-29 14:41 EDT by Everett Lipman
Modified: 2014-03-16 22:38 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-08-29 17:26:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Everett Lipman 2003-08-29 14:41:42 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225

Description of problem:
mutt omits the editor name in the argument to
execve() after I hit 'e'.

Version-Release number of selected component (if applicable):
mutt-1.4.1-1

How reproducible:
Always

Steps to Reproduce:
1.Type small message in mailx mode.
2.Type <Enter>.<Enter> to get send confirmation screen.
3.Type 'e'
4.Quit and look at error messages from stdout.  You will
  get "permission denied."
    

Actual Results:  from strace:

11011 execve("/bin/sh", ["sh", "-c", " \'/tmp/mutt-elo-11006-1\'"], [/* 24 vars
*/]) = 0

Expected Results:  from strace of working version of mutt 1.4i:

25871 execve("/bin/sh", ["sh", "-c", "vi \'/tmp/mutt-sphere-25869-1\'"], [/* 23
vars */]) = 0


Additional info:

.muttrc was identical for the two runs above.
Adding 'set editor="vi"' to .muttrc made no
difference.
~v and ~e both work fine (!) in mailx mode.
Comment 1 Bill Nottingham 2003-08-29 14:46:13 EDT
Can you attach your .muttrc?
Comment 2 Everett Lipman 2003-08-29 16:34:57 EDT
Created attachment 94077


file names have been changed
Comment 3 Everett Lipman 2003-08-29 16:38:15 EDT
Comment on attachment 94077


set folder=~/somedir
set record=~/somedir/somefile
set postponed=~/somedir/anotherfile
set sendmail=/home/user/myscript
set ispell="/usr/bin/aspell --mode=email check"
set index_format="%4C %Z %{%d%b%y %H:%M:%S %Z} %-15.15L (%4l) %s"
set sort=mailbox-order
set simple_search="~B %s"
set pager_context=1
set print_command="enscript -T3"
set edit_headers autoedit fast_reply menu_scroll postpone
unset editor user_agent use_from move abort_nosubject confirmappend include

bind pager N search-opposite
bind pager b previous-page
bind index b previous-page
bind index G last-entry
bind index 0 first-entry
bind index N search-opposite
bind attach r exit

exec last-entry

ignore received content- mime-version message-id return-path status
ignore in-reply-to references list- lines

color hdrdefault red default
color quoted brightblue default
color signature red default
color indicator brightyellow red
color error brightred default
color status yellow blue
color tree magenta default	# the thread tree in the index menu
color tilde magenta default
color message brightcyan default
color markers brightcyan default
color attachment brightmagenta default
color search default green	# how to hilite search patterns in the pager
color header cyan default ^(From|Subject):
color body magenta default "(ftp|http)://[^ ]+" # point out URLs
color body magenta default [-a-z_0-9.]+@[-a-z_0-9.]+	# e-mail addresses
color underline brightgreen default
Comment 4 Bill Nottingham 2003-08-29 16:54:21 EDT
OK, I'm missing something obvious... without having sendmail point at the
nonexistent script referenced above, I don't even get to the edit menu.
Comment 5 Everett Lipman 2003-08-29 17:13:13 EDT
Detailed description of what I do:

1. mutt -nz address

   I am prompted for a subject, I type "foo" and hit <Enter>.

2. Type a line of text and again hit <Enter>.

3. Type "."

4. Type <Enter>

   At this point I am in the menu screen, and if I type "y",
   the message will be sent.

5. Type "e"

   Screen flashes, and it is at this point that the execve()
   is attempted and the following error

   sh: line 1: /tmp/mutt-elo-25292-1: Permission denied

   is generated because the "vi" is left out of the execve() command
   string.

All of this happens before the message is ever sent, so I don't
think the fact that I use a funny script as my sendmail should
have any effect.  I used an identical setup under mutt 1.4i
and never had this problem.

BTW, in my environment,

EDITOR=vi
VISUAL=vi

From the muttrc man page:
editor
              Type: path
              Default: ""

              This  variable  specifies  which  editor  is  used  by mutt.  It
              defaults to the value of  the  VISUAL,  or  EDITOR,  environment
              variable, or to the string "vi" if neither of those are set.

The problem still occurs if EDITOR and VISUAL are unset.

   
Comment 6 Bill Nottingham 2003-08-29 17:24:15 EDT
Ah, you said mailx mode before, which implies -x, which does not prompt.
Comment 7 Bill Nottingham 2003-08-29 17:26:42 EDT
This is a general consequence of 'unset editor'. This unsets any value of
editor, including the default inherited ones.
Comment 8 Everett Lipman 2003-08-29 23:18:46 EDT
Sorry for the confusion about mailx mode; I did not specify
-x on the command line, but the "unset editor" command results
in mutt starting in mailx mode with the important difference that
the "." does not send the message, but rather puts you in the
mutt menu where you can attach files if you wish.

As far as whether or not this is a bug, I have a few comments:

1) I don't know of another way to have a default behavior
   that doesn't require an editor and still allows attachments.

2) This configuration worked flawlessly under version 1.4.

3) I still think it is a bug for mutt to try to have sh
   execute the temporary file holding the email message.  The old
   behavior was more rational, and the new behavior could have unpleasant
   consequences.  If the present version is doing what was intended,
   it should give an error message such as "No editor specified" rather
   than calling execve() with the message as the argument.

Note You need to log in before you can comment on or make changes to this bug.