Re: majordomo [Was: Send to a Listing]
On Mon, Apr 22, 2019 at 02:34:24PM -0500, Derek Martin wrote: > On Wed, Apr 17, 2019 at 09:53:58AM +1000, m...@raf.org wrote: > > if you want majordomo, i can send a copy but it's available at: > > > > ftp://ftp.icm.edu.pl/packages/majordomo/Welcome.html > > > > note that it's at least 18 years old and unsupported (but still works). > > it might be a better idea to use mailman. > > The whole point of suggesting majordomo is that (IIRC) it keeps the > recipients in a plain-text file, one address per line, making it > trivial to replace them by dropping in a file that had them in that > format in place of the existing file. You can't do that with mailman > because it stores them in a db file. So in that case you'd be better > off using a script to generate a mutt aliases file, or some other > thing. Just to inform you that I suspended the work on the bash script and decided to lock myself in with Python, so I will not be available for other things for some time now. Thanks, Derek, Wim, Cameron for your input. On the other hand, maybe this (1) might be useful for the op or anyone interested in using mutt in a python wrapper script. (1) https://github.com/stevekm/mutt-py Cheers, felixs
Re: [Fwd: Re: Send to a Listing]
On Thu, Apr 18, 2019 at 09:16:55AM +1000, Cameron Simpson wrote: > On 17Apr2019 22:45, felixs wrote: > > Thanks for your detailed comments and explanations. It will need a > > second lecture with the Bash Reference Manual opened in another terminal > > to fully understand the differences. > > Or, as previously mentioned: just "man sh", not "man bash". > > _Everything_ we've discussed here is plain Bourne shell. The difficulty with > using the bash manual _as a reference_ is that its little extensions are not > distinuished from the common subset which works everywhere. You've remarked > before that you "like bash", but actually nothing you've described uses > anything not in the standard shell - you're not "liking bash", you're > "liking the shell" and thinking the cool stuff is specific to bash - it > almost always isn't. > > Writing portable scripts is a win because you don't need to change them when > you step to another distro. Accidentally becoming dependent on some little > quirk of bash will cause you pain later. > > Most of bash's advantages are to do with interactive use (personally I > prefer zsh for interactive use): command line editing, job control, etc. > > The scripting language extensions are, in my experience, usually of > peripheral and rare value - by the time they're genuinely useful it is often > time to shift to a more capable language like Python anyway because you're > moving out of the domain to which the shell is well suited. > Ok, I will take your comments into account, and have decided anyway to shift my attention back to Python which is indeed more capable in terms of (wider) scope of application and portability. However, I will still try to get a final version of this script done. Cheers, felixs
Re: [Fwd: Re: Send to a Listing]
Hi Derek,
> ls -1 /path/to/spool | while read file; do
> outfile_name = "${file}.out"
> #You can use -e but you don't need it, no difference
> sed -n '/^From: $EMAIL_ADDRESS/p ; /Subject: $SUBJECT/p' \
> "$file" > $outfile_name
> done
I can confirm that this script part works; before integrating it into the
rest of my script I tested it separately. The only thing I had to change
was to delete whitespaces before and after = in the variable assignment
in the second line to get the variable assigned correctly.
The first run of the script with /path/to/spool as path/to/INBOX did not
work producing the output: ambiguous redirection I spoke of in a
previous message, and placing the mostly blank output files into the
$HOME folder. Putting it like so, /path/to/INBOX/cur/* did work so
that those sed output files were then placed into this very directory.
Fiddling with it a bit more, I did not pay attention, first cleaning up
sed's output files (deliberately) and now all remaining original messages
are still there
but the index view (the usual one that appears after typing 'mutt'
on the command line and presents all messages) now presents all messages
with a default 01 January date, no FROM, no SUBJECT but retaining all
flags previously set, with an [OK] flag added to the extreme right.
So, I supposed, the format code syntax of the
printf-like formatting sequences was corrupted and tried to restablish
it by copying the default sequence taken out of the configuration
variable reference of the mutt manual into muttrc, but it does not work.
The problem seems to be that those messages are no longer represented
correctly but still bear that information in the message files, so the
function that makes the message data be represented in/by the index
(technically, it may not be correct to put it like that, but that's
what it appears to be) does not work properly. But resetting the
index_format variable, as I said, did not bring the expected result.
Well, finally, I had to reconstruct your message in order to reply to
you maintaing the threading; I hope it works.
Thanks
felixs
Re: [Fwd: Re: Send to a Listing]
Thanks for your detailed comments and explanations. It will need a
second lecture with the Bash Reference Manual opened in another terminal
to fully understand the differences.
felixs
On Wed, Apr 17, 2019 at 08:28:56AM +1000, Cameron Simpson wrote:
> On 16Apr2019 18:40, felixs wrote:
> > On Tue, Apr 16, 2019 at 09:52:57AM +1000, Cameron Simpson wrote:
> > > Globbing is used to construct command line arguments. But a
> > > redirection is
> > > not a command line parameter - it is only subject to parameter
> > > substitution
> > > - $blah.
> >
> > Ok, got it. Globbing = filename expansion, as to the Bash Reference
> > Manual.
>
> Yes. Expanding unquoted "*" etc to match multiple pathnames and putting
> those names in place of the pattern.
>
> > Just to understand: the "${file}.out" in the variable assignment
> > Derek used is an example of a filename expansion, i.e. a special form of it,
> > because it does not expand to just one filename but a set of filenames,
> > that make up the directory?
>
> No, this is parameter substitution (there's a section in the manual titled
> PARAMETER SUBTITUTION). Parameters are shell variables like $file or
> ${file} or the other variations on ${.} which can be used. They are
> string expansions which come from shell variables, and they don't probe the
> filesystem to find out what files may be lying around.
>
> By contrast, globbing aka filename expansion is a separate step in the shell
> command line construction which happens _after_ parameter subtitution. It
> recognised unquoted '*' and '[range]' sequences and probes the filesystem
> for matching paths.
>
> Look:
>
> [~]fleet*> x='b*'
> [~]fleet*> echo b*
> bin bin-cs bin-darwin bin-local books bos build
> [~]fleet*> echo $x
> bin bin-cs bin-darwin bin-local books bos build
> [~]fleet*> echo "$x"
> b*
>
> Here we set $b to "b*", then use it in various ways.
>
> First, a literal "b*" to see what it expands to.
>
> Second: by using $x to get the "b*"; because the $x is unquoted, _after_
> expanding $x, the resulting "b*" is used for globbing, and is expanded to
> the various "b"-starting things in my home directory.
>
> Third: by using "$x" to get the "b*". After expansion, we get "b*" from $x.
> The globbing step still happens, but because the "*" is from the quoted
> section it is not expanded.
>
> > (Or is it, therefore, an array?). I tend to say
> > "set", because in Python3 these braces would enclose a set, but maybe this
> > is misleading.
>
> It is misleading. The ${} markers are just punctuation. Consider:
>
> x=a
> echo ${x}a
> echo ${xa}
>
> The first echo accesses the "$x" variable. The second one accesses the "$xa"
> variable. If you want a Python comparison, thinnk of the {} markers in a
> format string:
>
> print("{x}a")
>
> versus:
>
> print("{xa}")
>
> except that in a format string the markers are mandatory. In the shell the
> convenience bare form "$x" is what is usually used. The {} markers lets you
> specificly delineate the start and end of the variable name, which is useful
> when the name is followed by letters which would otherwise be considered
> part of the name.
>
> As an added bonus, once you are using ${} you can put extra syntax
> inside the {} markers such as:
>
> echo ${x:-3}
>
> which inserts the value of $x unless it is empty or unset, in which case it
> inserts "3".
>
> Python isn't a good comparison lanuage here because as far as parameter
> substitution and globbing go, the shell is a kind of macro language: the
> concrete commands issued are from _after_ the macros (parameters and
> globbing) are expanded.
>
> Python is not like that.
>
Re: [Fwd: Re: Send to a Listing]
On Tue, Apr 16, 2019 at 09:52:57AM +1000, Cameron Simpson wrote:
> On 15Apr2019 11:23, felixs wrote:
> > Thanks, Cameron. Some coments go in between your comments.
>
> As they should :-)
>
> > > If you go:
> > >
> > > sed ... > >
> > > and that does not match a _single_ file, then the shell will not do the
> > > redirection at all (because it can't) and sed doesn't run. This isn't a
> > > bug
> > > in sed or the shell, just that you've asked for something nonsensical.
> >
> > Well, I simply tried to use the catch-all parameter, which cannot be used
> > in this case. But it is accepted when having no redirection.
>
> These are 2 different things. And I misspoke anyway.
>
> Globbing is used to construct command line arguments. But a redirection is
> not a command line parameter - it is only subject to parameter substitution
> - $blah.
Ok, got it. Globbing = filename expansion, as to the Bash Reference
Manual. Just to understand: the "${file}.out" in the variable assignment
Derek used is an example of a filename expansion, i.e. a special form of it,
because it does not expand to just one filename but a set of filenames,
that make up the directory? (Or is it, therefore, an array?). I tend to say
"set", because in Python3 these braces would enclose a set, but maybe this
is misleading.
> This is because a redirection opens a file and attaches the new file
> descriptor to the process running the command. As such it inherently is an
> open of one specific file, not some kind of open of many files.
Thanks for this explanation: that is what I was asking/looking for.
> If you want to process many files a redirection is the wrong tool. You have
> two routes: pass many files on the command line as arguments to a command
> which accepts many files, or use a command like "cat" to collect all the
> data and feed it to the target command using a pipe; in a sense a pipe is a
> redirection with a command on the other side instead of a file.
>
Yes, that's (the latter) an instructive comparison, true.
Well, let's go scripting! Thanks.
felixs
Re: [Fwd: Re: Send to a Listing]
Thanks, Derek.
On Mon, Apr 15, 2019 at 12:02:18PM -0500, Derek Martin wrote:
> On Sun, Apr 14, 2019 at 08:06:04PM +0200, felixs wrote:
> > I searched in the documentation of sed (info sed), the bash-hacker's
> > wiki (1) and read through the Advanced Bash Scripting Guide, but I
> > haven't found the exact use case of redirecting input to all the files
> > of a directory.
>
> FWIW, you redirect input *from* a source file, not to it. You
> redirect output *to* a destination file. And you won't find anything
> that describes the use case of redirecting a program's input from
> multiple files anywhere, because you can't do that. I/O redirection
> is a function of your shell, so if you were to find it, it would be in
> the shell's manual, not in sed's.
For sure, I meant to say from a file, and I wrote from a file in other
occurrences, but here things got mixed up. I know what I/O redirection is,
but that you cannot put a /* when you had a < preceding it, was new to
me.Thanks, I take note of your detailed explanation.
> > But isn't there a way to address all the files in the INBOX? I mean, if
> > it were a mbox format, no problem, that's just one file and its content
> > can be fed into sed.
>
> There are three ways to do this (with sed, see below for likely a
> better option, depending on exactly what you want to do), and which
> one you choose depends on what your goal is. I *think* they've all
> been covered, but this thread has been a little hard for me to follow,
> so I'll summarize briefly:
>
> If you want to filter each message individually (putting its output
> into one file per message) you have one option: Use the shell to loop
> over the files, e.g.
>
> ls -1 /path/to/spool | while read file; do
> outfile_name = "${file}.out"
> # You can use -e but you don't need it, no difference
> sed -n '/^From: $EMAIL_ADDRESS/p ; /Subject: $SUBJECT/p' "$file" >
> $outfile_name
> done
>
> This uses output redirection, but does NOT use input redirection.
> NOTE: The reason I did it this way is because it properly handles any
> file names with spaces or other special characters in them. There is
> some nuance with using ls and specifying /path/to/spool vs.
> /path/to/spool/*, but the first is what you would usually want. This
> probably isn't interesting for Mutt mailboxes, but is a better
> technique for the general case where your filenames may have spaces or
> special characters in them.
That's by far the most elegant solution, thanks!! I'm at it, and I'll
report back to yu as soon as I have set it up with all the variables
set.
> If you want to process all the files at once and produce only one
> output file, you have 2 options:
>
> 1. use cat:
>
> cat /path/to/spool/* | sed -n ...
>
> 2. list the files on the sed command line:
>
>sed -n ... /path/to/spool/*
>
Yes, that's the way we had talked about in the previous message(s).
> > I'd be glad to be able to use this to have sed filter the INBOX for
> > mails having arrived from a known sender with a known subject line,
> > after mutt has polled for new mail.
>
> FWIW, there may be a better tool for this purpose, depending on
> exactly what you're trying to do: Procmail. It would filter your
> messages according to this rule (and many other possible rules you
> could create) *before* Mutt sees it, so that Mutt will find it in the
> folder you intended it to be delivered to in the first place. It can
> also be used to deliver mail to multiple folders, so that for example
> certain messages are delivered to a separate "important" mailbox, but
> still delivered to some other mailbox that is applicable to a larger
> set of messages. Related to procmail is formail, which lets you do
> things like extract headers from a message.
I heard of it quite a lot, but I have never used it; it sounds
interesting, although the more I read into the mutt manual the more
I learn of features I didn't know. For example, the way of monitoring
incoming mail. Maybe it would have been more appropriate to use merely mutt
with its macros, and not sed, but thinking about more generic use cases of text
editing/manipulation it's good to have a thorough knowledge of it.And tomorrow
I tell you that I am going to write all my mails with sed. :-)
I'll report back.
Cheers,
felixs
> --
> 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.
>
Re: Please do not mangle In-Reply-To [was: Re: [Fwd: Re: [Fwd: Re: Send to a Listing]]]
On Mon, Apr 15, 2019 at 01:13:05PM +0200, Francesco Ariis wrote: > On Mon, Apr 15, 2019 at 11:33:45AM +0200, felixs wrote: > > Please see UPDATE section > > [...] > > Hello everyone, > the `In-Reply-To` header for this discussion keeps getting mangled, > which confuses mutt and other programs (check the broken thread [1]) > to no end. :P > Most likely the problem is not using "Reply-" when replying to > messages. If you can avoid doing that, I am sure readers on > mutt-users will appreciate! > -F > > [1] https://marc.info/?l=mutt-users=1=201904=2 Ok, understood to the extent applicable to me. I decided to forward this sent message because I wanted to add the comment to the message to which the comment referred to. But I understand the criticism about thread-breaking messages. Cheers, felixs
[Fwd: Re: [Fwd: Re: Send to a Listing]]
Please see UPDATE section - Forwarded message from felixs - Date: Mon, 15 Apr 2019 11:23:29 +0200 From: felixs To: mutt-users@mutt.org Subject: Re: [Fwd: Re: Send to a Listing] Thanks, Cameron. Some coments go in between your comments. On Mon, Apr 15, 2019 at 05:15:37PM +1000, Cameron Simpson wrote: > On 15Apr2019 08:52, felixs wrote: > > > However, sed can instead accept a list of files on the command line > > Which felixs has tested successfully... > > > > and > > > it will then read from each in turn, so instead of having the shell > > > redirect stdin, just put the wildcard path as the trailing argument on > > > the command line and let the shell expand the wildcard into the list of > > > individual files: > > > sed -ne '/^From: $EMAIL_ADDRESS/p ; /Subject: $SUBJECT/p' > > > path/to/spoolfile/* > > > > > > (The applicable paragraph from the [GNU] sed man page is: > > >If no -e, --expression, -f, or --file option is given, then the > > > first > > >non-option argument is taken as the sed script to interpret. > > > All > > >remaining arguments are names of input files; if no input files > > > are > > >specified, then the standard input is read. > > > ) > > > > > > Nathan > > > > Well, I used the -e option and the first non-option argument is taken as > > the sed script (on my command line: the regexp), isn't it?. And standard > > input > > (redirected to an input path/to/spoolfile/* ) is not read as it (maybe) > > should. > > If you go: > > sed ... > and that does not match a _single_ file, then the shell will not do the > redirection at all (because it can't) and sed doesn't run. This isn't a bug > in sed or the shell, just that you've asked for something nonsensical. Well, I simply tried to use the catch-all parameter, which cannot be used in this case. But it is accepted when having no redirection. That is what I have learned of it. But there was always ONE match: the one I searched for using the regexp, knowing beforehand that it's there (in my example code I actually used no variables but "myemailaddress" and a "well-known subject line. So it seems that it is not that there wasn't any single match. Maybe one can say that the regexp could not match any message because redirecting input to a (spool)file directory's files does not work specifying the catch-all character. Maybe there is a technical reason (beyond the mere statement that it is not allowed to invoke bash like that) why you cannot use * with this kind of redirection. If I re-read the quote/definition of the bash-hackers-wiki (see one of the previous mails) I'm not satisfied with the assessment 'invalid invocation'. UPDATE: Now I understand what you mean with a _single_ file: yes, it's like you say (I read a single match). > Now, if you _want_ the concatenation of all those files as sed's standard > into you should first use a command to concatentate their data. Like "cat". > Thus: > > cat path/to/spoolfile/* | sed ... > Note that for any command where you could just put the filenames as > arguments to the command without changing the behaviours this is called, > colloquially, as a "useless cat" - running a cat and the filter flavour of > the command when the nonfilter flavour would work fine, and a bit faster. Yes, I noticed when reading several examples in the documentation I use, that this is a typical command pipe combination: cat ... | sed ... Thanks for the "useless cat" term, I hadn't heard of it. > > Are there any more list members that can confirm that redirecting it in > > the way I did, does not work/generates an error message? > > The way you did it isn't a legal shell incantation. The problem isn't > anything to do with sed itself. The dream of a bash bug report is over. :-) Cheers, felixs - End forwarded message -
Re: [Fwd: Re: Send to a Listing]
Thanks, Cameron. Some coments go in between your comments. On Mon, Apr 15, 2019 at 05:15:37PM +1000, Cameron Simpson wrote: > On 15Apr2019 08:52, felixs wrote: > > > However, sed can instead accept a list of files on the command line > > Which felixs has tested successfully... > > > > and > > > it will then read from each in turn, so instead of having the shell > > > redirect stdin, just put the wildcard path as the trailing argument on > > > the command line and let the shell expand the wildcard into the list of > > > individual files: > > > sed -ne '/^From: $EMAIL_ADDRESS/p ; /Subject: $SUBJECT/p' > > > path/to/spoolfile/* > > > > > > (The applicable paragraph from the [GNU] sed man page is: > > >If no -e, --expression, -f, or --file option is given, then the > > > first > > >non-option argument is taken as the sed script to interpret. > > > All > > >remaining arguments are names of input files; if no input files > > > are > > >specified, then the standard input is read. > > > ) > > > > > > Nathan > > > > Well, I used the -e option and the first non-option argument is taken as > > the sed script (on my command line: the regexp), isn't it?. And standard > > input > > (redirected to an input path/to/spoolfile/* ) is not read as it (maybe) > > should. > > If you go: > > sed ... > and that does not match a _single_ file, then the shell will not do the > redirection at all (because it can't) and sed doesn't run. This isn't a bug > in sed or the shell, just that you've asked for something nonsensical. Well, I simply tried to use the catch-all parameter, which cannot be used in this case. But it is accepted when having no redirection. That is what I have learned of it. But there was always ONE match: the one I searched for using the regexp, knowing beforehand that it's there (in my example code I actually used no variables but "myemailaddress" and a "well-known subject line. So it seems that it is not that there wasn't any single match. Maybe one can say that the regexp could not match any message because redirecting input to a (spool)file directory's files does not work specifying the catch-all character. Maybe there is a technical reason (beyond the mere statement that it is not allowed to invoke bash like that) why you cannot use * with this kind of redirection. If I re-read the quote/definition of the bash-hackers-wiki (see one of the previous mails) I'm not satisfied with the assessment 'invalid invocation'. > Now, if you _want_ the concatenation of all those files as sed's standard > into you should first use a command to concatentate their data. Like "cat". > Thus: > > cat path/to/spoolfile/* | sed ... > Note that for any command where you could just put the filenames as > arguments to the command without changing the behaviours this is called, > colloquially, as a "useless cat" - running a cat and the filter flavour of > the command when the nonfilter flavour would work fine, and a bit faster. Yes, I noticed when reading several examples in the documentation I use, that this is a typical command pipe combination: cat ... | sed ... Thanks for the "useless cat" term, I hadn't heard of it. > > Are there any more list members that can confirm that redirecting it in > > the way I did, does not work/generates an error message? > > The way you did it isn't a legal shell incantation. The problem isn't > anything to do with sed itself. The dream of a bash bug report is over. :-) Cheers, felixs
Re: [Fwd: Re: Send to a Listing]
On Mon, Apr 15, 2019 at 05:10:14PM +1000, Cameron Simpson wrote: > On 15Apr2019 08:34, felixs wrote: > > On Mon, Apr 15, 2019 at 07:33:53AM +1000, Cameron Simpson wrote: > > > On 15Apr2019 07:19, Cameron Simpson wrote: > > > > Think about it. You're invoking sed _once_. Its input can come from only > > > > one file. > > > > > > Actually, I lie. The way you're doing it "sed > > file. Sed will work on many files, like almost any UNIX utility: > > > > > > sed /path/to/spooldir/* > > > > I can confirm that without redirecting standard input and just putting > > the path as last argument works. > > And I can also confirm that with the redirection from standard input, > > the mentioned error message is still output. > > By the way, the error message (when redirecting) is in German (my locale), > > (I re-translated it into English) even when I put LC_ALL=C before the > > command. But that only happens here, with THIS precise sed command. > > It may depend on what's making the error message. > > Your redirection message from: > > < /path/* > > comes from bash. If you went like this: > > LC_ALL=C sed > then the LC_ALL=C is associated with the sed command only, which has not > been issued. So your bash message will be in the German locale. > > On the other hand, this: > > LC_ALL=C sed 'illegal sed command' ... > > invokes sed in the C locale and then sed will issue errors on that basis. > > Does this distinction fit with the behaviour you see? > Yes, I can confirm that. If I put LC_ALL=C sed outputs a sed error, in C. Typing in LC_ALL=C bash -v ouputs bash error message in C. The redirection error in itself remains a mystery for me. Cheers, felixs
Re: [Fwd: Re: Send to a Listing]
Thanks, Nathan. I can confirm that. Not redirecting standard input to a file but putting path/to/spoolfile as last argumnent works, as indicated in the other message I sent to the list. I checked it on the command line. On Sun, Apr 14, 2019 at 05:38:31PM -0400, Nathan Stratton Treadway wrote: > On Sun, Apr 14, 2019 at 20:06:04 +0200, felixs wrote: > > sed -ne '/^From: $EMAIL_ADDRESS/p ; /Subject: $SUBJECT/p' \ > > < /path/to/spoolfile > > > > If I specify a message file on the command line it works. If I try to > > make sed take its input from ALL the files in the directory using the > > above syntax it does not. I use, for instance, > > If you don't enter any file names on the sed command line it reads from > stdin (and thus works with your "< /path/to/spoolfile" redirect). > > However, sed can instead accept a list of files on the command line and > it will then read from each in turn, so instead of having the shell > redirect stdin, just put the wildcard path as the trailing argument on > the command line and let the shell expand the wildcard into the list of > individual files: > sed -ne '/^From: $EMAIL_ADDRESS/p ; /Subject: $SUBJECT/p' > path/to/spoolfile/* > > (The applicable paragraph from the [GNU] sed man page is: >If no -e, --expression, -f, or --file option is given, then the first >non-option argument is taken as the sed script to interpret. All >remaining arguments are names of input files; if no input files are >specified, then the standard input is read. > ) > > Nathan Well, I used the -e option and the first non-option argument is taken as the sed script (on my command line: the regexp), isn't it?. And standard input (redirected to an input path/to/spoolfile/* ) is not read as it (maybe) should. Are there any more list members that can confirm that redirecting it in the way I did, does not work/generates an error message? Cheers, felixs
Re: [Fwd: Re: Send to a Listing]
On Mon, Apr 15, 2019 at 07:33:53AM +1000, Cameron Simpson wrote: > On 15Apr2019 07:19, Cameron Simpson wrote: > > Think about it. You're invoking sed _once_. Its input can come from only > > one file. > > Actually, I lie. The way you're doing it "sed file. Sed will work on many files, like almost any UNIX utility: > > sed /path/to/spooldir/* I can confirm that without redirecting standard input and just putting the path as last argument works. And I can also confirm that with the redirection from standard input, the mentioned error message is still output. By the way, the error message (when redirecting) is in German (my locale), (I re-translated it into English) even when I put LC_ALL=C before the command. But that only happens here, with THIS precise sed command. If I use sed in another context all error messages are in English (if I use LC_ALL=C). May this be a bash i18n bug (a somewhat strange bug), a bash packaging bug of my distribution, I'm not sure where to send a bug report to. And the fact that bash (when invoking sed) does not accept < /path/* in itself is worth a bug report. Cheers, felixs
Re: [Fwd: Re: Send to a Listing]
I have placed my comments among yours, I hope you don't mind. On Mon, Apr 15, 2019 at 07:19:14AM +1000, Cameron Simpson wrote: > On 14Apr2019 20:06, felixs wrote: > > fiddling with sed in the mutt mailing bash script > > Nothing you're doing requires bash. Just use /bin/sh - "the shell" - it is > portable; it _is_ bash on many linux systems (though by no means all), and > it is _always_ present on any POSIX system. You're writing Bourne shell > scripts, not GNU's particular dialect. Thanks for your view on the matter. Personally speaking, I'm writing shell scripts to my own discretion and I like bash, and I appreciate the GNU project. I might write a .sh AND a .bash version ... whenever I like to. As the op has been served by other list members, there's no need to hurry. > > > I am writing I do not find > > a way to make sed read all files of a directory from standard in? > > I redirected standard input to a file and try to 'point' sed to all the > > files of the directory which is the spoolfile (maildir), like so: > > (...) > So invoke sed many times: > > for spoolfile in path/to/spooldir/* > do >sed . < "$spoolfile" > done Ok, thanks. > > I searched in the documentation of sed (info sed) > > The documentation should be in "man sed". But the GNU folks like to reader > than fairly useless and shove the useful stuff sideways. Aha, didn't notice it, but will take note of that. > > Regardless, redirection is part of the shell, and not part of sed, so what > you want won't be there (unless there's some example that just happens to > match what you're trying to do). > > Have a read of "man sh". Everything is in there, in one place. I like the manpages, too, but info sed seemed much more complete and instructive. First of all I read and still do read the Bash Reference Manual, it's all in there. Thanks, I know that redirection is part of the shell, but I was and I still am interested in sed. Cheers, felixs
[Fwd: Re: Send to a Listing]
Hi mutt users, fiddling with sed in the mutt mailing bash script I am writing I do not find a way to make sed read all files of a directory from standard in? I redirected standard input to a file and try to 'point' sed to all the files of the directory which is the spoolfile (maildir), like so: sed -ne '/^From: $EMAIL_ADDRESS/p ; /Subject: $SUBJECT/p' \ < /path/to/spoolfile If I specify a message file on the command line it works. If I try to make sed take its input from ALL the files in the directory using the above syntax it does not. I use, for instance, sed -ne '/^From: $EMAIL_ADDRESS/p ; /Subject: $SUBJECT/p' \ < path/to/spoolfile/*# error: ambiguous redirection or < path/to/spoolfile/'1'* #given that all msg files start with '1' or variations of that, it always fails with the above error messages. I searched in the documentation of sed (info sed), the bash-hacker's wiki (1) and read through the Advanced Bash Scripting Guide, but I haven't found the exact use case of redirecting input to all the files of a directory. The referred wiki points out that [QUOTE] FILENAME references a normal, ordinary file from the filesystem (which of course can be a FIFO, too. Simply everything you can reference in the filesystem. [END QUOTE] using only < path/to/spoolfile #results in error message: ... Is a directory. Ok. But isn't there a way to address all the files in the INBOX? I mean, if it were a mbox format, no problem, that's just one file and its content can be fed into sed. I'd be glad to be able to use this to have sed filter the INBOX for mails having arrived from a known sender with a known subject line, after mutt has polled for new mail. I've seen that one may use a variable and redirect standard in to it, but even thinking of pathname variable it always expands to a directory or to a given file, but to all the files of a directory? Any suggestions appreciated. felixs (1) https://wiki.bash-hackers.org/syntax/redirection - Forwarded message from felixs - Date: Fri, 12 Apr 2019 00:19:52 +0200 From: felixs To: Willem Offermans Cc: mutt-users@mutt.org Subject: Re: Send to a Listing (...) I thought of working with sed to get the 'alias line' inserted into the addresses_file.txt, and to modify it inserting commas, so that the file may be further processed by mutt. But that's just an idea. I will take up the crontab suggestion. Thanks for all. On Thu, Apr 11, 2019 at 08:13:13PM +0200, Willem Offermans wrote: > Dear Felixs and mutt friends, > > FYI > > I did some searching and I came across the following: (,,,) > > If you experience problem with scripting, I (we) can help you out. > Note the existence of the Advanced Bash Scripting Guide. You can find it all > over on the internet. I use it for more than a decade or so. > It gives you help with scripting. > > If you need crontab to schedule a job to check your mails, look on the > internet once more. There is plenty of documentation. > > Good luck and happy scripting. > > > > On 10 Apr 2019, at 18:31, felixs wrote: > > > > Thanks for your reply. > > > > On Wed, Apr 10, 2019 at 08:50:53AM +0200, Willem Offermans wrote: > >> Dear Felixs and mutt friends, > >> > >> FreeBSD with mutt, that is a strong team :) > > > > (...) - End forwarded message -
Re: Numbered SGML entities in header addresses
On Thu, Apr 11, 2019 at 07:12:57PM -0500, Derek Martin wrote: > On Sun, Apr 07, 2019 at 11:13:53PM +0200, felixs wrote: > > On Fri, Apr 05, 2019 at 11:24:26AM -0700, Ian Zimmerman wrote: > > > I think this is the first time I got hit by the next stage of > > > browserisation: on a mailing list, a From: line that looks like > > > > > > From: "Foo Bari" > > > > > where the entity refers to the character U0107 in Unicode code point > > FWIW, the quoted entity is the latin-1 character 'ì', not the > character 'ć'. The latter would be , not > 236... Seems the last two digits were transposed somehow. > > > And if you add > > > > set charset="utf-8" > > You should simply never set charset. Ever. If you need to, it's > either because your system is misconfigured (so fix that instead), or > your multi-lingual text input configuration is sufficiently > complicated that you already know plenty enough about it to ignore > what I just said. =8^) Setting charset is vastly more likely to > cause problems, because setting it almost guarantees that you don't > know what you're doing, and you're Doing It Wrong™. (...) Thanks. I had already posted a follow-up on my first message. > But clearly it won't help at all in this case. The problematic string > isn't a binary representation of a unicode character. It's an HTML > entity, and HTML entities in recipient headers is not supported by any > of the RFCs, AFAIK (although new ones are added all the time, so it's > hard to be sure)... So the fact that it's there is because some > misguided web-based e-mail software thinks ignoring e-mail RFCs is > cool (or more likely, just does not understand i18n). Event though, call them HTML entities, call them something else, they are ASCII characters and as such they are a subset of utf-8. That is the very reason why they are displayed by mutt as they are displayed. Who said that they are binary representations? I talked about hexadecimal representation being converted into integer, to make use of chr() in my python function example. Maybe I cannot follow now... > > At any rate, nothing will fix this short of Mutt providing explicit > support for it, which IMO it should not do, or writing a script that > can convert it, to be used as a display filter. This is bound to be > more trouble than it's worth... I'm guessing the least obnoxious > approach would be to find a script that converts plain text into > minimally formatted HTML, and then view the resulting thing in w3m or > some such. But such a thing would likely escape the HTML entities it > found in the text, in some fashion, since it's assuming that it's > plain text... Alternatively you'd have to parse the whole file > looking for HTML entities, and then convert them to the appropriate > character for the locale you're using. Blech. Sure, a waste of time. (...) Cheers, felixs
[Fwd: Re: mutt and icloud]
On Thu, Mar 28, 2019 at 10:20:07AM -0400, Jude DaShiell wrote: > Have we got any mutt users now able to get full access to their icloud > accounts and are also able to send with mutt through their icloud > accounts? I'm interested in this and so is another contact who got shot > down on another list for having sent an off topic post concerning mutt. > I still do some (ongoing) testing to use mutt with my icloud account, i.e. with googlemailapis.com, but after discarding oauth2 use for accessing the scope mail.google.com, I decided to make a break before continuing my testing with my cloud account. I will keep you and the list informed. felixs - End forwarded message - Just to follow up: I have been trying to use glcoud (SDK) to get access to my cloud account (for doing a mutt-related project), but connecting via console I always get an oauth2 url link telling me "Go to the following link in your browser",and below, the line: "Enter the verification code". I'm connecting via gcloud auth login ACCOUNT as I do not have any credentialed accounts yet. No browser is launched automatically. I have set the env var to my browser's path, but maybe it's not possible to have a GUI browser launched by a console app, I'm not sure. I reported it to the Google Bug Tracker (1) but still haven't got any reply. I read the related onsite docs, and the short answer is: they talk about having to enter the 200 characters oauth2 url manually (if no browser is launched.) But I am reluctant to do that, there should be a technical solution that does NOT force me to do that. Secondly, I set up a state-of-the-art virtual python3 environment using venv, intending to make gcloud only use its own gcloud packaged libs (to ensure that there is no interference, ENABLE_SITEPACKAGES=0, but doing a gcloud info I can see that the gcloud app does not honour in any way that virtual python3 environment I made and declared as an environment variable using CLOUDSDK_PYTHON=/Path/to/virtual_py/python3 as indicated. It's more, support for python3 is said to be experimental, so it might be VERY experimental. As I didn't even learn python2 as it is outdated, I started right away with python3 after having glimpsed into swaroop's python2 course. So I think if it's not possible to have a plain python3 (venv) virtual installation WITH gcloud, I'd prefer to stay outside. (1) htps://issuetracker.google.com/130257713 INFO: I conect via gcloud after having created an account and an example project via web console. As there are no credentialed accounts yet, I am reminded by gcloud's help text to connect using gcloud auth login ACCOUNT. And here we are... Well, I will keep you and the list informed.
Re: Add XOAUTH2 support?
On Wed, Apr 10, 2019 at 04:57:50PM -0500, Alexander Perlis wrote: > In case it helps inform a decision, here's the OAuth2 status of several > IMAP providers: > > OAUTHBEARER: Google, Yahoo, ATT, Comcast, Sky > XOAUTH2 only: Microsoft, AOL, Yandex > Neither: Apple, Cox, Zoho, Mail.com, GMX, FastMail, 1&1 > > For each service, I searched for the IMAP server name, then did > openssl s_client -crlf -connect IMAPSERVERNAME:993 > Typically they respond with * OK [CAPABILITY blablabla], but in some > cases only with * OK so then I typed "a CAPABILITY". > On Thu, 2019-04-04 at 10:37 -0700, Brandon Long wrote: > > XOAUTH2 is just OAUTHBEARER but based on an earlier draft, so yes, > > it's very similar. We had to ship it at Google because we we're > > deprecating oauth1 and our XOAUTH with it, and the rfc was taking > > longer than we'd hoped. > > > > Given the large population of outlook.com users, I'd be for > > supporting it, maybe with the caveat that we'll remove it when they > > support OAUTHBEARER. Up to you. Thanks for this update; at least it has informed my decision not to go for XOAUTH2 SASL. I hadn't read the RFC, just the Google page related to their XOAUTH2 (Gmail API pages, don't have the link here), which on the other hand might be outdated by now. I'm still struggling a bit with Google's OAUTH2 implementation, but that'll be the subject of another message which I promised to a certain list member. felixs >
Re: Send to a Listing
Thanks, Wiel. I have downloaded the ABSG and taken note of the link. I know that there are solutions out there, but I started with a sketch of what I'd like the script to do, and selecting the appropriate commands. I thought of working with sed to get the 'alias line' inserted into the addresses_file.txt, and to modify it inserting commas, so that the file may be further processed by mutt. But that's just an idea. I will take up the crontab suggestion. Thanks for all. felixs On Thu, Apr 11, 2019 at 08:13:13PM +0200, Willem Offermans wrote: > Dear Felixs and mutt friends, > > FYI > > I did some searching and I came across the following: > > https://www.reddit.com/r/commandline/comments/25n31s/mutt_run_a_command_on_an_attachment_mime/ > > <https://www.reddit.com/r/commandline/comments/25n31s/mutt_run_a_command_on_an_attachment_mime/> > > It is about macro’s. (I remember, I wrote my first macro in the beginning of > the 90’s in wordperfect. Sigh..) > > I know it is not exactly to the point, but maybe it gives you some > inspiration on how to run a command on a selected mail. > > My first FreeBSD experience was in 2000/2001. I fell in love on first sight, > but don’t tell my wife :) > I’m using it ever since and I still discover features that are awesome. I’m > talking about jails, that I have discovered just recently. > I run several servers with FreeBSD. They run for years and only die of > hardware or power failure. You can take the risk of spending > your time. > > If you experience problem with scripting, I (we) can help you out. > Note the existence of the Advanced Bash Scripting Guide. You can find it all > over on the internet. I use it for more than a decade or so. > It gives you help with scripting. > > If you need crontab to schedule a job to check your mails, look on the > internet once more. There is plenty of documentation. > > Good luck and happy scripting. > > > Wiel Offermans > wil...@offermans.rompen.nl > > > > > > On 10 Apr 2019, at 18:31, felixs wrote: > > > > Thanks for your reply. > > > > On Wed, Apr 10, 2019 at 08:50:53AM +0200, Willem Offermans wrote: > >> Dear Felixs and mutt friends, > >> > >> FreeBSD with mutt, that is a strong team :) > > > > I'm about to try using this strong team, my FreeBSD installation medium is > > still > > on my table. Hearing you here clapping your hands, has reminded me of trying > > it out. > >> > >> Do you mean that you want to select the mail with mutt and to start a > >> program/script from within mutt on this selected mail? > >> I would guess that this is possible in mutt. Mutt is amazingly powerful. > >> However, I have never looked for it. I would be surprised > >> if it turned out to be impossible, but maybe someone can comment on this. > > > > As there aren't any list members uttering their expertise on this, I > > think I will take this as a scripting task for myself. I only have limited > > knowledge > > of bash scripting, so maybe it will take some time to get it done. > > > > Thanks for your ideas. > > > > felixs > > > > P.S. Sorry for trimming ... >
Re: Send to a Listing
Thanks for your reply. On Wed, Apr 10, 2019 at 08:50:53AM +0200, Willem Offermans wrote: > Dear Felixs and mutt friends, > > FreeBSD with mutt, that is a strong team :) I'm about to try using this strong team, my FreeBSD installation medium is still on my table. Hearing you here clapping your hands, has reminded me of trying it out. > > Do you mean that you want to select the mail with mutt and to start a > program/script from within mutt on this selected mail? > I would guess that this is possible in mutt. Mutt is amazingly powerful. > However, I have never looked for it. I would be surprised > if it turned out to be impossible, but maybe someone can comment on this. As there aren't any list members uttering their expertise on this, I think I will take this as a scripting task for myself. I only have limited knowledge of bash scripting, so maybe it will take some time to get it done. Thanks for your ideas. felixs P.S. Sorry for trimming ...
Re: Send to a Listing
Thanks, I guess that for BSD things are quite the same, but the following is based on mutt v. 1.11.4. There are several ways to achieve what you are aiming at. One might be: 1a) Edit your EMAIL_ADDRESSES.txt or create a new one. Add alias my_alias (i.e. name of your alias) address1, address2, address3 1b) Source your email_addresses.txt file adding (to muttrc) source path/to/alias_file (i.e. to email_addresses.txt 2) You say you want to have a standard message. 2a) Create a standard message text and save it to /path/to/MY_STANDARD_BODY.txt On the command line (you wanted it as a command), type: mutt -ns "YOUR_SUBJECT" -i /path/to/MY_STANDARD_BODY.txt my_alias Explanation: the -n option prevents default systemwide muttrc to be read. Using the -i option you can include a standard body text. Or you might as well use mutt -ns "YOUR_SUBJECT" my_alias < /path/to/MY_STANDARD_BODY.txt Another way is (working with my examples: 1) Edit muttrc adding set alias test address1, address2, address3 ... 1a) Here you do not have to source anything, because the default value for alias_file is muttrc itself. 2) as 2) above I am not sure whether this fits your needs, but it works, provided that you add a way to supply your email credentials in this "batch" mode. I haven't tried this as I am not fond of storing passwords or credentials in a file. Maybe I'm going to try to set up a script myself, but at the moment I do not have any ready. Ideas: declare a variable in a shell script script.sh addresses=address1, address2, address3 mutt -s "YOUR SUBJECT" $addresses Let me know if that worked for you on FreeBSD. And don't tell me anything if it does not ;-) Cheers, felixs On Tue, Apr 09, 2019 at 05:32:41PM -0500, Software Info wrote: > HI Thanks for replying. I am using it on FreeBSD > > > Regards > SI > > Sent from Mail for Windows 10 > > From: felixs > Sent: Tuesday, April 9, 2019 5:27 PM > To: mutt-users@mutt.org > Subject: Re: Send to a Listing > > On Mon, Apr 08, 2019 at 02:38:36PM -0500, Software Info wrote: > > Hi All > > Each day I get a text file with a bunch of email addresses. I would like to > > send out a standard message to all email addresses in this file. Is there > > any way Mutt allows me to do this with a command? I would later like to > > write a script to include this command later on. > > > > > > Regards > > SoftInfoJ > > > > Sent from Mail for Windows 10 > > > For Linux or for Windows? > On which platform are you using mutt? > > Cheers, > > felixs >
Re: Send to a Listing
On Mon, Apr 08, 2019 at 02:38:36PM -0500, Software Info wrote: > Hi All > Each day I get a text file with a bunch of email addresses. I would like to > send out a standard message to all email addresses in this file. Is there any > way Mutt allows me to do this with a command? I would later like to write a > script to include this command later on. > > > Regards > SoftInfoJ > > Sent from Mail for Windows 10 For Linux or for Windows? On which platform are you using mutt? Cheers, felixs
Re: Numbered SGML entities in header addresses
On Mon, Apr 08, 2019 at 08:40:09PM -0700, Ian Zimmerman wrote: > On 2019-04-07 23:13, felixs wrote: > > > > From: "Foo Bari" > > > > > > where the entity refers to the character U0107 in Unicode code point > > > space. I would like to automatically see the correct glyph at least > > > when it is in one of the visible headers. Is there a display filtering > > > feature in mutt that would allow me to do that (I don't mind if it > > > requires a bit of configuration)? > > > > And if you add > > > > set charset="utf-8" > > > > to your muttrc conf file? > > That doesn't look at all plausible to me. For one thing, UTF-8 is the > systemwide default, meaning it ends up in my LANG and LC_ variables. I > am as sure as I can be about anything that mutt picks up those if the > "charset" mutt variable is not set. > > For another thing, why should it help? Those ASCII characters are > perfectly valid in the name part of a From header, and normally I expect > mutt to show them to me as they are. Sorry, at first glance I missed the significance of that. It's true, the characters are perfectly valid and as such ASCII characters are nothing than a subset of utf-8. No, it would then not help to set this in your conf file. But is mutt really capable of correcting such encoding errors of the sending side, or would that be desirable at all? Sorry for any confusion that that might have created. felixs
Re: Numbered SGML entities in header addresses
On Mon, Apr 08, 2019 at 08:40:09PM -0700, Ian Zimmerman wrote:
> On 2019-04-07 23:13, felixs wrote:
>
> > > From: "Foo Bari"
> > >
> > > where the entity refers to the character U0107 in Unicode code point
> > > space. I would like to automatically see the correct glyph at least
> > > when it is in one of the visible headers. Is there a display filtering
> > > feature in mutt that would allow me to do that (I don't mind if it
> > > requires a bit of configuration)?
> >
> > And if you add
> >
> > set charset="utf-8"
> >
> > to your muttrc conf file?
>
> That doesn't look at all plausible to me. For one thing, UTF-8 is the
> systemwide default, meaning it ends up in my LANG and LC_ variables. I
> am as sure as I can be about anything that mutt picks up those if the
> "charset" mutt variable is not set.
Yes, you are right, mutt reads the LC_* variables and is usually able to
represent characters in utf-8 if that is set by them. But in case of
problems, as I thought you might have, it may be a help to explicitly set it.
> For another thing, why should it help? Those ASCII characters are
> perfectly valid in the name part of a From header, and normally I expect
> mutt to show them to me as they are. It is only in this case where some
> HTML-addled MUA decided to use them together to encode a ISO 8859-2
> character (_not_ UTF-8 or anything related) that I want a way to see the
> character really intended by the sender.
You have asked for a "display filter" setting in mutt to be able to see
the "real" character, which is a character that is part of the Unicode
Database. Even if the message you supposedly received was encoded in
ISO-8859-2, mutt, when opening the message, would convert it into Unicode
(usually, utf-8) if your LC_variables
are correctly set to use it. Or, see above, set them explicitly to be sure.
Please take note that I did not reproduce your issue. So I actually do
not know why this happens in your case. Do you have some more information?
To know, by other means, what the intended character was, in *Python* you
might use the chr() function. Given the fact that chr() works with
integers, you first have to convert the hexadecimal into an integer.
chr(int('0x0107', base=16))
Maybe I can find some other way using just mutt's conf options.
Patience, please. :-)
> Nevertheless, your suggestion should do no harm, so I'll try it and
> report back.
Ok.
Cheers,
felixs
Re: Numbered SGML entities in header addresses
On Fri, Apr 05, 2019 at 11:24:26AM -0700, Ian Zimmerman wrote: > I think this is the first time I got hit by the next stage of > browserisation: on a mailing list, a From: line that looks like > > From: "Foo Bari" > > where the entity refers to the character U0107 in Unicode code point > space. I would like to automatically see the correct glyph at least > when it is in one of the visible headers. Is there a display filtering > feature in mutt that would allow me to do that (I don't mind if it > requires a bit of configuration)? > > And if not, _should_ it be possible? ;-) > > -- > Please don't Cc: me privately on mailing lists and Usenet, > if you also post the followup to the list or newsgroup. > To reply privately _only_ on Usenet and on broken lists > which rewrite From, fetch the TXT record for no-use.mooo.com. And if you add set charset="utf-8" to your muttrc conf file? Cheers, felixs
[Fwd: [Fwd: Re: Patch [was Re: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11]]]
- Forwarded message from felixs - Date: Sun, 31 Mar 2019 20:14:30 +0200 From: felixs To: Todd Zullinger Cc: mutt-users@mutt.org Subject: [Fwd: Re: Patch [was Re: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11]] - Forwarded message from felixs - Date: Sat, 30 Mar 2019 23:52:02 +0100 From: felixs To: Todd Zullinger Cc: mutt-users@mutt.org Subject: Re: Patch [was Re: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11] On Fri, Mar 29, 2019 at 03:35:28PM -0400, Todd Zullinger wrote: > Hi, > > felixs wrote: > > On Thu, Mar 28, 2019 at 03:11:34PM -0700, Kevin J. McCarthy wrote: > >> On Thu, Mar 28, 2019 at 10:20:54PM +0100, felixs wrote: > >>> I tried to access the branch with the patch, but the access is > >>> password-protected. > >> > >> The repo is clonable via <https://gitlab.com/muttmua/mutt.git>, which you > >> will find under the clone button on the project details page. > > > > Yes, I did that as a first operation 2 or 3 days ago, assuming that the > > patch > > was part of it. To better visualize the repo I have been working on > > setting up gitweb functionality by means of a web server. At the moment, > > I'm still getting 403 forbidden when connecting to localhost, but I > > think I'll get it done. > > It may be easier to use a graphical interface like gitk to > view the repository outside of the command line than setting > up gitweb. tig, a console repository viewer, is also quite > handy. Maybe, but I already set it up. The 403 forbidden at localhost I get seems to be a permissions issue. > > Alternately, the 'git instaweb' command can spawn gitweb for > a single repository fairly easily. It can use a number of > different web servers, lighttpd is one of the simplest -- > requiring no manual configuration. How boring! ;-) UPDATE: Fiddling with git/gitserver I have come across a very good resource, the brand-new 2nd edition of Scott Chacon's and Ben Straub's 'ProGit' published by APress only a few days ago, that may be of interest for you and the mutt community Here's the url: https://www.git-scm.com/book/en/v2 [Fixed a typo in the url above] Cheers, felixs --- End forwarded message - - End forwarded message -
[Fwd: Re: Patch [was Re: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11]]
- Forwarded message from felixs - Date: Sat, 30 Mar 2019 23:52:02 +0100 From: felixs To: Todd Zullinger Cc: mutt-users@mutt.org Subject: Re: Patch [was Re: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11] On Fri, Mar 29, 2019 at 03:35:28PM -0400, Todd Zullinger wrote: > Hi, > > felixs wrote: > > On Thu, Mar 28, 2019 at 03:11:34PM -0700, Kevin J. McCarthy wrote: > >> On Thu, Mar 28, 2019 at 10:20:54PM +0100, felixs wrote: > >>> I tried to access the branch with the patch, but the access is > >>> password-protected. > >> > >> The repo is clonable via <https://gitlab.com/muttmua/mutt.git>, which you > >> will find under the clone button on the project details page. > > > > Yes, I did that as a first operation 2 or 3 days ago, assuming that the > > patch > > was part of it. To better visualize the repo I have been working on > > setting up gitweb functionality by means of a web server. At the moment, > > I'm still getting 403 forbidden when connecting to localhost, but I > > think I'll get it done. > > It may be easier to use a graphical interface like gitk to > view the repository outside of the command line than setting > up gitweb. tig, a console repository viewer, is also quite > handy. Maybe, but I already set it up. The 403 forbidden at localhost I get seems to be a permissions issue. > > Alternately, the 'git instaweb' command can spawn gitweb for > a single repository fairly easily. It can use a number of > different web servers, lighttpd is one of the simplest -- > requiring no manual configuration. How boring! ;-) UPDATE: Fiddling with git/gitserver I have come across a very good resource, the brand-new 2nd edition of Scott Chacon's and Ben Straub's 'ProGit' published by APress only a few days ago, that may be of interest for you and the mutt community Here's the url: https://www,git-scm.com/book/en/v2 Cheers, felixs --- End forwarded message -
[Fwd: Re: Patch [was Re: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11]]
- Forwarded message from felixs - On Fri, Mar 29, 2019 at 03:43:11PM -0700, Kevin J. McCarthy wrote: > On Fri, Mar 29, 2019 at 07:57:49PM +0100, felixs wrote: > > OK, I managed to apply the patch as an email patchfile using > > > > git am /path/to/patch > > > > git log shows inclusion of the patch commit. > > git status says that my cloned repo is +1 ahead of MASTER-ORIGIN > > Just to follow up, I slightly modified the commit and pushed to stable and > master. I believe this should preserve the behavior your config had prior > to 1.11.0. If I can I'll try to get a stable release out with the > fix before the 1.12.0 release. > > I also changed IMAP to try OAUTH first when $imap_authenticators is unset, > like POP does. However, both will now return UNAVAIL if oauthbearer is not > explictly requested or configured (via $*_oauth_refresh_command). Thanks for the update. I did git checkout origin -- pop_auth.c imap/auth.c auth_oauth.c which are the three files that changed. Cheers, felixs - End forwarded message -
Re: Patch [was Re: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11]
On Fri, Mar 29, 2019 at 03:35:28PM -0400, Todd Zullinger wrote: > Hi, > > felixs wrote: > > On Thu, Mar 28, 2019 at 03:11:34PM -0700, Kevin J. McCarthy wrote: > >> On Thu, Mar 28, 2019 at 10:20:54PM +0100, felixs wrote: > >>> I tried to access the branch with the patch, but the access is > >>> password-protected. > >> > >> The repo is clonable via <https://gitlab.com/muttmua/mutt.git>, which you > >> will find under the clone button on the project details page. > > > > Yes, I did that as a first operation 2 or 3 days ago, assuming that the > > patch > > was part of it. To better visualize the repo I have been working on > > setting up gitweb functionality by means of a web server. At the moment, > > I'm still getting 403 forbidden when connecting to localhost, but I > > think I'll get it done. > > It may be easier to use a graphical interface like gitk to > view the repository outside of the command line than setting > up gitweb. tig, a console repository viewer, is also quite > handy. Maybe, but I already set it up. The 403 forbidden at localhost I get seems to be a permissions issue. > > Alternately, the 'git instaweb' command can spawn gitweb for > a single repository fairly easily. It can use a number of > different web servers, lighttpd is one of the simplest -- > requiring no manual configuration. How boring! ;-) > > >> If you open a particular commit, the options button has "Email patches" and > >> "Plain diff" views. So, for example the commit in question is available > >> via > >> <https://gitlab.com/muttmua/mutt/commit/a646d867b67bae327a9e5fc0301da5fa73450c68.patch> > >> and > >> <https://gitlab.com/muttmua/mutt/commit/a646d867b67bae327a9e5fc0301da5fa73450c68.diff> > > Ok, thanks. Now it's confirmed that the patch/diff is in a separate > > repository (not master, which I cloned). I'll get and test it. > > I know Kevin already clarified this in another reply, but > perhaps some additional details will help. > (...) > Hope this helps (and isn't too far off-topic). :) > Thanks, Todd, it DID help. Cheers, felixs
Re: github (was: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11])
On Sat, Mar 30, 2019 at 09:07:24AM +1100, Cameron Simpson wrote: > On 29Mar2019 13:05, felixs wrote: > > On Fri, Mar 29, 2019 at 08:42:33AM +1100, Cameron Simpson wrote: > > > On 28Mar2019 22:20, felixs wrote: > > > > I tried to access the branch with the patch, but the access is > > > > password-protected. Are you able to share the patchfile by other means? > > > > Signing up with gitlab is another option, but I'd need some more time to > > > > decide on whether it's the right choice for me. > > > > > > You can sign up to github without any other obligations; it is free and > > > gets > > > you various useful facilities. > > > > > > For example, my own code is published on bitbucket, but I have a github > > > account in order to interoperate with various projects. > > > > > > There isn't actually any particular downside. > > > > > Thanks for your comment, but already using gcloud I keep thinking about > > the comparative benefits of using another 'big player' like gitlab, github > > or platforms alike. I checked my possibilities/resources of code developing > > and > > cannot see the 'upsides' (sorry for the neologism) of using another > > service. But please tell me. > > Mainly for interoperation with others. As I mentioned, I host my own code on > bitbucket, but have github and gitlab accounts so that I can interact with > projects hosted there. > > For your own code, you can do as you want. When you want to submit to other > projects it is a great help to have an account with their repo hosting > service. Ok, I see. Thanks for your detailed explanation. > > > OK, Google strives for getting more user data, but we know > > that and can act accordingly. > > Yeah. I try to use Google services sparingly. I have a GMail account, but it > forwards. I usually search with duckduckgo. And so on. > > > It's more: to get a good overwiew of innovative > > technologies (and diving into it) I cannot see any other platform that has > > such > > a broad approach. > > The broad approach brings lock in. I try to think in terms of specific > services. Like supermarket loyalty cards, use of a single platform for > everything warps my decisions, so I try not to do that. > Anyway, I'm not trying to drive you to joins every service on the planet, or > recommending github/gitlab/etc in particular. I'm just saying having an > account costs no $s and will aid certain activities. Do it as needed. Or > not, if you'd rather not. In general, I try not to have too many accounts, but I thank you for sharing your valuable insight. I feel better informed now. Cheers, felixs
Re: Patch [was Re: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11]
On Fri, Mar 29, 2019 at 08:57:36AM -0700, Kevin J. McCarthy wrote:
> On Fri, Mar 29, 2019 at 12:48:46PM +0100, felixs wrote:
> > On Thu, Mar 28, 2019 at 03:11:34PM -0700, Kevin J. McCarthy wrote:
> > > The repo is clonable via <https://gitlab.com/muttmua/mutt.git>,
> > > which you will find under the clone button on the project details
> > > page.
> >
> > Yes, I did that as a first operation 2 or 3 days ago, assuming that the
> > patch was part of it.
>
> The patch _is_ part of it. However, by default when you clone a repos, git
> only maps the origin/master reference to a local branch reference
> ("master"). You'll need to manually map other branches, e.g. "git checkout
> -b kevin/stable-oauth-fix origin/kevin/stable-oauth-fix".
>
> Yes, git from the cli is pretty awful. Personally I use magit so I don't
> have to learn or deal with the intricacies.
>
OK, I managed to apply the patch as an email patchfile
using
git am /path/to/patch
git log shows inclusion of the patch commit.
git status says that my cloned repo is +1 ahead of MASTER-ORIGIN
Thanks for your hints.
felixs
Re: github (was: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11])
On Fri, Mar 29, 2019 at 08:42:33AM +1100, Cameron Simpson wrote: > On 28Mar2019 22:20, felixs wrote: > > I tried to access the branch with the patch, but the access is > > password-protected. Are you able to share the patchfile by other means? > > Signing up with gitlab is another option, but I'd need some more time to > > decide on whether it's the right choice for me. > > You can sign up to github without any other obligations; it is free and gets > you various useful facilities. > > For example, my own code is published on bitbucket, but I have a github > account in order to interoperate with various projects. > > There isn't actually any particular downside. > Thanks for your comment, but already using gcloud I keep thinking about the comparative benefits of using another 'big player' like gitlab, github or platforms alike. I checked my possibilities/resources of code developing and cannot see the 'upsides' (sorry for the neologism) of using another service. But please tell me. OK, Google strives for getting more user data, but we know that and can act accordingly. It's more: to get a good overwiew of innovative technologies (and diving into it) I cannot see any other platform that has such a broad approach. felixs
Patch [was Re: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11]
On Thu, Mar 28, 2019 at 03:11:34PM -0700, Kevin J. McCarthy wrote: > On Thu, Mar 28, 2019 at 10:20:54PM +0100, felixs wrote: > > I tried to access the branch with the patch, but the access is > > password-protected. > > The repo is clonable via <https://gitlab.com/muttmua/mutt.git>, which you > will find under the clone button on the project details page. Yes, I did that as a first operation 2 or 3 days ago, assuming that the patch was part of it. To better visualize the repo I have been working on setting up gitweb functionality by means of a web server. At the moment, I'm still getting 403 forbidden when connecting to localhost, but I think I'll get it done. > > If you open a particular commit, the options button has "Email patches" and > "Plain diff" views. So, for example the commit in question is available via > <https://gitlab.com/muttmua/mutt/commit/a646d867b67bae327a9e5fc0301da5fa73450c68.patch> > and > <https://gitlab.com/muttmua/mutt/commit/a646d867b67bae327a9e5fc0301da5fa73450c68.diff> Ok, thanks. Now it's confirmed that the patch/diff is in a separate repository (not master, which I cloned). I'll get and test it. > However, I was still thinking about making one more change the commit so > behavior remains the same as before when you has $pop_auth_try_all unset. > For now, you're welcome to try the patch with that variable set. Yes, now I have this variable set. One may ask for why I unset it explicitly. It was to ensure that no other authentication method would interfere with the one which is/was set up, which is "user", even when you do not set it up explicitly with $pop_authenticators. Thanks again. felixs
Re: mutt and icloud
On Thu, Mar 28, 2019 at 10:20:07AM -0400, Jude DaShiell wrote: > Have we got any mutt users now able to get full access to their icloud > accounts and are also able to send with mutt through their icloud > accounts? I'm interested in this and so is another contact who got shot > down on another list for having sent an off topic post concerning mutt. > I still do some (ongoing) testing to use mutt with my icloud account, i.e. with googlemailapis.com, but after discarding oauth2 use for accessing the scope mail.google.com, I decided to make a break before continuing my testing with my cloud account. I will keep you and the list informed. felixs >
Re: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11]
On Wed, Mar 27, 2019 at 09:18:22AM -0700, Kevin J. McCarthy wrote: > On Wed, Mar 27, 2019 at 04:54:04PM +0100, felixs wrote: > > Having studied oauth2 more in depth I do not consider it to be secure > > enough (as such) mainly because of its overwhelming complexity, and I will > > NOT use it for mail purposes. > > Thanks for the update felixs. I've just returned from overseas so my > schedule is a bit full, but as soon as I can I will fix up and push the > patch into stable. > Hi Kevin, I tried to access the branch with the patch, but the access is password-protected. Are you able to share the patchfile by other means? Signing up with gitlab is another option, but I'd need some more time to decide on whether it's the right choice for me. Could you email it as a patchfile? Thanks in advance. felixs
Re: [Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11]
On Wed, Mar 27, 2019 at 09:18:22AM -0700, Kevin J. McCarthy wrote: > On Wed, Mar 27, 2019 at 04:54:04PM +0100, felixs wrote: > > Having studied oauth2 more in depth I do not consider it to be secure > > enough (as such) mainly because of its overwhelming complexity, and I will > > NOT use it for mail purposes. > > Thanks for the update felixs. I've just returned from overseas so my > schedule is a bit full, but as soon as I can I will fix up and push the > patch into stable. > OK, I cloned the git repository and will do some testing with the patch. I hope I'll be fast enough to get it done before you are about to commit it. I already have encountered some problems to 'make' the manual, but without problems/errors it would be somewhat boring. ;-) As I was used to subversion I am quite a beginner in using git. Best regards felixs
[Fwd: Re: Impossible to connect to mail server via pops3 using mutt 1.11]
On Sat, Mar 23, 2019 at 08:29:44PM +0800, Kevin J. McCarthy wrote: > On Sat, Mar 23, 2019 at 10:27:38AM +0100, felixs wrote: > > 'getoauthbearersupport' and 'no refresh command defined', not showing > > any willingness to download my e-mais. > > Hi felixs, > > The OAUTH support was added in version 1.11.0. Perhaps the POP > implementation hasn't gotten enough testing. Thanks, Kevin, for your kind answer. Actually, I downloaded the oauth2.py script and I will check if I can adapt it for using it with pop as well (importing the pop libs), so I will do some testing, at least with my gmail account. I'm not a real programmer, but I am in the 'training circuit'...) (...) I now will try to set up the oauth2 authentication. (...) Having studied oauth2 more in depth I do not consider it to be secure enough (as such) mainly because of its overwhelming complexity, and I will NOT use it for mail purposes. For more secure authentication to the mail server, one might consider using OpenID Connect, but on the other hand I am meditating about whether I need such a system at all. felixs
Test
Test
[Re: Impossible to connect to mail server via pops3 using mutt 1.11]
- Forwarded message from felixs - Date: Sun, 24 Mar 2019 12:59:35 +0100 From: felixs To: "Kevin J. McCarthy" Cc: mutt-users@mutt.org Subject: Re: Impossible to connect to mail server via pops3 using mutt 1.11 On Sat, Mar 23, 2019 at 08:29:44PM +0800, Kevin J. McCarthy wrote: > On Sat, Mar 23, 2019 at 10:27:38AM +0100, felixs wrote: > > 'getoauthbearersupport' and 'no refresh command defined', not showing > > any willingness to download my e-mais. > > Hi felixs, > > The OAUTH support was added in version 1.11.0. Perhaps the POP > implementation hasn't gotten enough testing. Thanks, Kevin, for your kind answer. Actually, I downloaded the oauth2.py script and I will check if I can adapt it for using it with pop as well (importing the pop libs), so I will do some testing, at least with my gmail account. I'm not a real programmer, but I am in the 'training circuit'...) > > It looks like if $pop_authenticators is undefined (the default) then POP > will try OAUTH first. Whereas IMAP will try OAUTH last. I think this was > an oversight, and I will change POP to match IMAP. #Well, I had set unset pop_auth_try_all #and didn't have pop_authenticators set/set but #commented#. > > However, if $pop_auth_try_all is set (the default), then Mutt *should* try > all the other mechanisms (sasl, apop, user). Do you have $pop_auth_try_all > set? > > You could also try setting $pop_authenticators to something like > "apop:user". Yes, thanks. Now I have #unset pop_auth_try_all set pop_autenticators="sasl:apop:user" and it worked (with "user") AFTER I disabled Gmail's security settings "block less secure apps" i.e. mutt, in this case. I don't remember having set that gmail setting before, but maybe it's the default. I now have my emails on my machine, and that's where they belong! ;-) Thanks for your patch, but I had to find out and correct it myself. Including this version I will build all further mutt versions myself. I now will try to set up the oauth2 authentication. To get the credentials mentioned in the OAUTHBEARER section of the mutt manual (gmail) you have to create a project and define a consent screen for users, in order to get their consent to their data being used by the app, so that puzzled me. Is that really my use case? I just want a client ID and secret to generate access tokens/refresh tokens to be able to connect more securely to the mailserver using mutt. I guess I have to go for the XOAUTH SASL method. I'll let you know as soon as I managed to get it all set up the way I like to have it. Thanks and have a nice sunday felixs > > -- > Kevin J. McCarthy > GPG Fingerprint: 8975 A9B3 3AA3 7910 385C 5308 ADEF 7684 8031 6BDA - End forwarded message -
Impossible to connect to mail server via pops3 using mutt 1.11
Hi mutt users, this is my first post so at first I'd like to say hello to ev'ryone and to thank all the people who make this wonderful e-mail client possible. I have been using it for a year or so, retrieving my emails via pops, but lately I experienced some troubles doing so, i.e. retrieving my e-mails via pops mutt's own output in the 'status line' indicated: 'getoauthbearersupport' and 'no refresh command defined', not showing any willingness to download my e-mais. I understand that oauth is a fine security mechanism, I've read the corresponding section in the mutt manual (one of the best of its kind I've ever seen for its exhaustiveness), and I'm eager to implement it in the very near future. But I also understand that this, oauth/oauthbearer support, is a feature, something I can choose. Mutt's status line message and its behavior, however, indicate that it does not let me choose, it simply does not retrieve my emails via pops when I press Shift+G (=fetchmail/retrieve function), and not only in the case of gmail but also with other e-mail providers, so I determined that it's mutt that causes the issue. I compiled mutt with --enable-pop (among other flags) and am currently using v.1.11.3 (well, no, currently, I am using the web interface, for obvious reasons) So, is this a bug, or a feature to convince people to adopt oauth mechanism? ;-) Any comment, help or pointer is appreciated. felixs
