[Mutt] #2893: fcc_attach=no should record filenames (like deleted attachments)
#2893: fcc_attach=no should record filenames (like deleted attachments)
{{{
Forwarding to trac so we don't forget it...
- Forwarded message from Louis-David Mitterrand -
Date: Thu, 3 May 2007 17:21:26 +0200
From: Louis-David Mitterrand <[EMAIL PROTECTED]>
To: mutt-dev@mutt.org
Subject: fcc_attach=no improvement suggestion
Hello,
I am following the exciting new rythm of mutt's development and this
leads me to humbly submit an improvement request.
When fcc_attach=no outgoing attachements are not saved in the 'Sent'
mailbox however it would be convenient to have a record of what was
attached at the time it was sent: file path, size and last modification.
This would nicely improve the audit'ability of one's sent mail without
inflating it.
Thanks for your consideration,
- End forwarded message -
}}}
--
Ticket URL:
Re: [PATCH, RFC] mouse tracking support
Hi,
thanks for the comments.
Re: Gary Johnson 2007-05-21 <[EMAIL PROTECTED]>
> I just built the ncurses-5.5 library with --enable-ext-mouse and
> built mutt-1.5.15 with this library and your patch on a machine
> running SunOS 5.8. With the minimal use I've given it so far, it
> seems to work fine.
Thanks.
> I know mutt is intended to be driven from the keyboard, and I much
> prefer using the keyboard to the mouse for almost everything, but I
> run mutt in an xterm window right alongside Firefox (dual-monitor
> display) and with the mouse already in my hand from using Firefox,
> it's just natural to want to click on any new message that arrives
> in mutt.
Same here.
Re: Gary Johnson 2007-05-22 <[EMAIL PROTECTED]>
> I've encountered a few issues with using this patch. None of these
> are bugs, just areas where I think the behavior could be improved.
> The first is an enhancement request. Having gotten used to being
> able to click on a message to open it, I tried clicking in the pager
> mini-index to open one of the messages shown there, but it didn't
> work. It would be nice if the mouse worked there, too.
Should be possible, though harder than the current "mouse keys are
just normal keybindings" approach. (Which only adds one extra
jump-to-message-or-open-if-already-there binding aka .)
> The next issue is probably just a matter of learning new habits, but
> with this patch it is no longer possible to select text in a message
> using just the mouse--you have to hold the shift key while selecting
> text.
That's a xterm/ncurses issue. The only way around is probably vim-like
internal mouse handling. I admit that's the reason I don't use vim's
mouse handling, but I might get used to it for mutt.
> The last issue is becoming quite an annoyance and I think the
> behavior should be changed. When the index fills only the top of
> the screen, clicking anywhere in the empty space below the last
> message selects the last message. This is a problem when you have
> overlapping windows, mutt is running in a partially-hidden window,
> and you click in an empty area of the window in order to bring it to
> the foreground. If the indicator is already on the last message,
> clicking in that empty area will also open the message.
Easy to fix, should be:
+void menu_mouse_click (MUTTMENU *menu, int op)
+{
+ int click = LastY + menu->top - menu->offset;
+ if (click < 0)
+click = 0;<-- return;
+ if (click >= menu->max)
+click = menu->max -1; <-- return;
+ if (click == menu->current) {
+mutt_ungetch(0, op);
+ } else {
+menu->current = click;
+menu->redraw = REDRAW_MOTION;
+ }
+}
> I think
> this should be changed so that clicking in that area has no effect,
> or scrolls the index down as '<' would, but does not open any
> message.
Btw, one cool side-effect of using menu_context with mouse tracking is
that clicking into the "context" area will cause the screen to scroll.
One idea I had was to have more jump-and-$something features, e.g.
using right-clicks in the index for tagging. I thought about a generic
"mouse-" prefix for all operations that would cause them to do
reasonable actions but it seemed too intrusive for the first version
of the patch.
Christoph
[PATCH] Support for reading users and/or passwords from netrc(5)
# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1179848062 -3600
# Node ID 0a3bb46d1d5ee19199f2f7170cfdd16a46cb3553
# Parent 357b7651d6095f5b2e9c5dab1e4cb5c7fb6bc379
Support for reading users and/or passwords from netrc(5)
Extended mutt_account_getuser and mutt_account_getpass in account.c with
netrc_user and netrc_password for retrieving username and password from
~/.netrc.
netrc(5) parsing was added in new files netrc.c and netrc.h.
diff -r 357b7651d609 -r 0a3bb46d1d5e Makefile.am
--- a/Makefile.am Tue May 22 16:11:15 2007 +0100
+++ b/Makefile.am Tue May 22 16:34:22 2007 +0100
@@ -28,7 +28,7 @@ mutt_SOURCES = $(BUILT_SOURCES) \
rfc822.c rfc1524.c rfc2047.c rfc2231.c rfc3676.c \
score.c send.c sendlib.c signal.c sort.c \
status.c system.c thread.c charset.c history.c lib.c \
- muttlib.c editmsg.c mbyte.c \
+ muttlib.c editmsg.c mbyte.c netrc.c \
url.c ascii.c mutt_idna.c crypt-mod.c crypt-mod.h
mutt_LDADD = @MUTT_LIB_OBJECTS@ @LIBOBJS@ $(LIBIMAP) $(MUTTLIBS) \
diff -r 357b7651d609 -r 0a3bb46d1d5e account.c
--- a/account.c Tue May 22 16:11:15 2007 +0100
+++ b/account.c Tue May 22 16:34:22 2007 +0100
@@ -25,6 +25,7 @@
#include "mutt.h"
#include "account.h"
#include "url.h"
+#include "netrc.h"
/* mutt_account_match: compare account info (host/port/user/login) */
int mutt_account_match (const ACCOUNT* a1, const ACCOUNT* a2)
@@ -158,6 +159,10 @@ int mutt_account_getuser (ACCOUNT* accou
else if ((account->type == M_ACCT_TYPE_POP) && PopUser)
strfcpy (account->user, PopUser, sizeof (account->user));
#endif
+ else if (netrc_user (account->host,
+ account->user, sizeof (account->user),
+ account->pass, sizeof (account->pass)))
+ ;
/* prompt (defaults to unix username), copy into account->user */
else
{
@@ -218,6 +223,11 @@ int mutt_account_getpass (ACCOUNT* accou
else if ((account->type == M_ACCT_TYPE_SMTP) && SmtpPass)
strfcpy (account->pass, SmtpPass, sizeof (account->pass));
#endif
+ else if (netrc_password (account->flags & M_ACCT_LOGIN
+ ? account->login : account->user,
+ account->host,
+ account->pass, sizeof (account->pass)))
+ ;
else
{
snprintf (prompt, sizeof (prompt), _("Password for [EMAIL PROTECTED]: "),
diff -r 357b7651d609 -r 0a3bb46d1d5e netrc.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/netrc.c Tue May 22 16:34:22 2007 +0100
@@ -0,0 +1,322 @@
+/*
+ * Copyright (C) 2007 Luciano Rocha <[EMAIL PROTECTED]>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301, USA.
+ */
+
+/* netrc(5) parsing support */
+
+#if HAVE_CONFIG_H
+# include "config.h"
+#endif
+
+/* for isspace(c) */
+#include
+
+#include "mutt.h"
+#include "netrc.h"
+
+/* token types */
+enum
+{
+ M_NETRC_TOK_DEFAULT,
+ M_NETRC_TOK_MACHINE,
+ M_NETRC_TOK_LOGIN,
+ M_NETRC_TOK_PASSWORD,
+ M_NETRC_TOK_ACCOUNT,
+ M_NETRC_TOK_MACRO,
+ M_NETRC_TOK_UNKNOWN
+};
+
+/* tokens and their values */
+typedef struct {
+ int type;
+ char *value1;
+ int len1;
+ char *value2;
+ int len2;
+} TOKEN;
+
+/* open netrc */
+static FILE *netrc_open (void)
+{
+ char path[_POSIX_PATH_MAX];
+
+ snprintf (path, sizeof (path), "%s/.netrc", NONULL(Homedir));
+ return fopen (path, "r");
+}
+
+/* clean tok structure and free any alloced data */
+static void netrc_free_tok (TOKEN *tok)
+{
+ if (tok->value1)
+ free (tok->value1);
+ if (tok->value2)
+ free (tok->value2);
+ tok->value1 = tok->value2 = NULL;
+ tok->len1 = tok->len2 = 0;
+}
+
+/* read next token from netrc and its values */
+static int netrc_next_tok (FILE *fp, TOKEN *tok)
+{
+ char token[40];
+ char value[256];
+ int c, i;
+
+ netrc_free_tok (tok);
+
+ /* skip whitespace */
+ while ((c = getc (fp)) != EOF && isspace (c));
+ if (c == EOF)
+ return 0;
+
+ /* get token (text till next whitespace) */
+ token[0] = (char) c;
+ i = 1;
+ while ((c = getc (fp)) != EOF && !isspace (c)
+ && i < (sizeof token - 1)
Re: [PATCH] Support for reading users and/or passwords from
On Wednesday, May 23 at 05:16 PM, quoth Luciano Rocha: Support for reading users and/or passwords from netrc(5) Extended mutt_account_getuser and mutt_account_getpass in account.c with netrc_user and netrc_password for retrieving username and password from ~/.netrc. ...according to my netrc(5) man pages, ~/.netrc is specific to ftp. Why is fetching information out of it and using it for email a good idea? ~Kyle -- Never think that war, no matter how necessary, no matter how justified, is not a crime. -- Ernest Hemingway pgphRA71KPoGw.pgp Description: PGP signature
[PATCH] when using `which` send errors to /dev/null
# HG changeset patch # User [EMAIL PROTECTED] # Date 1179846675 -3600 # Node ID 357b7651d6095f5b2e9c5dab1e4cb5c7fb6bc379 # Parent 516f41633e202184e897bef24a6d9f17bba7c0ba when using `which` send errors to /dev/null diff -r 516f41633e20 -r 357b7651d609 hcachever.sh --- a/hcachever.sh Sun May 20 00:31:19 2007 -0700 +++ b/hcachever.sh Tue May 22 16:11:15 2007 +0100 @@ -2,13 +2,13 @@ BASEVERSION=1 -if test -x "`which md5`" +if test -x "`which md5 2> /dev/null`" then MD5=md5 -elif test -x "`which md5sum`" +elif test -x "`which md5sum 2> /dev/null`" then MD5=md5sum -elif test -x "`which openssl`" +elif test -x "`which openssl 2> /dev/null`" then MD5="openssl md5 -hex" else pgpbZZEpZK8iz.pgp Description: PGP signature
Re: [PATCH] when using `which` send errors to /dev/null
=- Luciano Rocha wrote on Wed 23.May'07 at 18:48:01 +0100 -=
> when using `which` send errors to /dev/null
> {...}
> -if test -x "`which md5`"
> +if test -x "`which md5 2> /dev/null`"
On solaris 8 which produces noise on STDOUT, not STDERR.
Maybe the attached version suits all.
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
--- morg/hcachever.sh Fri Apr 6 09:00:11 2007
+++ mgo/hcachever.shWed May 23 20:07:50 2007
@@ -2,6 +2,7 @@
BASEVERSION=1
+{
if test -x "`which md5`"
then
MD5=md5
@@ -12,9 +13,10 @@
then
MD5="openssl md5 -hex"
else
- echo "ERROR: no MD5 tool found"
+ echo "ERROR: no MD5 tool found" >&3
exit 1
fi
+} >>/dev/null 2>&1 3>&2
cleanstruct () {
echo "$1" | sed -e 's/} *//' -e 's/;$//'
Re: [PATCH] Support for reading users and/or passwords from
On Wed, May 23, 2007 at 11:42:21AM -0600, Kyle Wheeler wrote: > On Wednesday, May 23 at 05:16 PM, quoth Luciano Rocha: >> Support for reading users and/or passwords from netrc(5) >> >> Extended mutt_account_getuser and mutt_account_getpass in account.c with >> netrc_user and netrc_password for retrieving username and password from >> ~/.netrc. > > ...according to my netrc(5) man pages, ~/.netrc is specific to ftp. Why is > fetching information out of it and using it for email a good idea? Well, for starters, it isn't called .ftprc. =) But wget (including http auth), fetchmail, some scripts I made and some other utilities use it. And as I use fetchmail extensively, I really didn't want to keep passwords in two or more different places. $ find /usr/share/man/ -name \*.gz | xargs zgrep -F .netrc -l /usr/share/man/man3/curl_easy_setopt.3.gz /usr/share/man/man3/rexec.3.gz /usr/share/man/man3/libcurl-tutorial.3.gz /usr/share/man/man3/Net::Netrc.3pm.gz /usr/share/man/man1/rexec.1.gz /usr/share/man/man1/curl.1.gz /usr/share/man/man1/perltoc.1.gz /usr/share/man/man1/fetchmail.1.gz /usr/share/man/man1/mkxauth.1x.gz /usr/share/man/man1/pftp.1.gz /usr/share/man/man1/ftp.1.gz /usr/share/man/man1/lftp.1.gz /usr/share/man/man1/wget.1.gz /usr/share/man/man5/netrc.5.gz Not many, and maybe using it outside of ftp goes against some standard practice, but I wanted that functionality, implemented, and maybe it will be useful for someone else. -- lfr 0/0 pgp5HV9XvyzrK.pgp Description: PGP signature
Re: [PATCH] Support for reading users and/or passwords from
On Wednesday, May 23 at 07:15 PM, quoth Luciano Rocha:
...according to my netrc(5) man pages, ~/.netrc is specific to ftp.
Why is fetching information out of it and using it for email a good
idea?
Well, for starters, it isn't called .ftprc. =)
HEH. Fair enough, but still, it's not exactly someplace that's
*expected*.
And as I use fetchmail extensively, I really didn't want to keep
passwords in two or more different places.
Well, strictly speaking, you don't have to. You could, for example,
have this in your muttrc:
set imap_user=`awk '/^login/{print $2}' ~/.netrc`
set imap_pass=`awk '/^password/{print $2}' ~/.netrc`
set folder="imaps://`awk '/^machine/{print $2}' ~/.netrc`/INBOX"
(or, if you have multiple entries in your netrc, you may want to use
something more complicated, like a little perl script to extract all
the right information out of it)
Not many, and maybe using it outside of ftp goes against some
standard practice, but I wanted that functionality, implemented, and
maybe it will be useful for someone else.
Fair enough.
~Kyle
--
Truth springs from argument amongst friends.
-- David Hume
pgpHeQJzvHipl.pgp
Description: PGP signature
Re: [PATCH] when using `which` send errors to /dev/null
* On 2007.05.23, in <[EMAIL PROTECTED]>,
* "Rado S" <[EMAIL PROTECTED]> wrote:
> =- Luciano Rocha wrote on Wed 23.May'07 at 18:48:01 +0100 -=
>
> > when using `which` send errors to /dev/null
> > {...}
> > -if test -x "`which md5`"
> > +if test -x "`which md5 2> /dev/null`"
>
> On solaris 8 which produces noise on STDOUT, not STDERR.
> Maybe the attached version suits all.
Is the problem with irregular behavior of different whiches? Which is
convenient but besides this has the drawback that since it's almost
always a csh script, it sometimes returns csh aliases and such instead
of what you really want.
It's easy enough to add a which-like command though.
where ()
{
echo $PATH | tr : '\012' | while read dir; do
[ -x "$dir/$1" -a ! -d "$dir/$1" ] && echo "$dir/$1" && return 0
## "return 0" returns from the do/done subshell, not the
## function. "false" here ensures that a "where" that does not
## find the program returns false at end.
false
done
}
{ MD5=`where md5` } ||
{ MD5=`where md5sum` } ||
{ MD5=`where openssl` && MD5="$MD5 md5 -hex"; } ||
{ echo No md5 found.; exit 1; }
--
-D.[EMAIL PROTECTED], NSITUniversity of Chicago
Re: [PATCH, RFC] mouse tracking support
On 2007-05-23, Christoph Berg <[EMAIL PROTECTED]> wrote:
> Re: Gary Johnson 2007-05-22 <[EMAIL PROTECTED]>
> > I've encountered a few issues with using this patch. None of these
> > are bugs, just areas where I think the behavior could be improved.
> > The next issue is probably just a matter of learning new habits, but
> > with this patch it is no longer possible to select text in a message
> > using just the mouse--you have to hold the shift key while selecting
> > text.
>
> That's a xterm/ncurses issue. The only way around is probably vim-like
> internal mouse handling. I admit that's the reason I don't use vim's
> mouse handling, but I might get used to it for mutt.
Now that I've thought about it more, I'm not sure that adding
vim-like internal selections is worth the effort. Besides, I
sometimes select text from the index, in which case I might have to
hold the shift key anyway. I just read that gaim-text (now Finch)
has this issue when their mouse feature is enabled, and their FAQ
says to use the shift key. In w3m, you can use the mouse for
scrolling, and if "we" ever wanted to add such a feature to mutt,
we'd have to give up internally handling selections anyway. To
select text in w3m, one has to use the shift key, too.
So, I think I can get used to holding the shift key for selections.
> > The last issue is becoming quite an annoyance and I think the
> > behavior should be changed. When the index fills only the top of
> > the screen, clicking anywhere in the empty space below the last
> > message selects the last message. This is a problem when you have
> > overlapping windows, mutt is running in a partially-hidden window,
> > and you click in an empty area of the window in order to bring it to
> > the foreground. If the indicator is already on the last message,
> > clicking in that empty area will also open the message.
>
> Easy to fix, should be:
>
> +void menu_mouse_click (MUTTMENU *menu, int op)
> +{
> + int click = LastY + menu->top - menu->offset;
> + if (click < 0)
> +click = 0;<-- return;
> + if (click >= menu->max)
> +click = menu->max -1; <-- return;
> + if (click == menu->current) {
> +mutt_ungetch(0, op);
> + } else {
> +menu->current = click;
> +menu->redraw = REDRAW_MOTION;
> + }
> +}
That works nicely. Thank you.
> > I think
> > this should be changed so that clicking in that area has no effect,
> > or scrolls the index down as '<' would, but does not open any
> > message.
>
> Btw, one cool side-effect of using menu_context with mouse tracking is
> that clicking into the "context" area will cause the screen to scroll.
Yes, I discovered that.
> One idea I had was to have more jump-and-$something features, e.g.
> using right-clicks in the index for tagging. I thought about a generic
> "mouse-" prefix for all operations that would cause them to do
> reasonable actions but it seemed too intrusive for the first version
> of the patch.
W3m has a menu of commonly-used functions that pops up with a
right-click. Having such a menu, especially if users could
configure the contents, would avoid users having to choose only
function to bind to the right mouse button.
I agree that just having the mouse working at all is enough for now.
Thanks again for doing this. I wish I had more time to help.
Regards,
Gary
--
Gary Johnson | Agilent Technologies
[EMAIL PROTECTED] | Mobile Broadband Division
http://www.spocom.com/users/gjohnson/mutt/ | Spokane, Washington, USA
Re: [PATCH] when using `which` send errors to /dev/null
On Wed, May 23, 2007 at 01:33:56PM -0500, David Champion wrote:
> * On 2007.05.23, in <[EMAIL PROTECTED]>,
> * "Rado S" <[EMAIL PROTECTED]> wrote:
> > =- Luciano Rocha wrote on Wed 23.May'07 at 18:48:01 +0100 -=
> >
> > > when using `which` send errors to /dev/null
> > > {...}
> > > -if test -x "`which md5`"
> > > +if test -x "`which md5 2> /dev/null`"
> >
> > On solaris 8 which produces noise on STDOUT, not STDERR.
> > Maybe the attached version suits all.
>
> Is the problem with irregular behavior of different whiches? Which is
> convenient but besides this has the drawback that since it's almost
> always a csh script, it sometimes returns csh aliases and such instead
> of what you really want.
>
> It's easy enough to add a which-like command though.
>
What about stopping to find where the binary is and check only if it can
be run?
if echo | md5sum &> /dev/null; then
MD5=md5sum
elif echo | md5 &> /dev/null; then
MD5=md5
elif echo | openssl md5 -hex &> /dev/null; then
MD5="openssl md5 -hex"
else
echo No md5 found 1>&2
exit 1
fi
--
lfr
0/0
pgpfKXiLhE6eZ.pgp
Description: PGP signature
Re: [PATCH] when using `which` send errors to /dev/null
=- Luciano Rocha wrote on Wed 23.May'07 at 20:22:32 +0100 -=
> > It's easy enough to add a which-like command though.
>
> What about stopping to find where the binary is and check only if it can
> be run?
> if echo | md5sum &> /dev/null; then
> MD5=md5sum
> elif echo | md5 &> /dev/null; then
> MD5=md5
> elif echo | openssl md5 -hex &> /dev/null; then
> MD5="openssl md5 -hex"
> else
> echo No md5 found 1>&2
> exit 1
> fi
You still put redirects for each test.
With the {} capturing any future cases as well as localized
deviations where the noise is sent (err-out) will be taken care of.
--
© Rado S. -- You must provide YOUR effort for your goal!
EVERY effort counts: at least to show your attitude.
You're responsible for ALL you do: you get what you give.
Re: [PATCH] when using `which` send errors to /dev/null
On Wed, May 23, 2007 at 10:01:37PM +0200, Rado S wrote:
> =- Luciano Rocha wrote on Wed 23.May'07 at 20:22:32 +0100 -=
>
> > > It's easy enough to add a which-like command though.
> >
> > What about stopping to find where the binary is and check only if it can
> > be run?
> > if echo | md5sum &> /dev/null; then
> > MD5=md5sum
> > elif echo | md5 &> /dev/null; then
> > MD5=md5
> > elif echo | openssl md5 -hex &> /dev/null; then
> > MD5="openssl md5 -hex"
> > else
> > echo No md5 found 1>&2
> > exit 1
> > fi
>
> You still put redirects for each test.
> With the {} capturing any future cases as well as localized
> deviations where the noise is sent (err-out) will be taken care of.
If you prefer { ... } 3>&2 &> /dev/null, then by all means. I,
personally, prefer the format I presented.
Anyway, the following is wrong:
} >>/dev/null 2>&1 3>&2
As it sets stdout to /dev/null, stderr to stdout, and fd 3 to stderr,
that by now is /dev/null.
} 3>&2 > /dev/null 2>&1 (or 3>&2 &> /dev/null) should work instead.
--
lfr
0/0
pgphCD259nU4z.pgp
Description: PGP signature
Re: when using `which` send errors to /dev/null
On 23May2007 13:33, David Champion <[EMAIL PROTECTED]> wrote:
| Is the problem with irregular behavior of different whiches?
I've never trusted it even to exist everywhere:-)
| Which is
| convenient but besides this has the drawback that since it's almost
| always a csh script, it sometimes returns csh aliases and such instead
| of what you really want.
|
| It's easy enough to add a which-like command though.
|
| where ()
Yes! I'd run with this myself.
| {
| echo $PATH | tr : '\012' | while read dir; do
This is more robustly written:
printf "%s\n" "$PATH" | tr : '\012' | while read -r dir; do
Unless that breaks on Solaris, which it may:-(
| [ -x "$dir/$1" -a ! -d "$dir/$1" ] && echo "$dir/$1" && return 0
|
| ## "return 0" returns from the do/done subshell, not the
| ## function. "false" here ensures that a "where" that does not
| ## find the program returns false at end.
| false
This is not necessary. The last loop iteration will get false from the
"read" condition of the while, and so the subshell will exit non-zero
anyway.
--
Cameron Simpson <[EMAIL PROTECTED]> DoD#743
http://www.cskk.ezoshosting.com/cs/
If you can keep your head while all those about you are losing theirs,
perhaps you don't understand the situation.
- Paul Wilson <[EMAIL PROTECTED]>
Re: when using `which` send errors to /dev/null
On 23May2007 20:22, Luciano Rocha <[EMAIL PROTECTED]> wrote: | if echo | md5sum &> /dev/null; then "&>" is not portable. It's a bastard import into bash from csh:-( Just go ">/dev/null 2>&1". Portable and just as readable. -- Cameron Simpson <[EMAIL PROTECTED]> DoD#743 http://www.cskk.ezoshosting.com/cs/ Courage is not the absence of fear, but rather the judgment that something else is more important than fear. - Ambrose Redmoon
Re: [PATCH, RFC] mouse tracking support
On Monday, May 21 at 12:39 PM, quoth Kyle Wheeler: On Monday, May 21 at 07:15 PM, quoth Christoph Berg: I've updated Anatoly's patch from 2005 that adds mouse tracking using slang/ncurses to mutt. With "set mouse" (unset by default) mutt will react to button1/2/3/wheel with configurable bindings. I like it :) Oooo! I'll test it when I get home from work, but I love the concept! Hrm; having trouble getting it to work on MacOS X. I thought I compiled both ncurses and ncursesw with --enable-ext-mouse; is there a way of testing? ~Kyle -- In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. -- Douglas Adams pgp5pMWltimaS.pgp Description: PGP signature
Re: when using `which` send errors to /dev/null
* On 2007.05.23, in <[EMAIL PROTECTED]>, * "Cameron Simpson" <[EMAIL PROTECTED]> wrote: > > printf "%s\n" "$PATH" | tr : '\012' | while read -r dir; do > > Unless that breaks on Solaris, which it may:-( I don't think -r is present in a strict Bourne shell's "read". Solaris's gives "-r: is not an identifier", but I don't expect that it's limited to Solaris. -- -D.[EMAIL PROTECTED], NSITUniversity of Chicago
Re: when using `which` send errors to /dev/null
On 23May2007 21:21, David Champion <[EMAIL PROTECTED]> wrote: | * On 2007.05.23, in <[EMAIL PROTECTED]>, | * "Cameron Simpson" <[EMAIL PROTECTED]> wrote: | > printf "%s\n" "$PATH" | tr : '\012' | while read -r dir; do | > Unless that breaks on Solaris, which it may:-( | | I don't think -r is present in a strict Bourne shell's "read". | Solaris's gives "-r: is not an identifier", but I don't expect that it's | limited to Solaris. I think it's POSIX standard, but not SysV Bourne shell (sorry, no chapter and verse to hand). Solaris ships with the latter as /bin/sh. But as you point out, a single exception may be enough. -- Cameron Simpson <[EMAIL PROTECTED]> DoD#743 http://www.cskk.ezoshosting.com/cs/ "I think I've just made the biggest mistake of my life."- Villa "That seems unlikely. I would predict that there are far greater mistakes waiting to be made by someone of your obvious talent for them."- Orac
Re: when using `which` send errors to /dev/null
* Cameron Simpson wrote on Thu, May 24, 2007 at 01:31:31AM CEST:
> On 23May2007 13:33, David Champion <[EMAIL PROTECTED]> wrote:
>
> | {
> | echo $PATH | tr : '\012' | while read dir; do
>
> This is more robustly written:
>
> printf "%s\n" "$PATH" | tr : '\012' | while read -r dir; do
And even more robustly (and faster!) written like this:
save_IFS=$IFS
IFS=:
for dir in $PATH; do
IFS=$save_IFS
...
done
IFS=$save_IFS
Cheers,
Ralf
Re: [PATCH] when using `which` send errors to /dev/null
On Wed, May 23, 2007 at 10:55:25PM +0100, Luciano Rocha wrote:
>
> } 3>&2 > /dev/null 2>&1 (or 3>&2 &> /dev/null) should work instead.
Except that &> isn't posix-compliant shell syntax (it is from csh), and
isn't supported by all shells.
Also, since the redirection of {...} will enforce a subshell (at least
on some shells), requesting it explicitly by using (...) is better.
Also a conformat posix shell should have a 'type' command, and 'command -v'
which are builtins that report the location of programs.
David
--
David Laight: [EMAIL PROTECTED]
