Re: Bash source repository
On Mon, May 30, 2011 at 05:06, Ben Pfaff b...@cs.stanford.edu wrote: Bradley M. Kuhn bk...@ebb.org writes: The new repository contains everything that the current Savannah one does, but I put much more effort into making commits fine-grained, rather than merely importing the public releases blindly. (For example, I did 'git mv' where it was obvious a move occurred, so that changes in file movements were properly tracked historically). Git doesn't track file movement in any way, it just tracks file content. It is git diff and other commands for viewing history that figure out that a file moved, based on the change that occurred. It is a waste of time to use git mv if some other way is easier. More importantly, it is best to move files and commit the results without any other additional content changes occuring simultaneously, so that commands like git diff may figure this out more readily. Perhaps (and hopefully) Bradley meant that file moves were separated from any other content changes that might otherwise have occurred simultaneously. P.S. Ben, it is generally a good idea to maintain the `Cc' list unless explicitly asked.
Re: Bash source repository
Michael Witten wrote at 02:34 (EDT): Perhaps (and hopefully) Bradley meant that file moves were separated from any other content changes that might otherwise have occurred simultaneously. I probably did this in some cases and not others. Anyway, what I've got is clearly better than what's on Savannah, and, as I've mentioned, I'm willing to rebase master if folks produce a better historical archive. -- -- bkuhn
[RFC] support 'COMP_WORDBREAKS' value on a per-completion basis
It seems like if gnu.bash@googlegroups.com eat the first occurrence
of this email (not in the mailman archives)... second attempt:
=== Rationale:
Let's say you want to complete http URL (which contain ':').
The completion probably contains this kind of statement:
_comp() {
COMPREPLY=( $(compgen -W http://foo http://bar; -- $cur) )
}
After the completion function is evaluated, readline will consider
the value of $COMP_WORDBREAKS to split the word to complete...
If the current argument is 'http://', then:
- if $COMP_WORDBREAKS contains ':' , only '//' will be used by the
completion process.
- otherwise (and if ' ' (space) is part of $COMP_WORDBREAKS), the
whole 'http://' string will be used.
The problem is that this evaluation happens after the completion function
has returned (and won't work before $COMP_WORDBREAKS has really been
modified to match our needs):
The FAQ says:
E13) Why does filename completion misbehave if a colon appears in the filename?
and the workaround proposed, ie:
_comp() {
export COMP_WORDBREAKS=${COMP_WORDBREAKS//:/}
COMPREPLY=( $(compgen -W http://foo http://bar; -- $cur) )
}
... has mainly two drawbacks:
1) the completion has to alter the user environment
$ comp http://TAB
$ echo $COMP_WORDBREAKS
'=;|( ### ':' has disappeared, other completion functions
### may suffer from this
2) the first time we try a completion, _comp() has not yet been executed
so our modified $COMP_WORDBREAKS isn't yet part of the context.
$ comp http://TAB
completes (the first time) to
$ comp http:http://
but after that, $COMP_WORDBREAKS is modified so the next calls will succeed.
=== the proposed patch is in 3 parts (also attached):
https://gitorious.org/drzraf/bash/commit/0994f18671dc9c080b01af9c6005a19c7edac17c
Adds a char *word_breaks to the COMPSPEC struct
https://gitorious.org/drzraf/bash/commit/123ba1c50078c0857c489809132cc39ab59d7636
Support of a -B COMP_WORDBREAKS flag to the complete builtin
https://gitorious.org/drzraf/bash/commit/be1ff9edf02d7a28b1a4d18d8e996ef4ba56c490
registers readline 'rl_completion_word_break_hook' and makes the bash
hook returning the value of the complete -B flag if it was
specified during the call to the 'complete' builtin.
===
If the rationale of this patch is accepted, I would be happy to discuss
the possibility to implement it at the 'compopt' level (what I was so far
unable to do) in order to change dynamically word bounds *during* the
completion process.
Raph
From 0994f18671dc9c080b01af9c6005a19c7edac17c Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Droz?= raphael.droz+fl...@gmail.com
Date: Fri, 27 May 2011 14:55:02 +0200
Subject: [PATCH 1/3] added char *word_breaks to the COMPSPEC struct.
It will allow registration of a $COMP_WORDBREAKS equivalent on
a per-completion basis.
---
pcomplete.h |1 +
pcomplib.c |3 +++
2 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/pcomplete.h b/pcomplete.h
index 6c1a664..31ef3cb 100644
--- a/pcomplete.h
+++ b/pcomplete.h
@@ -37,6 +37,7 @@ typedef struct compspec {
char *command;
char *lcommand;
char *filterpat;
+ char *word_breaks;
} COMPSPEC;
/* Values for COMPSPEC actions. These are things the shell knows how to
diff --git a/pcomplib.c b/pcomplib.c
index fe337e4..5d812c7 100644
--- a/pcomplib.c
+++ b/pcomplib.c
@@ -64,6 +64,7 @@ compspec_create ()
ret-command = (char *)NULL;
ret-lcommand = (char *)NULL;
ret-filterpat = (char *)NULL;
+ ret-word_breaks = (char *)NULL;
return ret;
}
@@ -83,6 +84,7 @@ compspec_dispose (cs)
FREE (cs-command);
FREE (cs-lcommand);
FREE (cs-filterpat);
+ FREE (cs-word_breaks);
free (cs);
}
@@ -108,6 +110,7 @@ compspec_copy (cs)
new-command = STRDUP (cs-command);
new-lcommand = STRDUP (cs-lcommand);
new-filterpat = STRDUP (cs-filterpat);
+ new-word_breaks = STRDUP (cs-word_breaks);
return new;
}
--
1.7.3.4
From 123ba1c50078c0857c489809132cc39ab59d7636 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Droz?= raphael.droz+fl...@gmail.com
Date: Fri, 27 May 2011 14:58:01 +0200
Subject: [PATCH 2/3] added support of the -B COMP_WORDBREAKS flag to the 'complete' builtin.
It will allow registration of a $COMP_WORDBREAKS equivalent on
a per-completion basis.
---
builtins/complete.def | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/builtins/complete.def b/builtins/complete.def
index b9f0a13..248cd05 100644
--- a/builtins/complete.def
+++ b/builtins/complete.def
@@ -94,7 +94,7 @@ static void print_compopts __P((const char *, COMPSPEC *, int));
static void print_all_completions __P((void));
static int print_cmd_completions __P((WORD_LIST *));
-static char *Garg, *Warg, *Parg, *Sarg, *Xarg, *Farg, *Carg;
+static char *Garg, *Warg, *Parg, *Sarg, *Xarg, *Farg, *Carg, *Barg;
static const struct _compacts {
const char * const actname;
@@ -193,7 +193,7 @@ build_actions (list, flagp,
[patch] colored filename completion
Hi,
I finished 6 patches which add color to filename completions in
readline.
You'll find them here (651569 to 9cb76f)
http://gitorious.org/drzraf/bash/commits/enhanced-completion
and also attached.
Most of code, more or less modified, comes from the LS_COLORS
(parser / indicator selection) which can be found in
coreutils/src/ls.c.
I wish these patch will be reviewed (and appreciated).
Raph
PS: these patches apply to readline, but the bash mailing-list probably
hosts more testers, please excuse me for crossposting.
From 651569ec2fba50adf5457a854dcfa660e1c62d75 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Droz?= raphael.droz+fl...@gmail.com
Date: Tue, 31 May 2011 00:46:04 +0200
Subject: [PATCH 1/6] Colored completion, readline.h (1/6)
Adds the basic data structures needed by readline
to support the colored output of filename completions.
---
lib/readline/readline.h | 32
1 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/lib/readline/readline.h b/lib/readline/readline.h
index 49b40d3..dc8b29a 100644
--- a/lib/readline/readline.h
+++ b/lib/readline/readline.h
@@ -72,6 +72,32 @@ typedef struct _funmap {
extern FUNMAP **funmap;
+
+/* Null is a valid character in a color indicator (think about Epson
+ printers, for example) so we have to use a length/buffer string
+ type. */
+struct bin_str {
+ size_t len;
+ const char *string;
+};
+
+/* file type indicators (dir, sock, fifo, ...)
+ Default value is initialized in parse-colors.c.
+ It is then modified from the values of $LS_COLORS. */
+extern struct bin_str color_indicator[];
+
+/* The LS_COLORS variable is in a termcap-like format. */
+typedef struct _color_ext_type {
+ struct bin_str ext; /* The extension we're looking for */
+ struct bin_str seq; /* The sequence to output when we do */
+ struct _color_ext_type *next; /* Next in list */
+} COLOR_EXT_TYPE;
+
+/* file extensions indicators (.txt, .log, .jpg, ...)
+ Values are taken from $LS_COLORS in rl_parse_colors().*/
+extern COLOR_EXT_TYPE *_rl_color_ext_list;
+
+
/* */
/* */
/* Functions available to bind to key sequences */
@@ -893,6 +919,12 @@ struct readline_state {
extern int rl_save_state PARAMS((struct readline_state *));
extern int rl_restore_state PARAMS((struct readline_state *));
+/* This is the function which parses the environment variable LS_COLORS
+ to fill _rl_color_ext_list.
+ This is not necessary in order to support basic colorization (file type).
+ But this is needed to add specific colors according to file extension. */
+extern void rl_parse_colors PARAMS((void));
+
#ifdef __cplusplus
}
#endif
--
1.7.3.4
From 8093e98ae8c1fa81ec6037b488ec96eedfd04d1f Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Rapha=C3=ABl=20Droz?= raphael.droz+fl...@gmail.com
Date: Tue, 31 May 2011 00:47:33 +0200
Subject: [PATCH 2/6] Colored completion, core functions (2/6)
Adds the functions to handle colors:
- to parse the LS_COLORS value (termcap format)
- to choose a color according to a file type or a file extension
This is a modified/downstripped version of the colorization code
originally found in coreutils-8.7 (src/ls.c)
---
lib/readline/colors.c | 211 ++
lib/readline/colors.h | 79 +
lib/readline/parse-colors.c | 408 +++
lib/readline/parse-colors.h | 45 +
4 files changed, 743 insertions(+), 0 deletions(-)
create mode 100644 lib/readline/colors.c
create mode 100644 lib/readline/colors.h
create mode 100644 lib/readline/parse-colors.c
create mode 100644 lib/readline/parse-colors.h
diff --git a/lib/readline/colors.c b/lib/readline/colors.c
new file mode 100644
index 000..b2629c1
--- /dev/null
+++ b/lib/readline/colors.c
@@ -0,0 +1,211 @@
+/* `dir', `vdir' and `ls' directory listing programs for GNU.
+ Copyright (C) 1985, 1988, 1990-1991, 1995-2010 Free Software Foundation,
+ Inc.
+
+ 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 3 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, see http://www.gnu.org/licenses/. */
+
+/* Written by Richard Stallman and David MacKenzie. */
+
+/* Color support by Peter Anvin peter.an...@linux.org and Dennis
+ Flaherty denn...@denix.elk.miles.com based on original patches by
+ Greg Lee
