Re: sending an email with a mutt one-line without being prompted
On Mon, Aug 09, 2010 at 06:18:04PM -0500, David Champion wrote:
> If we're actually going to revisit this in -dev, I'll reiterate my
> suggestion from back then:
>
> mutt -a { *.jpg } $RECIPIENT
>
> I don't think that needing to attach files named '{' or '}' from the
> command line is a very common problem. But I also don't think that
> what we have is such a problem that it must be changed, so long as it's
> properly documented in usage and the manual.
And while I'm not entering the delimiter debate I just wanted to point
out something I recently discovered:
mutt -s 'subject' w...@foo.com -a *.jpg < /tmp/msg
(no delimiter necessary).
--
Will Fiveash
Re: sending an email with a mutt one-line without being prompted
* On 09 Aug 2010, Derek Martin wrote:
>
> $ mutt [...] -a "`echo *|tr ' ' \"$DELIMITER\""` $RECIPIENT
>
> or something of the sort. Of course, then you have either the
> spaces-in-filenames problem, or the delimiter-in-filenames problem.
> Or both.
If we're actually going to revisit this in -dev, I'll reiterate my
suggestion from back then:
mutt -a { *.jpg } $RECIPIENT
I don't think that needing to attach files named '{' or '}' from the
command line is a very common problem. But I also don't think that
what we have is such a problem that it must be changed, so long as it's
properly documented in usage and the manual.
--
-D.d...@uchicago.eduIT ServicesUniversity of Chicago
Re: sending an email with a mutt one-line without being prompted
On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
> On 2010-08-02, Nicolas Williams wrote:
>
> > Right. There's no good convention for "end of list of arguments to an
> > option". There's only a good convention for "end of variable argument
> > list" ('--'), and since this is the closest thing...
>
> And since there _is_ a convention that '--' ends the option list, it's
> A Bad Thing(TM) to use it for something else. I think violating the
> almost universal convention about what '--' means is a terrible idea,
> but apparently we're now stuck with it.
It's not just an "almost universal convention" ... it's actually a
POSIX standard. I never liked the idea when it was proposed, but
wasn't aware that it was a standard at that time. A better way to
handle this is to allow mutt to accept a delimiter-separated list of
filenames, so you can do stuff like:
$ mutt [...] -a "`echo *|tr ' ' \"$DELIMITER\""` $RECIPIENT
or something of the sort. Of course, then you have either the
spaces-in-filenames problem, or the delimiter-in-filenames problem.
Or both.
> The standard way to pass a list of filenames on a command line is to
> do it indirectly by putting the filenames in a file, and passing that
> filename. That seems to work fine for dozens (or hundreds) of other
> programs, so I don't see any reason why mutt shouldn't follow that
> convention.
Or that. Seems fine to me, though it's definitely less convenient if
you want to attach, say, *.jpg to your message. Adds a couple of
steps.
--
Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02
-=-=-=-=-
This message is posted from an invalid address. Replying to it will result in
undeliverable mail due to spam prevention. Sorry for the inconvenience.
pgpe3XeOYiTnh.pgp
Description: PGP signature
Re: sending an email with a mutt one-line without being prompted
On Tue, Aug 03, 2010 at 12:45:12PM -0500, David Champion wrote:
> * On 03 Aug 2010, Nicolas Williams wrote:
> > On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
> > > On 2010-08-02, Nicolas Williams wrote:
> > >
> > > > Right. There's no good convention for "end of list of arguments to an
> > > > option". There's only a good convention for "end of variable argument
> > > > list" ('--'), and since this is the closest thing...
> > >
> > > And since there _is_ a convention that '--' ends the option list, it's
> > > A Bad Thing(TM) to use it for something else. I think violating the
> > > almost universal convention about what '--' means is a terrible idea,
> > > but apparently we're now stuck with it.
> >
> > The convention is that '--' ends the entire option list, not a list of
> > arguments to a single option. Therefore mutt clearly uses something
> > other than the existing convention.
>
> Strictly speaking, no: since mutt requires the -a option to be last,
> a '--' terminating the list of arguments to -a implicitly terminates
> the option list as well. I think this may have been part of the design
> consideration.
Ah, that is good to know. I just tried:
mutt -s 'test mail' will.five...@oracle.com -a /etc/motd /etc/motd /etc/motd <
/etc/motd
which worked. Unfortunately the mutt usage help:
Mutt 1.5.20 (2010-04-22)
usage: mutt [] [-z] [-f | -yZ]
mutt [] [-x] [-Hi ] [-s ] [-bc ] [-a
[...] --] [...]
mutt [] [-x] [-s ] [-bc ] [-a [...] --]
[...] < message
appears to indicate that the to: address arg(s) must be last.
--
Will Fiveash
Re: sending an email with a mutt one-line without being prompted
* On 03 Aug 2010, Grant Edwards wrote: > > > > Strictly speaking, no: since mutt requires the -a option to be last, > > a '--' terminating the list of arguments to -a implicitly terminates > > the option list as well. I think this may have been part of the design > > consideration. > > IMO, requiring that unrelated options be present in a certain order is also > a bad idea. What we have wouldn't have been my solution, but this solution got there first with a patch. Unless there's a patch implementing something else and a problem statement or use case to justify changing the interface (again), I think this is a solved problem from the maintenance point of view. :) We three agree that we don't *like* this syntax, but is anything operationally broken about it -- can any commonplace operation not be accomplished, or does it require a bizarre workaround? Nothing like that has been demonstrated. -- -D.d...@uchicago.eduIT ServicesUniversity of Chicago
Re: sending an email with a mutt one-line without being prompted
On 2010-08-03, David Champion wrote:
> * On 03 Aug 2010, Nicolas Williams wrote:
>> On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
>> > On 2010-08-02, Nicolas Williams wrote:
>> >
>> > > Right. There's no good convention for "end of list of arguments to an
>> > > option". There's only a good convention for "end of variable argument
>> > > list" ('--'), and since this is the closest thing...
>> >
>> > And since there _is_ a convention that '--' ends the option list, it's
>> > A Bad Thing(TM) to use it for something else. I think violating the
>> > almost universal convention about what '--' means is a terrible idea,
>> > but apparently we're now stuck with it.
>>
>> The convention is that '--' ends the entire option list, not a list of
>> arguments to a single option. Therefore mutt clearly uses something
>> other than the existing convention.
>
> Strictly speaking, no: since mutt requires the -a option to be last,
> a '--' terminating the list of arguments to -a implicitly terminates
> the option list as well. I think this may have been part of the design
> consideration.
IMO, requiring that unrelated options be present in a certain order is also
a bad idea.
--
Grant Edwards grant.b.edwardsYow! Is something VIOLENT
at going to happen to a
gmail.comGARBAGE CAN?
Re: sending an email with a mutt one-line without being prompted
On 2010-08-03, Nicolas Williams wrote:
> On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
>> On 2010-08-02, Nicolas Williams wrote:
>>
>> > Right. There's no good convention for "end of list of arguments to an
>> > option". There's only a good convention for "end of variable argument
>> > list" ('--'), and since this is the closest thing...
>>
>> And since there _is_ a convention that '--' ends the option list, it's
>> A Bad Thing(TM) to use it for something else. I think violating the
>> almost universal convention about what '--' means is a terrible idea,
>> but apparently we're now stuck with it.
>
> The convention is that '--' ends the entire option list, not a list of
> arguments to a single option.
Yes.
> Therefore mutt clearly uses something other than the existing
> convention.
I thought that's what I wrote.
--
Grant Edwards grant.b.edwardsYow! Here I am at the flea
at market but nobody is buying
gmail.commy urine sample bottles ...
Re: sending an email with a mutt one-line without being prompted
On Tue, Aug 03, 2010 at 12:45:12PM -0500, David Champion wrote:
> * On 03 Aug 2010, Nicolas Williams wrote:
> > On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
> > > On 2010-08-02, Nicolas Williams wrote:
> > >
> > > > Right. There's no good convention for "end of list of arguments to an
> > > > option". There's only a good convention for "end of variable argument
> > > > list" ('--'), and since this is the closest thing...
> > >
> > > And since there _is_ a convention that '--' ends the option list, it's
> > > A Bad Thing(TM) to use it for something else. I think violating the
> > > almost universal convention about what '--' means is a terrible idea,
> > > but apparently we're now stuck with it.
> >
> > The convention is that '--' ends the entire option list, not a list of
> > arguments to a single option. Therefore mutt clearly uses something
> > other than the existing convention.
>
> Strictly speaking, no: since mutt requires the -a option to be last,
> a '--' terminating the list of arguments to -a implicitly terminates
> the option list as well. I think this may have been part of the design
> consideration.
Ah, well, if -a has to be last then you're right. (Still feels icky,
but that's just aesthetics.)
Re: sending an email with a mutt one-line without being prompted
* On 03 Aug 2010, Nicolas Williams wrote:
> On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
> > On 2010-08-02, Nicolas Williams wrote:
> >
> > > Right. There's no good convention for "end of list of arguments to an
> > > option". There's only a good convention for "end of variable argument
> > > list" ('--'), and since this is the closest thing...
> >
> > And since there _is_ a convention that '--' ends the option list, it's
> > A Bad Thing(TM) to use it for something else. I think violating the
> > almost universal convention about what '--' means is a terrible idea,
> > but apparently we're now stuck with it.
>
> The convention is that '--' ends the entire option list, not a list of
> arguments to a single option. Therefore mutt clearly uses something
> other than the existing convention.
Strictly speaking, no: since mutt requires the -a option to be last,
a '--' terminating the list of arguments to -a implicitly terminates
the option list as well. I think this may have been part of the design
consideration.
--
-D.d...@uchicago.eduIT ServicesUniversity of Chicago
Re: sending an email with a mutt one-line without being prompted
On Tue, Aug 03, 2010 at 02:00:46PM +, Grant Edwards wrote:
> On 2010-08-02, Nicolas Williams wrote:
>
> > Right. There's no good convention for "end of list of arguments to an
> > option". There's only a good convention for "end of variable argument
> > list" ('--'), and since this is the closest thing...
>
> And since there _is_ a convention that '--' ends the option list, it's
> A Bad Thing(TM) to use it for something else. I think violating the
> almost universal convention about what '--' means is a terrible idea,
> but apparently we're now stuck with it.
The convention is that '--' ends the entire option list, not a list of
arguments to a single option. Therefore mutt clearly uses something
other than the existing convention.
Nico
--
Re: sending an email with a mutt one-line without being prompted
On Tue, Aug 03, 2010 at 10:36:05AM +0200, Christoph Kukulies wrote: > -- has special meaning in some unix command lines to provide an > escape when names starting with a "-"-sign > are concerned. (doesn't getopt use it as an escape anyway? not sure). > > mkdir -- -foo > rmdir -- -foo -- means "end of option arguments". > How about > > mutt -a * \; j...@foo.bar > > ? Lots of conventions could be established, but none that getopt/getopts would know already. For example, using '' results in no ambiguity (you can have files named ';', but not files named ''). Either way, the matter is clearly closed for the time being. Nico --
Re: sending an email with a mutt one-line without being prompted
Grant Edwards wrote:
> Nicolas Williams wrote:
> > Right. There's no good convention for "end of list of arguments to an
> > option". There's only a good convention for "end of variable argument
> > list" ('--'), and since this is the closest thing...
>
> And since there _is_ a convention that '--' ends the option list, it's
> A Bad Thing(TM) to use it for something else. I think violating the
> almost universal convention about what '--' means is a terrible idea,
> but apparently we're now stuck with it.
Having just happened upon this myself I am now one of the many saying
that mutt has made a terrible mistake with this implementation. The
'--' is an end of option argument processing. It should not be used
as an end of list marker. It should be used as an end of argument
option marker.
> The standard way to pass a list of filenames on a command line is to
> do it indirectly by putting the filenames in a file, and passing that
> filename. That seems to work fine for dozens (or hundreds) of other
> programs, so I don't see any reason why mutt shouldn't follow that
> convention.
The problem mutt is facing is one of in-band-control. The marker
needs to not match any filename. But what if you have a file named
"--"? (Don't laugh. People do things like this. And then then ask
how to remove it. Really! ["rm -f ./--", or "rm -f -- --") It is
hard to do in-band-control well. Especially on Unix-like filesystems
where the only two invalid characters are the null character and slash.
One way is just to assume that a particular filename will never be
supported. Something like "--" but "--" is a terrible choice.
I would have preferred that "+" were chosen.
mutt -a * + j...@example.com
That seems to have a low likelihood of collision with a real filename.
It is used by 'find' and standardized by POSIX. As in this example
"find . -exec echo {} +". And so isn't completely unknown elsewhere.
But since only null and slash are invalid perhaps that is the best clue.
mutt -a * / j...@example.com
Ugly. But seems least ambiguous to me. And it avoids the in-band
control problem.
Bob
signature.asc
Description: Digital signature
Re: sending an email with a mutt one-line without being prompted
On 2010-08-02, Nicolas Williams wrote:
> Right. There's no good convention for "end of list of arguments to an
> option". There's only a good convention for "end of variable argument
> list" ('--'), and since this is the closest thing...
And since there _is_ a convention that '--' ends the option list, it's
A Bad Thing(TM) to use it for something else. I think violating the
almost universal convention about what '--' means is a terrible idea,
but apparently we're now stuck with it.
The standard way to pass a list of filenames on a command line is to
do it indirectly by putting the filenames in a file, and passing that
filename. That seems to work fine for dozens (or hundreds) of other
programs, so I don't see any reason why mutt shouldn't follow that
convention.
--
Grant Edwards grant.b.edwardsYow! Sometime in 1993
at NANCY SINATRA will lead a
gmail.comBLOODLESS COUP on GUAM!!
Re: sending an email with a mutt one-line without being prompted
Am 02.08.2010 23:13, schrieb Will Fiveash: On Mon, Aug 02, 2010 at 03:49:47PM -0500, Nicolas Williams wrote: On Sun, Aug 01, 2010 at 10:52:01PM -0500, David Champion wrote: Syntax has been changed: -a indicates a *list* of attachment files ending with "--". I don't recall which version was first to boast this new syntax, but it's the problem you're seeing right now even if it's not related to the problem you saw earlier. Try: mutt -s test -a Bild.jpg -- m...@some.org I recommend against this use of '--'. It makes it harder to write wrapper scripts that parse the same arguments using getopt/ getopts, for example. Sadly, I don't have a counter-proposal, nor am I suggesting this get ripped out now. On the other hand it makes: mutt -a * -- j...@foo.bar easier which I would guess is why the change was made. You do have a point about -- being potentially problematic. Maybe -a should work like it used to (only one file per -a instance) and a new flag could take a list of files to attach from a file given as a arg (or stdin). -- has special meaning in some unix command lines to provide an escape when names starting with a "-"-sign are concerned. (doesn't getopt use it as an escape anyway? not sure). mkdir -- -foo rmdir -- -foo How about mutt -a * \; j...@foo.bar ? -- Christoph
Re: sending an email with a mutt one-line without being prompted
On Mon, Aug 02, 2010 at 04:26:47PM -0500, Nicolas Williams wrote:
> On Mon, Aug 02, 2010 at 04:13:16PM -0500, Will Fiveash wrote:
> > On Mon, Aug 02, 2010 at 03:49:47PM -0500, Nicolas Williams wrote:
> > > On Sun, Aug 01, 2010 at 10:52:01PM -0500, David Champion wrote:
> > > > Syntax has been changed: -a indicates a *list* of attachment files
> > > > ending with "--". I don't recall which version was first to boast this
> > > > new syntax, but it's the problem you're seeing right now even if it's
> > > > not related to the problem you saw earlier.
> > > >
> > > > Try:
> > > >
> > > > mutt -s test -a Bild.jpg -- m...@some.org > >
> > > I recommend against this use of '--'. It makes it harder to write
> > > wrapper scripts that parse the same arguments using getopt/ getopts, for
> > > example. Sadly, I don't have a counter-proposal, nor am I suggesting
> > > this get ripped out now.
> >
> > On the other hand it makes:
> >
> > mutt -a * -- j...@foo.bar
>
> Really? You do that? It's kinda like rm *...
I haven't yet but I could see if one was in a dir with images like
foo.jpg bar.jpg etc... it could be useful. I'm not saying one should
use it without caution.
> > easier which I would guess is why the change was made. You do have a
> > point about -- being potentially problematic. Maybe -a should work like
> > it used to (only one file per -a instance) and a new flag could take a
> > list of files to attach from a file given as a arg (or stdin).
>
> Right. There's no good convention for "end of list of arguments to an
> option". There's only a good convention for "end of variable argument
> list" ('--'), and since this is the closest thing...
>
> If -a was last then you could:
>
> % mutt -s some-subject -t some-to:-addres ... -a * < body.txt
>
> Oddly enough there's no -t argument. The To: address(es) has(have) to
> be last. You can't have two argument lists terminated by dint of being
> last.
Yeah, I hate positional CLI args. I'd prefer:
% ls *.jpg > /tmp/files
% mutt -s some-subject -t to:-address1,to:address2 -q /tmp/files -c cc:-address
< body.txt
--
Will Fiveash
Oracle
Austin, TX, USA
Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay.sun.com
http://opensolaris.org/os/project/kerberos/
Note my new work e-mail address: will.five...@oracle.com
Re: sending an email with a mutt one-line without being prompted
On Mon, Aug 02, 2010 at 04:13:16PM -0500, Will Fiveash wrote:
> On Mon, Aug 02, 2010 at 03:49:47PM -0500, Nicolas Williams wrote:
> > On Sun, Aug 01, 2010 at 10:52:01PM -0500, David Champion wrote:
> > > Syntax has been changed: -a indicates a *list* of attachment files
> > > ending with "--". I don't recall which version was first to boast this
> > > new syntax, but it's the problem you're seeing right now even if it's
> > > not related to the problem you saw earlier.
> > >
> > > Try:
> > >
> > > mutt -s test -a Bild.jpg -- m...@some.org >
> > I recommend against this use of '--'. It makes it harder to write
> > wrapper scripts that parse the same arguments using getopt/ getopts, for
> > example. Sadly, I don't have a counter-proposal, nor am I suggesting
> > this get ripped out now.
>
> On the other hand it makes:
>
> mutt -a * -- j...@foo.bar
Really? You do that? It's kinda like rm *...
> easier which I would guess is why the change was made. You do have a
> point about -- being potentially problematic. Maybe -a should work like
> it used to (only one file per -a instance) and a new flag could take a
> list of files to attach from a file given as a arg (or stdin).
Right. There's no good convention for "end of list of arguments to an
option". There's only a good convention for "end of variable argument
list" ('--'), and since this is the closest thing...
If -a was last then you could:
% mutt -s some-subject -t some-to:-addres ... -a * < body.txt
Oddly enough there's no -t argument. The To: address(es) has(have) to
be last. You can't have two argument lists terminated by dint of being
last.
Nico
--
Re: sending an email with a mutt one-line without being prompted
* On 02 Aug 2010, Nicolas Williams wrote: > On Sun, Aug 01, 2010 at 10:52:01PM -0500, David Champion wrote: > > Syntax has been changed: -a indicates a *list* of attachment files > > ending with "--". I don't recall which version was first to boast this > > new syntax, but it's the problem you're seeing right now even if it's > > not related to the problem you saw earlier. > > > > Try: > > > > mutt -s test -a Bild.jpg -- m...@some.org > I recommend against this use of '--'. It makes it harder to write > wrapper scripts that parse the same arguments using getopt/ getopts, for > example. Sadly, I don't have a counter-proposal, nor am I suggesting > this get ripped out now. I'm not fond of it either, but there was fairly extensive discussion when it was committed in April 2007. See mutt-users <20070320122350.ga25...@giotto.argoss.nl> and mutt-dev <20070321193650.gb2...@df7cb.de> for thread heads. I think your specific concern may be exempted by the implementation used. -- -D.d...@uchicago.eduIT ServicesUniversity of Chicago
Re: sending an email with a mutt one-line without being prompted
On Mon, Aug 02, 2010 at 03:49:47PM -0500, Nicolas Williams wrote: > On Sun, Aug 01, 2010 at 10:52:01PM -0500, David Champion wrote: > > Syntax has been changed: -a indicates a *list* of attachment files > > ending with "--". I don't recall which version was first to boast this > > new syntax, but it's the problem you're seeing right now even if it's > > not related to the problem you saw earlier. > > > > Try: > > > > mutt -s test -a Bild.jpg -- m...@some.org > I recommend against this use of '--'. It makes it harder to write > wrapper scripts that parse the same arguments using getopt/ getopts, for > example. Sadly, I don't have a counter-proposal, nor am I suggesting > this get ripped out now. On the other hand it makes: mutt -a * -- j...@foo.bar easier which I would guess is why the change was made. You do have a point about -- being potentially problematic. Maybe -a should work like it used to (only one file per -a instance) and a new flag could take a list of files to attach from a file given as a arg (or stdin). -- Will Fiveash
Re: sending an email with a mutt one-line without being prompted
On Sun, Aug 01, 2010 at 10:52:01PM -0500, David Champion wrote: > Syntax has been changed: -a indicates a *list* of attachment files > ending with "--". I don't recall which version was first to boast this > new syntax, but it's the problem you're seeing right now even if it's > not related to the problem you saw earlier. > > Try: > > mutt -s test -a Bild.jpg -- m...@some.org
Re: sending an email with a mutt one-line without being prompted
On Mon, Aug 02, 2010 at 01:34:18PM -0700, Michael Elkins wrote: > > At the end of the help output there is this: > > -- separate filename(s) and recipients, > when using -a, -- is mandatory > > I agree it would make more sense to put that nearer to the text for > the -a option. Something like: > > -a [...] -- attach file(s) to the message > the list of files must be terminated with the "--" sequence +1 -- Will Fiveash Oracle
Re: sending an email with a mutt one-line without being prompted
On Mon, Aug 02, 2010 at 12:12:27PM -0500, Will Fiveash wrote: Yep, I struggled with this change recently. It would be nice if mutt's help output for -a was updated with this important usage tidbit. Here's what it looks like now: Mutt 1.5.20 (2010-04-22) usage: mutt [] [-z] [-f | -yZ] mutt [] [-x] [-Hi ] [-s ] [-bc ] [-a [...] --] [...] mutt [] [-x] [-s ] [-bc ] [-a [...] --] [...] < message mutt [] -p mutt [] -A [...] mutt [] -Q [...] mutt [] -D mutt -v[v] options: -A expand the given alias -a attach a file to the message ^^ This should be: -a attach one or more files to the message, must be terminated with " --" BTW, I do notice now that the terse usage does indicate -- termination but I didn't look at that closely initially. At the end of the help output there is this: --separate filename(s) and recipients, when using -a, -- is mandatory I agree it would make more sense to put that nearer to the text for the -a option. Something like: -a [...] -- attach file(s) to the message the list of files must be terminated with the "--" sequence me pgpxw4bZlyAU4.pgp Description: PGP signature
Re: sending an email with a mutt one-line without being prompted
On Sun, Aug 01, 2010 at 10:52:01PM -0500, David Champion wrote: > * On 01 Aug 2010, Christoph Kukulies wrote: > > >> > > >>k...@post:~$ mutt -s test k...@validaddress.de > >>Error sending message, child exited 1 (). > > >>Segmentation fault > > >> > > >> > > >> > > >This should work. Maybe you could try to upgrade mutt to the most recent > > >version 1.5.20? > > > > > I tried it on another machine (ubuntu) and there it says > > > > k...@accms33:~$ mutt -s test -a Bild.jpg m...@some.org > Keine Empf?nger angegeben. > > Syntax has been changed: -a indicates a *list* of attachment files > ending with "--". I don't recall which version was first to boast this > new syntax, but it's the problem you're seeing right now even if it's > not related to the problem you saw earlier. > > Try: > > mutt -s test -a Bild.jpg -- m...@some.org ] [-z] [-f | -yZ] mutt [] [-x] [-Hi ] [-s ] [-bc ] [-a [...] --] [...] mutt [] [-x] [-s ] [-bc ] [-a [...] --] [...] < message mutt [] -p mutt [] -A [...] mutt [] -Q [...] mutt [] -D mutt -v[v] options: -A expand the given alias -a attach a file to the message ^^ This should be: -a attach one or more files to the message, must be terminated with " --" BTW, I do notice now that the terse usage does indicate -- termination but I didn't look at that closely initially. -- Will Fiveash
Re: sending an email with a mutt one-line without being prompted
Am 02.08.2010 10:58, schrieb Simon Ruderich: On Sun, Aug 01, 2010 at 07:31:28PM +0200, Christoph Kukulies wrote: [snip] I opened a can of worms obviously. On the target system (debian) the stock mutt-1.5.20.tgz doesn't compile because it can't find libcurses. I have libncurses5 installed. Maybe patches are required for debian? On Debian the files necessary to compile a program are provided in a separate package, called libncurses5-dev. You will need those *-dev packages for all libraries mutt depends on. But before doing this, try mutt 1.5.20 from backports.org. Thanks. I lifted my system this morning from debian 4 to debian 5 and the stock 1.3.18 (or sth.) mutt didn't show the segfault. I then installed 1.5.20 from a backport site and it was working fine. A newer package for debian (unless I compile from sources) doesn't seem to exist. Any debian experts here? I'm getting error 404 when trying to install further packages (e.g. strace) . Maybe I got to extend /etc/apt/sources.list? The only thing you need in there should be something like this (if you use Debian Lenny): deb http://ftp.de.debian.org/debian/ lenny main As mentioned above, I was still having edge and moved to lenny this morning. -- Christoph
Re: sending an email with a mutt one-line without being prompted
On Sun, Aug 01, 2010 at 07:31:28PM +0200, Christoph Kukulies wrote: > [snip] > > I opened a can of worms obviously. On the target system (debian) the > stock mutt-1.5.20.tgz doesn't compile because > it can't find libcurses. I have libncurses5 installed. Maybe patches > are required for debian? On Debian the files necessary to compile a program are provided in a separate package, called libncurses5-dev. You will need those *-dev packages for all libraries mutt depends on. But before doing this, try mutt 1.5.20 from backports.org. > A newer package for debian (unless I compile from sources) doesn't > seem to exist. > > Any debian experts here? I'm getting error 404 when trying to > install further packages (e.g. strace) . Maybe I got to extend > /etc/apt/sources.list? The only thing you need in there should be something like this (if you use Debian Lenny): deb http://ftp.de.debian.org/debian/ lenny main > Christoph Hope this helps, Simon -- + privacy is necessary + using gnupg http://gnupg.org + public key id: 0x92FEFDB7E44C32F9 pgppmdctTW30h.pgp Description: PGP signature
Re: sending an email with a mutt one-line without being prompted
* On 01 Aug 2010, Christoph Kukulies wrote: > >> > >>k...@post:~$ mutt -s test k...@validaddress.de >>Error sending message, child exited 1 (). > >>Segmentation fault > >> > >> > >> > >This should work. Maybe you could try to upgrade mutt to the most recent > >version 1.5.20? > > > I tried it on another machine (ubuntu) and there it says > > k...@accms33:~$ mutt -s test -a Bild.jpg m...@some.org Keine Empf?nger angegeben. Syntax has been changed: -a indicates a *list* of attachment files ending with "--". I don't recall which version was first to boast this new syntax, but it's the problem you're seeing right now even if it's not related to the problem you saw earlier. Try: mutt -s test -a Bild.jpg -- m...@some.org
Re: sending an email with a mutt one-line without being prompted
Am 01.08.2010 19:10, schrieb rog...@sdf.org:
On Sun, Aug 01, 2010 at 06:33:35PM +0200, Christoph Kukulies wrote:
Am 01.08.2010 18:13, schrieb Jostein Berntsen:
On 01.08.10,18:05, Christoph Kukulies wrote:
I'm trying
mutt -i message.text -s subject -a attachment.jpg recipi...@domain
Is there a way to do that without being prompted?
You can try:
mutt -s subject -a attachment.jpg recipi...@domain< message.text
Jostein
Surprise:
k...@post:~$ mutt -s test k...@validaddress.de
mutt -d5
And, since it's a segfault, might also try strace of "mutt -d5" doesn't show
any of much use.
cat body.txt | mutt -s "${HOSTNAME}: Subject" b...@me.com
... works for me here.
No difference with me here whether through pipe or stdin redirect.
I opened a can of worms obviously. On the target system (debian) the
stock mutt-1.5.20.tgz doesn't compile because
it can't find libcurses. I have libncurses5 installed. Maybe patches are
required for debian?
A newer package for debian (unless I compile from sources) doesn't seem
to exist.
Any debian experts here? I'm getting error 404 when trying to install
further packages (e.g. strace) . Maybe I got to extend
/etc/apt/sources.list?
--
Christoph
Re: sending an email with a mutt one-line without being prompted
Am 01.08.2010 18:49, schrieb Jostein Berntsen: On 01.08.10,18:33, Christoph Kukulies wrote: Am 01.08.2010 18:13, schrieb Jostein Berntsen: On 01.08.10,18:05, Christoph Kukulies wrote: I'm trying mutt -i message.text -s subject -a attachment.jpg recipi...@domain Is there a way to do that without being prompted? You can try: mutt -s subject -a attachment.jpg recipi...@domain< message.text Jostein Surprise: k...@post:~$ mutt -s test k...@validaddress.de This should work. Maybe you could try to upgrade mutt to the most recent version 1.5.20? I tried it on another machine (ubuntu) and there it says k...@accms33:~$ mutt -s test -a Bild.jpg m...@some.org -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK -USE_POP -USE_IMAP -USE_SMTP -USE_SSL_OPENSSL -USE_SSL_GNUTLS -USE_SASL -USE_GSS -HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID -USE_HCACHE ISPELL="/usr/bin/ispell" SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/local/share/mutt" SYSCONFDIR="/usr/local/etc" EXECSHELL="/bin/sh" -MIXMASTER Um die Entwickler zu kontaktieren, schicken Sie bitte eine Nachricht (in englisch) an . Um einen Bug zu melden, besuchen Sie bitte http://bugs.mutt.org/.
Re: sending an email with a mutt one-line without being prompted
On Sun, Aug 01, 2010 at 06:33:35PM +0200, Christoph Kukulies wrote:
>Am 01.08.2010 18:13, schrieb Jostein Berntsen:
>> On 01.08.10,18:05, Christoph Kukulies wrote:
>>
>>> I'm trying
>>>
>>> mutt -i message.text -s subject -a attachment.jpg recipi...@domain
>>>
>>> Is there a way to do that without being prompted?
>>>
>>>
>> You can try:
>>
>> mutt -s subject -a attachment.jpg recipi...@domain< message.text
>>
>>
>> Jostein
>>
>>
>>
>
>
>Surprise:
>
>k...@post:~$ mutt -s test k...@validaddress.de Error sending message, child exited 1 ().
>Segmentation fault
mutt -d5
And, since it's a segfault, might also try strace of "mutt -d5" doesn't show
any of much use.
cat body.txt | mutt -s "${HOSTNAME}: Subject" b...@me.com
... works for me here.
--
Roger
http://rogerx.freeshell.org/
Re: sending an email with a mutt one-line without being prompted
On 01.08.10,18:33, Christoph Kukulies wrote: > Am 01.08.2010 18:13, schrieb Jostein Berntsen: > >On 01.08.10,18:05, Christoph Kukulies wrote: > >>I'm trying > >> > >>mutt -i message.text -s subject -a attachment.jpg recipi...@domain > >> > >>Is there a way to do that without being prompted? > >> > >You can try: > > > >mutt -s subject -a attachment.jpg recipi...@domain< message.text > > > > > >Jostein > > > > > > > Surprise: > > k...@post:~$ mutt -s test k...@validaddress.de Error sending message, child exited 1 (). > Segmentation fault > > > This should work. Maybe you could try to upgrade mutt to the most recent version 1.5.20? Jostein
Re: sending an email with a mutt one-line without being prompted
Am 01.08.2010 18:13, schrieb Jostein Berntsen: On 01.08.10,18:05, Christoph Kukulies wrote: I'm trying mutt -i message.text -s subject -a attachment.jpg recipi...@domain Is there a way to do that without being prompted? You can try: mutt -s subject -a attachment.jpg recipi...@domain< message.text Jostein Surprise: k...@post:~$ mutt -s test k...@validaddress.de System: Linux 2.6.18-6-486 (i686) [using ncurses 5.5] [using libidn 0.6.5 (compiled with 0.6.5)] Compile options: -DOMAIN +DEBUG -HOMESPOOL +USE_SETGID +USE_DOTLOCK +DL_STANDALONE +USE_FCNTL -USE_FLOCK +USE_INODESORT +USE_POP +USE_IMAP -USE_GSS -USE_SSL_OPENSSL +USE_SSL_GNUTLS +USE_SASL +HAVE_GETADDRINFO +HAVE_REGCOMP -USE_GNU_REGEX +HAVE_COLOR +HAVE_START_COLOR +HAVE_TYPEAHEAD +HAVE_BKGDSET +HAVE_CURS_SET +HAVE_META +HAVE_RESIZETERM +CRYPT_BACKEND_CLASSIC_PGP +CRYPT_BACKEND_CLASSIC_SMIME -CRYPT_BACKEND_GPGME -BUFFY_SIZE -EXACT_ADDRESS -SUN_ATTACHMENT +ENABLE_NLS -LOCALES_HACK +COMPRESSED +HAVE_WC_FUNCS +HAVE_LANGINFO_CODESET +HAVE_LANGINFO_YESEXPR +HAVE_ICONV -ICONV_NONTRANS +HAVE_LIBIDN +HAVE_GETSID +USE_HCACHE -ISPELL SENDMAIL="/usr/sbin/sendmail" MAILPATH="/var/mail" PKGDATADIR="/usr/share/mutt" SYSCONFDIR="/etc" EXECSHELL="/bin/sh" MIXMASTER="mixmaster" To contact the developers, please mail to . To report a bug, please visit http://bugs.mutt.org/. patch-1.5.11.rr.compressed.1 patch-1.5.4.vk.pgp_verbose_mime patch-1.5.5.1.nt.xtitles.3.ab.1 patch-1.5.6.dw.maildir-mtime.1 patch-1.5.6.tt.assumed_charset.1
Re: sending an email with a mutt one-line without being prompted
On 01.08.10,18:05, Christoph Kukulies wrote: > I'm trying > > mutt -i message.text -s subject -a attachment.jpg recipi...@domain > > Is there a way to do that without being prompted? > You can try: mutt -s subject -a attachment.jpg recipi...@domain < message.text Jostein
