Re: locale and external address
Alle venerdì 7 dicembre 2007, Kyle Wheeler ha scritto: > This sounds like something you should more likely be asking the exim > mailing list. Yes, I've already posted a message in exim list... > That said, to prove for a fact whether it's mutt or exim, try > replacing your hooks with this: > send-hook .* 'my_hdr From: samiel <[EMAIL PROTECTED]>' > If your mail still has the wrong header, then there's nothing mutt can > do about it. Exim is likely rewriting things that use the form > "@hostname" (where "hostname" is the local machine's hostname), since > those are technically illegal according to the SMTP RFC (2822). I tried: the local mail arrives again with the wrong (external) address. The outgoing mail (I think for my provider doesn't recognize the sender name "[EMAIL PROTECTED]") doesn't arrives at all. Infact, in /var/log/exim4/mainlog I read: == 2007-12-07 23:25:12 1J0ldA-0003hk-I6 ** [EMAIL PROTECTED]: Unrouteable address 2007-12-07 23:25:12 1J0ldA-0003hk-I6 Frozen (delivery error message) == So, we can conclude that all this matter depends on exim behaviour... Thanx! M. -- linux user no.: 353546 public key at http://keyserver.linux.it
Re: terminal settings
On Fri, Dec 07, 2007 at 03:51:30PM -0500, Dave Dodge wrote: > Try setting the environment variable LANG=C setenv LC_ALL C fixed it. Thanks for the nudge. ~S -- [EMAIL PROTECTED]I love my country, but I fear my government.
Re: mailbox close while accessing exchange over imap
Jason Joines wrote: Brendan Cully wrote: On Friday, 30 November 2007 at 16:22, Jason Joines wrote: Subject: mailbox close while accessing exchange over imap From: Jason Joines <[EMAIL PROTECTED]> To: mutt-users@mutt.org Date: Fri Nov 30 14:37:52 2007 Any suggestions for other client side tweaks to help with this problem? I don't administer the exchange server and getting those who do to even reveal any settings, much less change them, will be a nightmare. I did a bit more checking. With the imap_keepalive=600 option, the IMAP TCP connection itself seems to stay open indefinitely via netstat. The client then gets the "mailbox closed" message right at 30 minutes after the last activity. I think there's an open bug about this (and it does need fixing before 1.6). There are three different settings that can affect how often mutt sends messages to the IMAP server: $timeout $mail_check $imap_keepalive The problem is that they are basically independent. imap_keepalive works when mutt is not in a menu (eg while composing a message or viewing something in the pager). When you're in the index, it doesn't do anything. In this case, $timeout causes mutt to poll the current mailbox for new mail every $timeout seconds (and mail_check controls how often it interrogates other mailboxes). There's an entry about this in the FAQ: http://wiki.mutt.org/?MuttFaq/RemoteFolder It may be a firewall issue like the FAQ mentions. Do you know what that bug URL is? Jason === Another interesting find. Now I'm running the debug version and have timeout, mail_check, and imap_keepalive set to 2. When I'm looking at the inbox index and following the debug log I see NOOP every 2 seconds. When I'm on a message compose screen it only happens every 4 seconds. Jason ===
Re: terminal settings
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, December 7 at 03:39 PM, quoth Stefanie Slamon: >After being away from the joys of a shell account for a while, I'm >back to reading mail as it should be read. Unfortunately, I'm >having a witch of a time getting a compatible term and charset >match to display threading characters correctly. What I'm getting >now looks like this: > > 221 O Dec 07 Pau Amaro-Seoan ( 20) Re: searching in "sent" > 222 O Dec 07 Michael Tatge ( 24) └─> > 223 O Dec 07 Pau Amaro-Seoan ( 29) └─> > 224 N Dec 07 Nicolas Rachins ( 13) └─> What's wrong with that? Looks fine to me... (Though the fact that it renders fine on my terminal and not on yours suggests that perhaps your locale or TERM setting is incorrect.) ~Kyle - -- No one really listens to anyone else, and if you try it for a while you'll see why. -- Mignon McLaughlin -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHWbR9BkIOoMqOI14RAk/fAKCeBygqMT9zk2Wt9juXNQVbY2yamwCgups9 RQ9d1A/lLMt3yItXOEGnlRs= =CwxN -END PGP SIGNATURE-
Re: locale and external address
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, December 7 at 09:41 PM, quoth Mauro Sacchetto: >I made some experiments more. >If I put in my .muttrc: >send-hook .* 'my_hdr From: spiderman <[EMAIL PROTECTED]> >exim4 sends correctly the message, >and in the header I read the new address. SO, >it doesn'r re-writes the original, true address. >But if I put into: >send-hook .* 'my_hdr From: spiderman <[EMAIL PROTECTED]> >send-hook '~t debian$' 'my_hdr From: samiel <[EMAIL PROTECTED]>' >(for I've: set hostname="debian") >in local email I find again an ever my right external address. >Why in the first case the field "From" is changed >as I ask to Mutt, and in the second one not? This sounds like something you should more likely be asking the exim mailing list. That said, to prove for a fact whether it's mutt or exim, try replacing your hooks with this: send-hook .* 'my_hdr From: samiel <[EMAIL PROTECTED]>' If your mail still has the wrong header, then there's nothing mutt can do about it. Exim is likely rewriting things that use the form "@hostname" (where "hostname" is the local machine's hostname), since those are technically illegal according to the SMTP RFC (2822). ~Kyle - -- You cannot reason a person out of a position he did not reason himself into in the first place. -- Jonathan Swift -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHWbP+BkIOoMqOI14RAirFAJ0a21Xe4MCxggBm7gExsVLeyoBIAwCgs8AB jpriOIOAANCOrOBAyZpMiFY= =OjaL -END PGP SIGNATURE-
Re: terminal settings
On Fri, Dec 07, 2007 at 03:39:48PM -0500, Stefanie Slamon wrote: > 221 O Dec 07 Pau Amaro-Seoan ( 20) Re: searching in "sent" > 222 O Dec 07 Michael Tatge ( 24) ??> > 223 O Dec 07 Pau Amaro-Seoan ( 29) ??> > 224 N Dec 07 Nicolas Rachins ( 13) ??> > > My terminal progeam (SecureCRT) is using VT102 w/ansi and my > term env variable is vt102 as well. What do I need to do to get > the right characters to display? Try setting the environment variable LANG=C If that fixes it, then it's a locale problem. -Dave Dodge
terminal settings
After being away from the joys of a shell account for a while, I'm back to reading mail as it should be read. Unfortunately, I'm having a witch of a time getting a compatible term and charset match to display threading characters correctly. What I'm getting now looks like this: 221 O Dec 07 Pau Amaro-Seoan ( 20) Re: searching in "sent" 222 O Dec 07 Michael Tatge ( 24) └─> 223 O Dec 07 Pau Amaro-Seoan ( 29) └─> 224 N Dec 07 Nicolas Rachins ( 13) └─> My terminal progeam (SecureCRT) is using VT102 w/ansi and my term env variable is vt102 as well. What do I need to do to get the right characters to display? ~Stef -- [EMAIL PROTECTED]I love my country, but I fear my government.
Re: locale and external address
Alle giovedì 6 dicembre 2007, Kyle Wheeler ha scritto: > > I find again the old external address and not that one specified by > > the hook: "samiel <[EMAIL PROTECTED]>" I'm very confused, but > > I suspect that Exim rewrite the address furnished by Mutt with that > > one present in /etc/mail.addresses... Maybe, there is something to > > change in exim.conf too... M. > > Possibly. If your "sent" messages are correct, then your suspicion > sounds plausible. I made some experiments more. If I put in my .muttrc: send-hook .* 'my_hdr From: spiderman <[EMAIL PROTECTED]> exim4 sends correctly the message, and in the header I read the new address. SO, it doesn'r re-writes the original, true address. But if I put into: send-hook .* 'my_hdr From: spiderman <[EMAIL PROTECTED]> send-hook '~t debian$' 'my_hdr From: samiel <[EMAIL PROTECTED]>' (for I've: set hostname="debian") in local email I find again an ever my right external address. Why in the first case the field "From" is changed as I ask to Mutt, and in the second one not? M. -- linux user no.: 353546 public key at http://keyserver.linux.it
Re: searching in "sent"
[Please do not top-post] * Pau Amaro-Seoane <[EMAIL PROTECTED]> [2007-12-07 16:11 +0100]: > I must be mentally retarded, but I tried that one and it didn't work > for me... I get always the "To:"... ??? Please corroborate mi IQ I just noted that I don't know a way to avoid the 'To '. I seem to ignore it automatically. Sorry. Nicolas -- http://www.rachinsky.de/nicolas
Re: mailbox close while accessing exchange over imap
Brendan Cully wrote: On Friday, 07 December 2007 at 12:16, Jason Joines wrote: < a0006 OK STATUS completed. mutt_num_postponed: 4 postponed IMAP messages found. > a0007 NOOP Error talking to mail.okstate.edu (Connection reset by peer) imap_cmd_step: Error reading server response. Mailbox closed imap_exec: command failed: If I'm interpreting this correctly, the first NOOP worked. An attempt was made to send a second NOOP but the mail server couldn't be contacted. Looks to me like a connection issue instead of a server issue. What do you think? Jason === I restored my 2s settings and ran the debug version. It does show a successful NOOP every 2s until the "Connection reset by peer" error appears. Even with default settings, sometimes there are several successful NOOPs before the error. It doesn't sound like there's much you can do about this. The server seems to be disconnecting you for some reason. Maybe there's another connection opening up to the same mailbox and your IMAP server doesn't like it? The earlier post by Kyle in this thread suggested running the debug version to see if exchange was failing to recognize the NOOP option as something to keep the mailbox open. The connection stays open a lot longer when I send one every 2 seconds. At the moment the connection has been open for 33 minutes and I have had it stay open for a few hours this way. The logs look to me like the NOOPs are being successful. Your earlier post in this thread pointed me to the FAQ at http://wiki.mutt.org/?MuttFaq/RemoteFolder. Part of the next to last entry says, "There is probably a firewall or NAT router between you and your server which drops connections that don't get traffic frequently enough.". Since my sending more traffic by decreasing the time between imap_keepalive messages since to make the problem better and keeps connections open way beyond the 30 minute time that the server could disconnect me via RFC if it hadn't been told to stay open, I'm leaning toward the FAQ suggestion being correct. I don't think the "connection reset by peer" is an actual reset from the server but a router dropping the connection. I have servers here on the same network but different subnet from the exchange servers. From other locations in the same network I can stay connected via SSH for weeks. However, from outside this network my SSH connections get killed with a "connection reset by peer" message unless I'm actively using the connection. At the same time, those connection from within the same network stay up and running. That along with the IMAP behavior I'm seeing makes me think the network admins have implemented some sort of firewall rule that's affecting both applications. Just wanted to know what some others think before I start pushing on the network and exchange admins. Jason ===
Re: mailbox close while accessing exchange over imap
On Friday, 07 December 2007 at 12:16, Jason Joines wrote: >> < a0006 OK STATUS completed. >> mutt_num_postponed: 4 postponed IMAP messages found. >> > a0007 NOOP >> Error talking to mail.okstate.edu (Connection reset by peer) >> imap_cmd_step: Error reading server response. >> Mailbox closed >> imap_exec: command failed: >> >> >> >> If I'm interpreting this correctly, the first NOOP worked. An >> attempt was made to send a second NOOP but the mail server couldn't be >> contacted. Looks to me like a connection issue instead of a server >> issue. What do you think? >> >> >> Jason >> === > > > > I restored my 2s settings and ran the debug version. It does show a > successful NOOP every 2s until the "Connection reset by peer" error > appears. Even with default settings, sometimes there are several > successful NOOPs before the error. It doesn't sound like there's much you can do about this. The server seems to be disconnecting you for some reason. Maybe there's another connection opening up to the same mailbox and your IMAP server doesn't like it?
Re: mailbox close while accessing exchange over imap
Jason Joines wrote: Jason Joines wrote: Kyle Wheeler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, November 30 at 02:37 PM, quoth Jason Joines: The reason I'm working on this in the first place is someone else reported the same problem with an imap_keepalive=300. So, I set up Mutt to connect to the same exchange server and another instance of Mutt to connect to a Courier IMAP 4.1.3 server that I maintain. There have been no problems with the connection to the Courier server just using Mutt's default settings. Heh, there's a shock: a Microsoft product that plays fast and loose with the IMAP spec. I normally use Thunderbird 2.0 to connect to the same exchange server and have no problems. However, Thunderbird keeps the message index and headers on local disk even for IMAP mail so it just might not be letting me know that the mailbox is being closed by the server. Indeed, it probably isn't. Seriously, if you can fake it to hide the network latency, why bother the user with such pithy details? Mutt only does so because it believes in being more honest about what's really going on rather than in providing a pleasant illusion. ;) (That's one way of putting it, anyway---another would be WYSIWYH.) From the way Mutt reports "Fetching message headers" at startup while it counts through all the messages in my inbox and then displays an empty list when the mailbox goes away, I'm guessing it does not store any sort of index on disk for IMAP messages. Is that correct? For mutt 1.4.x? Correct. That feature has been added to the development version of mutt (1.5.x) and will be in the next stable mutt (1.6), whenever that comes out. Any suggestions for other client side tweaks to help with this problem? I don't administer the exchange server and getting those who do to even reveal any settings, much less change them, will be a nightmare. I guess my first instinct would be to use a *really* low imap_keepalive (like 60), and maybe a timeout value of 1 or something similarly silly and see if that helps. If it doesn't, I'd be curious to try compiling mutt with debugging enabled (reconfigure with --enable-debug) and then run it with a -d2 argument. That will cause it to log (in ~/.muttdebug0) the entire IMAP conversation, so you can see exactly what's going on. If the previous attempts to fix the problem didn't work, my guess would be that mutt is using the IMAP NOOP command to keep the connection alive, and Exchange is not recognizing that as something that keeps the connection alive. But that's just a guess---the log of the IMAP connection would tell you for certain. At that point you can probably easily figure out what mutt is doing and who's doing something wrong. Chances are there's little you can do to really fix the problem, but it's better to know what the problem is for sure first! ~Kyle - -- The surest way to corrupt a youth is to instruct him to hold in higher regard those who think alike than those who think differently. -- Nietzsche -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHUJCtBkIOoMqOI14RAg4yAKCu/NhGMerQ/1b9ZNmkyYdK7d22XACgn34l yfhjUTxptrhVPdzyXyP+0Ek= =6XIl -END PGP SIGNATURE- I started at 256 for timeout, mail_check, imap_keepalive and kept having them every time the problem occured. Now I'm down to 2 and the problem is better but not gone. I am going to try your debug suggestion. However, after reading the FAQ entry and thinking about some other odd behavior I've observed with other applications connecting to stuff managed by the same people, I think it may be a firewall isssue. Jason === I went back to the default settings, tried the debug option and got this output: Mutt 1.4.2.3i started at Fri Dec 7 10:10:31 2007 . Debugging at level 2. mutt_alloc_color(): Color pairs used so far: 1 < * OK Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1 (exfe01.ad.okstate.edu) ready. > a CAPABILITY < * CAPABILITY IMAP4 IMAP4rev1 IDLE LOGIN-REFERRALS MAILBOX-REFERRALS NAMESPACE LITERAL+ UIDPLUS CHILDREN Handling CAPABILITY < a OK CAPABILITY completed. imap_authenticate: Using any available method. Sending LOGIN command for joines... < a0001 OK LOGIN completed. > a0002 LIST "" "" < * LIST (\Noselect) "/" "" < a0002 OK LIST completed. Delimiter: / > a0003 SELECT "INBOX" < * 178 EXISTS Handling EXISTS cmd_handle_untagged: New mail in INBOX - 178 messages total. < * 0 RECENT < * FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent) Getting mailbox FLAGS < * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)] Permanent flags Getting mailbox PERMANENTFLAGS < * OK [UNSEEN 30] Is the first unseen message < * OK [UIDVALIDITY 143157] UIDVALIDITY value < a0003 OK [READ-WRITE] SELECT completed. > a0004 FETCH 1:178 (UID FLAGS INTERNALDATE RFC822.SI
Re: mailbox close while accessing exchange over imap
Jason Joines wrote: Kyle Wheeler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday, November 30 at 02:37 PM, quoth Jason Joines: The reason I'm working on this in the first place is someone else reported the same problem with an imap_keepalive=300. So, I set up Mutt to connect to the same exchange server and another instance of Mutt to connect to a Courier IMAP 4.1.3 server that I maintain. There have been no problems with the connection to the Courier server just using Mutt's default settings. Heh, there's a shock: a Microsoft product that plays fast and loose with the IMAP spec. I normally use Thunderbird 2.0 to connect to the same exchange server and have no problems. However, Thunderbird keeps the message index and headers on local disk even for IMAP mail so it just might not be letting me know that the mailbox is being closed by the server. Indeed, it probably isn't. Seriously, if you can fake it to hide the network latency, why bother the user with such pithy details? Mutt only does so because it believes in being more honest about what's really going on rather than in providing a pleasant illusion. ;) (That's one way of putting it, anyway---another would be WYSIWYH.) From the way Mutt reports "Fetching message headers" at startup while it counts through all the messages in my inbox and then displays an empty list when the mailbox goes away, I'm guessing it does not store any sort of index on disk for IMAP messages. Is that correct? For mutt 1.4.x? Correct. That feature has been added to the development version of mutt (1.5.x) and will be in the next stable mutt (1.6), whenever that comes out. Any suggestions for other client side tweaks to help with this problem? I don't administer the exchange server and getting those who do to even reveal any settings, much less change them, will be a nightmare. I guess my first instinct would be to use a *really* low imap_keepalive (like 60), and maybe a timeout value of 1 or something similarly silly and see if that helps. If it doesn't, I'd be curious to try compiling mutt with debugging enabled (reconfigure with --enable-debug) and then run it with a -d2 argument. That will cause it to log (in ~/.muttdebug0) the entire IMAP conversation, so you can see exactly what's going on. If the previous attempts to fix the problem didn't work, my guess would be that mutt is using the IMAP NOOP command to keep the connection alive, and Exchange is not recognizing that as something that keeps the connection alive. But that's just a guess---the log of the IMAP connection would tell you for certain. At that point you can probably easily figure out what mutt is doing and who's doing something wrong. Chances are there's little you can do to really fix the problem, but it's better to know what the problem is for sure first! ~Kyle - -- The surest way to corrupt a youth is to instruct him to hold in higher regard those who think alike than those who think differently. -- Nietzsche -BEGIN PGP SIGNATURE- Comment: Thank you for using encryption! iD8DBQFHUJCtBkIOoMqOI14RAg4yAKCu/NhGMerQ/1b9ZNmkyYdK7d22XACgn34l yfhjUTxptrhVPdzyXyP+0Ek= =6XIl -END PGP SIGNATURE- I started at 256 for timeout, mail_check, imap_keepalive and kept having them every time the problem occured. Now I'm down to 2 and the problem is better but not gone. I am going to try your debug suggestion. However, after reading the FAQ entry and thinking about some other odd behavior I've observed with other applications connecting to stuff managed by the same people, I think it may be a firewall isssue. Jason === I went back to the default settings, tried the debug option and got this output: Mutt 1.4.2.3i started at Fri Dec 7 10:10:31 2007 . Debugging at level 2. mutt_alloc_color(): Color pairs used so far: 1 < * OK Microsoft Exchange Server 2003 IMAP4rev1 server version 6.5.7638.1 (exfe01.ad.okstate.edu) ready. > a CAPABILITY < * CAPABILITY IMAP4 IMAP4rev1 IDLE LOGIN-REFERRALS MAILBOX-REFERRALS NAMESPACE LITERAL+ UIDPLUS CHILDREN Handling CAPABILITY < a OK CAPABILITY completed. imap_authenticate: Using any available method. Sending LOGIN command for joines... < a0001 OK LOGIN completed. > a0002 LIST "" "" < * LIST (\Noselect) "/" "" < a0002 OK LIST completed. Delimiter: / > a0003 SELECT "INBOX" < * 178 EXISTS Handling EXISTS cmd_handle_untagged: New mail in INBOX - 178 messages total. < * 0 RECENT < * FLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent) Getting mailbox FLAGS < * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \Deleted \Draft $MDNSent)] Permanent flags Getting mailbox PERMANENTFLAGS < * OK [UNSEEN 30] Is the first unseen message < * OK [UIDVALIDITY 143157] UIDVALIDITY value < a0003 OK [READ-WRITE] SELECT completed. > a0004 FETCH 1:178 (UID FLAGS INTERNALDATE RFC822.SIZE BODY.PEEK[HEADER.FIELD
Re: First "fcc-hook" is not more working...
Hi,
* Michelle Konzack wrote:
Hello Rocco,
The problem is definitivly NOT IN MUTT since I get exact the same error
now in one of my scripts usin "egrep"
Here the code sniplet:
8<--
elif `echo "${LINE}" |egrep '^(---|+++) ' >/dev/null` ; then
echo "${ESC}35;40m${LINE}"
8<--
That regex looks perfectly fine to me. I was afraid it was not a mutt
issue since for the alternates case I looked at, the value got read
correctly by mutt and passed straight down to the regex engine without
modification.
The only source of error I can think of is the implementation of regex,
i.e. most likely glibc in your case.
Any ideas?
In general, you could retry with different libc versions. For mutt, you
can compile your own using --with-regex option to configure. That will
compile mutt using a different engine shipped with mutt.
Also creating a minimal test case showing the problem (some text file
and an egrep call) would be useful to file a bug report against your
distribution.
I'm not sure if something like that exists: But you could try to search
your distro docs for updating hints (at least sometimes things breaking
things get documented).
On the other hand, if there's no breakage documented, I can't really
imagine that something crucial as regex breaks already for such simply
patterns since that should be backed by dozens of automated tests...
Rocco
Re: Reliable/safe way of removing empty maildirs?
On Fri, Dec 07, 2007 at 12:18:03PM +, Chris G wrote:
> On Thu, Dec 06, 2007 at 09:05:32PM -0700, Michael Endsley wrote:
> >
> > On Thu, Dec 06, 2007 at 10:28:26PM +, Chris G wrote:
> > > On Thu, Dec 06, 2007 at 09:15:10PM +, A Darren Dunham wrote:
> > > > > >> chmod a-w dir/new
> > > > > >> if [ `find dir -type f` ] ; then
> > > > > >
> > > > > > You have to do something like this instead:
> > > > [snip other responses]
> > > >
> > > > Perhaps I've misunderstood the reason for doing this, but I would just
> > > > ask find to do a rmdir, and let it fail if the directory isn't empty.
> > > >
> > > > find dir -depth -type d -exec rmdir {} \;
> > > >
> > > > If 'dir' is still around when that finishes, it's probably because
> > > > there's a file in there now. In the meantime, it's removed all empty
> > > > subtrees.
> > > >
> > > ... and left an *awful* mess, a maildir mailbox is a directory with
> > > *three* sub-directories in it, you need to check that all three are
> > > empty before removing them.
> > >
> > I needed to empty some subdirectories and this is what I did:
> >
> > du test
> > 4 test/cur
> > 4 test/tmp
> > 4 test/new
> > 16 test
> >
> > Nothing in the test directory, so I deleted it.
> >
> Er, and? I want a command which safely deletes empty maildirs without
> me having to inspect them myself.
>
> --
> Chris Green
Ok, sorry, I missed (or forgot) the original question.
Re: searching in "sent"
I must be mentally retarded, but I tried that one and it didn't work
for me... I get always the "To:"... ??? Please corroborate mi IQ
2007/12/7, Michael Tatge <[EMAIL PROTECTED]>:
> * On Fri, Dec 07, 2007 Pau Amaro-Seoane ([EMAIL PROTECTED]) muttered:
> > I have not found the way of modifying the To: thing. It must be
> > related to $to_chars, but how? Thanks for your answer
> > This is what I have:
> >
> > set index_format="%4C %Z %{%b %d} %-15.15L (%4c) %s"
>
> Change %-15.15L into %-15.15F
>
> %F - author name, or recipient name if the message is from you
> %L - If an address in the To or CC header field matches an address
> defined by the users ``subscribe'' command, this displays "To
> ", otherwise the same as %F.
>
>
> HTH,
>
> Michael
> --
> Linux: the operating system with a CLUE... Command Line User Environment.
> -- seen in a posting in comp.software.testing
>
> PGP-Key-ID: 0xDC1A44DD
> Jabber: [EMAIL PROTECTED]
>
Re: searching in "sent"
* On Fri, Dec 07, 2007 Pau Amaro-Seoane ([EMAIL PROTECTED]) muttered:
> I have not found the way of modifying the To: thing. It must be
> related to $to_chars, but how? Thanks for your answer
> This is what I have:
>
> set index_format="%4C %Z %{%b %d} %-15.15L (%4c) %s"
Change %-15.15L into %-15.15F
%F - author name, or recipient name if the message is from you
%L - If an address in the To or CC header field matches an address
defined by the users ``subscribe'' command, this displays "To
", otherwise the same as %F.
HTH,
Michael
--
Linux: the operating system with a CLUE... Command Line User Environment.
-- seen in a posting in comp.software.testing
PGP-Key-ID: 0xDC1A44DD
Jabber: [EMAIL PROTECTED]
Re: searching in "sent"
This is what I have:
set index_format="%4C %Z %{%b %d} %-15.15L (%4c) %s"
I have not found the way of modifying the To: thing. It must be
related to $to_chars, but how? Thanks for your answer
2007/12/6, Nicolas Rachinsky <[EMAIL PROTECTED]>:
> * Pau Amaro-Seoane <[EMAIL PROTECTED]> [2007-12-06 14:15 +0100]:
> > and yet I would love to get rid of the "To:" thing... I don't have a
> > "From:" in my inbox... it's a word repeated unnecessary as many times
> > as email I have sent... I know I have sent them, it's the SENT
> > folder...
>
> Redefine $index_format in your sent folder.
>
> Nicolas
> --
> http://www.rachinsky.de/nicolas
>
Re: First "fcc-hook" is not more working...
Hello Rocco,
The problem is definitivly NOT IN MUTT since I get exact the same error
now in one of my scripts usin "egrep"
Am 2007-11-30 15:22:54, schrieb Rocco Rutte:
> * Michelle Konzack wrote:
> >8<--
> >[EMAIL PROTECTED]:~/] export LANG=C
> >[EMAIL PROTECTED]:~/] export LC_ALL=C
> >[EMAIL PROTECTED]:~/] mutt
> >Error in /home/michelle.konzack/.mutt/hook-fcc, line 8: Unmatched ( or \(
> >Error in /home/michelle.konzack/.mutt/muttrc, line 18: source: errors in
> >/home/michelle.konzack/.mutt/hook-fcc
> >source: errors in /home/michelle.konzack/.mutt/muttrc
> >8<--
> Oh, please not again. Somebody on IRC had exactly the same problem where
> a 600 byte alternates command wouldn't work and reported a regex error.
> In one mutt version it worked, with a different on a different system it
> didn't for no reason. As in your case, I bet the error is the regex
> engine and not mutt itself.
>
> For the alternates issue, the workaround was to split the pattern at |.
>
> Can you please give system details and see if multiple fcc-hooks work
> (including 'mutt -v | grep REGEX' and the libc version)? Do you have
> other regexes with brackets/OR logic?
>
> I really have no clue what's wrong, thouhg :(
- END OF REPLIED MESSAGE -
Here the code sniplet:
8<--
elif `echo "${LINE}" |egrep '^(---|+++) ' >/dev/null` ; then
echo "${ESC}35;40m${LINE}"
8<--
and if I call my script with:
[ command 'tdfileview --color --inputfile=tdfileview.0201.diff' ]---
[1;36mViewing: /home/michelle.konzack//bin/tdfileview.0201.diff[0m
[1;36mFiletype: RCS/CVS diff output text[0m
[1;36mFilter: 201, diff or patch[0m
[1;36m==[0m
[33mIndex: [30;47mdebian-packages[0m
grep: »)« oder »\)« ohne öffnende Klammer
[0m===
grep: »)« oder »\)« ohne öffnende Klammer
[0m--- debian-packages (revision 2398)
grep: »)« oder »\)« ohne öffnende Klammer
Any ideas?
grep:
Installiert:2.5.1.ds2-5
Mögliche Pakete:2.5.1.ds2-5
Versions-Tabelle:
*** 2.5.1.ds2-5 0
500 cdrom://Etch DVD 1 etch/main Packages
100 /var/lib/dpkg/status
Thanks, Greetings and nice Day
Michelle Konzack
Tamay Dogan Network
Open Hardware Developer
Debian GNU/Linux Consultant
--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
# Debian GNU/Linux Consultant #
Michelle Konzack Apt. 917 ICQ #328449886
50, rue de Soultz MSN LinuxMichi
0033/6/6192519367100 Strasbourg/France IRC #Debian (irc.icq.com)
signature.pgp
Description: Digital signature
Re: Reliable/safe way of removing empty maildirs?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 * Cameron Simpson <[EMAIL PROTECTED]> [12-07-07 01:38]: > Yeah, but without even invoking find: > > rmdir dir/new dir/tmp dir/cur dir \ > || mkdir -p dir/new dir/tmp dir/cur > > Robust, safe, trivial. > > People always seem to forget that rmdir is perfectly safe, in that it > won't remove empty directories. ^^^ *only* removes empty directories :^) ^^^ - -- Patrick Shanahan Plainfield, Indiana, USAHOG # US1244711 http://wahoo.no-ip.org Photo Album: http://wahoo.no-ip.org/gallery2 Registered Linux User #207535@ http://counter.li.org -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (GNU/Linux) iD8DBQFHWUbaClSjbQz1U5oRAhPrAKCKQrp33JBhC8FfaAXL8Geg5tJn3wCgoDkd j0gOrWyGMG/8Qy6kb0OV3pA= =0tkT -END PGP SIGNATURE-
Re: Reliable/safe way of removing empty maildirs?
On Fri, Dec 07, 2007 at 05:37:45PM +1100, Cameron Simpson wrote:
> On 06Dec2007 21:15, A Darren Dunham <[EMAIL PROTECTED]> wrote:
> | > >> chmod a-w dir/new
> | > >> if [ `find dir -type f` ] ; then
> | > >
> | > > You have to do something like this instead:
> | [snip other responses]
> |
> | Perhaps I've misunderstood the reason for doing this, but I would just
> | ask find to do a rmdir, and let it fail if the directory isn't empty.
> |
> | find dir -depth -type d -exec rmdir {} \;
> |
> | If 'dir' is still around when that finishes, it's probably because
> | there's a file in there now. In the meantime, it's removed all empty
> | subtrees.
>
> Yeah, but without even invoking find:
>
> rmdir dir/new dir/tmp dir/cur dir \
> || mkdir -p dir/new dir/tmp dir/cur
>
> Robust, safe, trivial.
>
> People always seem to forget that rmdir is perfectly safe, in that it
> won't remove empty directories.
>
Now that's quite clever! :-) Can anyone see anything wrong with it?
--
Chris Green
Re: Reliable/safe way of removing empty maildirs?
On Thu, Dec 06, 2007 at 09:05:32PM -0700, Michael Endsley wrote:
>
> On Thu, Dec 06, 2007 at 10:28:26PM +, Chris G wrote:
> > On Thu, Dec 06, 2007 at 09:15:10PM +, A Darren Dunham wrote:
> > > > >> chmod a-w dir/new
> > > > >> if [ `find dir -type f` ] ; then
> > > > >
> > > > > You have to do something like this instead:
> > > [snip other responses]
> > >
> > > Perhaps I've misunderstood the reason for doing this, but I would just
> > > ask find to do a rmdir, and let it fail if the directory isn't empty.
> > >
> > > find dir -depth -type d -exec rmdir {} \;
> > >
> > > If 'dir' is still around when that finishes, it's probably because
> > > there's a file in there now. In the meantime, it's removed all empty
> > > subtrees.
> > >
> > ... and left an *awful* mess, a maildir mailbox is a directory with
> > *three* sub-directories in it, you need to check that all three are
> > empty before removing them.
> >
> I needed to empty some subdirectories and this is what I did:
>
> du test
> 4 test/cur
> 4 test/tmp
> 4 test/new
> 16 test
>
> Nothing in the test directory, so I deleted it.
>
Er, and? I want a command which safely deletes empty maildirs without
me having to inspect them myself.
--
Chris Green
