Re: Feature : walkthrough lines of stdout
Just to mention that for urxvt a perl plugin was already posted some
times ago¹. The sad thing is that it has no clue about the semantic of
the last line.
For example you may not want to paste the last line if it's the
prompt. Neither you have the context of the output (the last command
entered).
I think that readline could be a good layer for that since it can easily
guess what was the entered and validated command and I guess that it
knows where the output ends and where the prompt and other things are..
(actually only the bash process parses the line and can consistently
say that in ...
$ x=y ls foo
... the actual command is ls)
And the main uses of grabbing the last line come if we know what was the
command they come from (see the regexp in the attachment...)
The missing bit is probably a link between readline lines (and states)
and the terminal. The later could then provide
API/configuration/key-bindings to reuse the last
line-of-output-really-being-the-output-of-a-command.
Anyway I have no clue about the means by which, if possible, the
terminal could interact with readline or vice versa.
¹ http://lists.schmorp.de/pipermail/rxvt-unicode/2011q4/001494.html
Enhanced version attached
On Wed, Jun 17, 2015 at 04:05:56AM -0700, Hrazel wrote:
Now it would be nice just to log the last lines on stdout and walk it
through line by line ready to be put to the clipboard.
This is a bit different since here you're intending to *walk* along the
(multiple) previous lines, not only splitting the last one.
Still in the urxvt case, you may want to take inspiration from the
url-select extension while assuming a set of word boundary characters.
#! perl
# Author: Raphaël Droz
# Website: http://gitorious.org/~drzraf
# Version: 0.1
# License: GPLv2
# TODO
# use Term::ReadLine::Gnu;
use POSIX ();
sub on_user_command {
my ($self, $cmd) = @_;
if ($cmd eq yank-return:true) {
my ($row, $col) = $self-screen_cur;
my $line = $self-ROW_t ($row - 1);
# TODO: if (readline-previous-command-was-grep)
# and no newline
# and last line was not the prompt
# bash: xxx command not found
if ($line =~ /^bash:\s/) {
$line =~ s/^bash:\s(.*?):\scommand not found\s*/$1/;
$self-tt_write($line);
}
# ls -l (before grep because hours contain :)
elsif ($line =~ /^[ldp-][r-][w-][x-][r-][w-][x-][r-][w-][tx-]\s+/) {
# $line =~
s/^\S+\s+\d+\s+\S+\s+\S+\s+\d+\s+\d+\s+\S+\s+\S+\s+(.*?)\s+$/$1/;
# (in ls -l), these two \d\d may be
# the minutes or the two last digits of the year
$line =~ s/^.*\d\d\s(.*?)\s+$/$1/;
$self-tt_write($line);
}
# unzip
elsif ($line =~ /^\s+inflating:/) {
$line =~ s/^\s+inflating:\s+(.*?)\s+/$1/;
$self-tt_write($line);
}
# dpkg -l
elsif ($line =~ /^(ii|hi|rc)\s+/) {
$line =~ s/^(ii|hi|rc)\s+(.*?)\s+.*/$1/;
$self-tt_write($line);
}
elsif ($line =~ /:/) {
my $login = getlogin;
# prompt: return prev path
if($line =~ /^$login@.*\$\s+$/) {
$line =~ s/^.*?:(.*?)\s[\$#].*$/$1/;
$self-tt_write($line);
}
# grep
else {
# TODO: custom regexp
$line =~ s/^([^:\s]+):.*$/$1/;
$self-tt_write($line);
}
}
# wget
elsif ($line =~ /^\s+$/) {
my $pline = $self-ROW_t ($row - 2);
$pline =~ s/^.*«(.*?)» sauvegardé \[.*$/$1/;
$pline =~ s/^.*'(.*?)' saved \[.*$/$1/;
$pline =~ s/^.*`(.*?)' saved \[.*$/$1/;
$self-tt_write($pline);
}
# any other
else {
$line =~ s/\s+$//;
$self-tt_write($line);
}
}
()
}
4.3 compgen behavior change (quoted arg)
I'm not sure whether or not this is to be expected. $ echo $BASH_VERSION 4.2.42(1)-release $ touch a.log $ compgen -f -X '!*.log' -- \'\' $ $ echo $BASH_VERSION 4.3.0(3)-devel $ touch a.log $ compgen -f -X '!*.log' -- \'\' a.log $ This kind of quoted call is used by bash-completion _filedir I didn't see a change notice in NEWS-4.3 about it. I don't know which behavior is the correct one. regards
Re: devel branch build failure
On Fri, Jan 04, 2013 at 07:12:49PM +0100, Raphaël Droz wrote:
With latest git:
When undefining DEBUG (relstatus=misc in configure.ac), the -devel
branch can't build (4.3.0-devel) :
./parse.y:2199: undefined reference to `itrace'
[...]
trivial patch fixes this.
diff --git a/parse.y b/parse.y
index 98f6264..64c6c2d 100644
--- a/parse.y
+++ b/parse.y
@@ -2196,7 +2196,9 @@ shell_getc (remove_quoted_newline)
/* Let's not let one really really long line blow up memory allocation */
if (shell_input_line shell_input_line_size = 32768)
{
+#ifdef DEBUG
itrace(shell_getc: freeing shell_input_line);
+#endif
free (shell_input_line);
shell_input_line = 0;
shell_input_line_size = 0;
Re: devel branch build failure
With latest git: When undefining DEBUG (relstatus=misc in configure.ac), the -devel branch can't build (4.3.0-devel) : ./parse.y:2199: undefined reference to `itrace' jobs.c:3233: undefined reference to `itrace' jobs.c:2522: undefined reference to `itrace' jobs.c:2745: undefined reference to `itrace' The CHECK_WAIT_INTR macro uses itrace without #ifdef DEBUG. [ quit.h ] Note: When compiling the -devel branch with the correct/default relstatus (-DDEBUG) then, when running the new build, Ctrl+C throws itrace(bash_event_hook); but then Ctrl+C is not usable again. [ newline is needed before Ctrl+C becomes usable again ] There should be a reason for that but this is strange.
devel branch build failure
Hi, using the devel/ branch, linking fails with: bashline.o: In function `attempt_shell_completion': bashline.c:1406: undefined reference to `parser_in_command_position' collect2: ld returned 1 exit status I tried a bissection and c84e5202 was the last one to build fine. But since f14388d (bash-20120914 snapshot), the build fails with the above error. Some of the later revisions also add the failure below: ./builtins/libbuiltins.a(help.o): In function `wdispcolumn': builtins/./help.def:409: undefined reference to `wcsnwidth' builtins/./help.def:449: undefined reference to `wcsnwidth' collect2: ld returned 1 exit statu is this expected ? is there something special about building this branch ? thanks
Re: devel branch build failure
On Wed, Dec 12, 2012 at 09:40:29AM -0500, Chet Ramey wrote: On 12/12/12 8:56 AM, Raphaël Droz wrote: Hi, using the devel/ branch, linking fails with: bashline.o: In function `attempt_shell_completion': bashline.c:1406: undefined reference to `parser_in_command_position' collect2: ld returned 1 exit status I see what happened. git (or the process used to create the devel tree) makes the mod time of all files in the tree the same, so y.tab.c doesn't get rebuilt from parse.y. You can fix this with rm y.tab.? make thanks !
devel/ hangs in globbing
Using the devel/ branch, with default options (simple ./configure), I found that *sourcing* such a script would cause bash to hang using 100% CPU. This does not happen using 4.2_p39. #!/bin/bash shopt -s extglob glob='@(|))' for i in /tmp/!($glob); do echo $i; done [ bash-completion initialisation uses this kind of construct ] regards
Re: in completion, $COMP_WORDBREAKS should be ignored, unless there are no matches
On Wed, May 23, 2012 at 01:11:27PM +0200, Vincent Lefevre wrote: It seems that $COMP_WORDBREAKS annoys users when filenames contain one of its characters: [...] Unsetting $COMP_WORDBREAKS is not a solution, as completion would no longer work in contexts where such characters are word separators. indeed, it's not On Thu, May 24, 2012 at 03:16:40PM -0400, Chet Ramey wrote: The whole raison d'etre for having it in the first place is to allow the user to specify these things. It's easy enough to have COMP_WORDBREAKS only contain whitespace and shell metacharacters. of course but COMP_WORDBREAKS is used in the context of different completion which are kind enough to not alter main user environment. That's why COMP_WORDBREAKS would need to apply in a given context ( like the scope of a function being used as a completion :) ) On Wed, May 23, 2012 at 01:11:27PM +0200, Vincent Lefevre wrote: How about the following behavior when the user types [TAB]? 1. Try to complete the whole word, ignoring $COMP_WORDBREAKS. 2. If there are no matches, take $COMP_WORDBREAKS into account like now. See: https://lists.gnu.org/archive/html/bug-bash/2011-05/msg00148.html [thread follow-up]: https://lists.gnu.org/archive/html/bug-bash/2011-06/msg00032.html The patch in the above thread allowed COMP_WORDBREAKS to be set on a completion basis using a newly created `complete` -B switch. It uses the proper hook for this task but as been considered (probably rightfully) heavyweight. It would needs a strong knowledge of the codebase (and hook definition) in order to add such a feature in an elegant manner. regards
Re: locale specific ordering in EN_US -- why is aAbByYzZ?
On Mon, May 21, 2012 at 12:19:26PM -0700, Linda Walsh wrote: So which is correct? Anyone wanting to reference an upper or lower case range [a-z] or [A-Z], is gonna hurt from this. My OS uses en_US.UTF-8. I don't remember this bug having been cited here: https://bugs.launchpad.net/ubuntu/+source/bash/+bug/120687 About $ export LC_COLLATE=C /etc/skel/.bashrc co
Re: [RFC] support 'COMP_WORDBREAKS' value on a per-completion basis
On Mon, Aug 22, 2011 at 11:22:36AM +0200, Raphaël Droz wrote:
On Thu, Jun 23, 2011 at 10:49:20AM -0400, Chet Ramey wrote:
On 5/30/11 2:05 PM, Raphaël Droz wrote:
=== 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...
The question that comes to mind is whether or not this complication is
worth it. This seems like a pretty heavyweight solution to an
occasional problem with `:'.
would you have any advise to give for a lighter solution ?
Isn't rl_completion_word_break_hook the way to go ?
I still have the two same questions.
I also gave a look at completions and the COMP_WORDBREAKS behavior
disturbs the following completions:
* any URL/host for commands supporting several protocols (colon separated)
* some mount options
* cpan2dist --format option (Perl::module::name)
* setxkbmap -option option
But I can see a workaround which may consist in saving COMP_WORKBREAKS
before the completion is called, and restoring its value (still within
bash) after the completion happened, so that programmable completion can
change its value without trouble. Would it be better ?
Re: [patch] colored filename completion
ping, anyone interested in reviewing/commenting on this ?
Re: [patch] colored filename completion
On Sat, Jun 25, 2011 at 11:56:25PM +0200, Raphaël Droz wrote: On Tue, May 31, 2011 at 01:32:44AM +0200, Raphaël wrote: Hi, I finished 6 patches which add color to filename completions in readline. Those who tried the patch may have noticed (at least) two bugs: [...] * completion of command names was annoying: every match was considered as a missing-file It is (partly) fixed with the attached dont-bug-command-name-completion.patch [...] The lowest common denominator calculation is skipped. [...] three main drawbacks stays after this patch: - duplication is not correct: [...] - aliases, functions, ... and any too abstract command name is still considered as an missing file. (The goal of the patch was just to make the binary in $PATH-case not that abstract). [...] - in the end (print_filename()) priority is given to the filesystem so: Attached is an updated version of dont-bug-command-name-completion.patch. Deduplication is now correct by adding a new qsort() comparison routine which takes care of striping the directory part of the path. Sort of matches is now correct too. The two last drawbacks above are not solved (but are minor).
Re: [patch] colored filename completion
On Sun, Jun 26, 2011 at 05:42:31PM +0200, Raphaël Droz wrote:
Attached is an updated version of dont-bug-command-name-completion.patch.
(really) attached
commit b3572793f7e77bf3ccb4e58121aabe457ddbe39c
Author: Raphaël Droz raphael.droz+fl...@gmail.com
Date: Sat Jun 25 22:55:11 2011 +0200
Colored completion, bugfix (8/6).
When a filename completion needs $PATH traversal (like the
completion of a command name), don't hide the absolute path
of matches to readline.
Fewer matches will be considered as missing files when completing
a command name.
diff --git a/bashline.c b/bashline.c
index 692b912..b2d2e06 100644
--- a/bashline.c
+++ b/bashline.c
@@ -1899,12 +1899,20 @@ globword:
bash execution code won't find executables in directories which
appear in directories in $PATH when they're specified using
relative pathnames. */
- if (match (searching_path ? executable_file (val) :
executable_or_directory (val)))
+ int is_executable_file = 0;
+ if (match (searching_path ? ( is_executable_file = executable_file
(val) ) : executable_or_directory (val)))
#endif
{
- free (val);
- val = ; /* So it won't be NULL. */
- return (temp);
+ if(is_executable_file) {
+ rl_executable_completion_desired = 1;
+ free (temp);
+ return val;
+ }
+ else {
+ free (val);
+ val = ; /* So it won't be NULL. */
+ return (temp);
+ }
}
else
{
diff --git a/lib/readline/complete.c b/lib/readline/complete.c
index 661a5fa..e534bfe 100644
--- a/lib/readline/complete.c
+++ b/lib/readline/complete.c
@@ -317,6 +317,15 @@ int rl_ignore_completion_duplicates = 1;
within a completion entry finder function. */
int rl_filename_completion_desired = 0;
+/* Non-zero means that at least one of the results of the matches is
+ an absolute path. This is ALWAYS zero on entry, and can only be changed
+ within the entry_function callback given to rl_completion_matches.
+ If it is set to a non-zero value the lower common denominator computation
+ will take care of stripping directory names each filename match belongs to.
+ The matches should expect to be processed by printable_part().
+ print_filename() will receive a correct full_pathname parameter. */
+int rl_executable_completion_desired = 0;
+
/* Non-zero means that the results of the matches are to be quoted using
double quotes (or an application-specific quoting mechanism) if the
filename contains any characters in rl_filename_quote_chars. This is
@@ -1144,6 +1153,17 @@ gen_completion_matches (text, start, end, our_func,
found_quote, quote_char)
return matches;
}
+/* Used by compute_lcd_of_matches() and remove_duplicate_matches()
+ when, during the lower common denominator calculation,
+ we have interest in stripping a possible directory part of an
+ absolute path (= if rl_executable_completion_desired 0). */
+static char *possibly_strip_dirname(char *match) {
+ if( rl_executable_completion_desired )
+return printable_part(match);
+ else
+return match;
+}
+
/* Filter out duplicates in MATCHES. This frees up the strings in
MATCHES. */
static char **
@@ -1161,15 +1181,19 @@ remove_duplicate_matches (matches)
/* Sort the array without matches[0], since we need it to
stay in place no matter what. */
- if (i rl_sort_completion_matches)
-qsort (matches+1, i-1, sizeof (char *), (QSFUNC
*)_rl_qsort_string_compare);
+ if (i rl_sort_completion_matches) {
+if(rl_executable_completion_desired)
+ qsort (matches+1, i-1, sizeof (char *), (QSFUNC
*)_rl_qsort_basename_string_compare);
+else
+ qsort (matches+1, i-1, sizeof (char *), (QSFUNC
*)_rl_qsort_string_compare);
+ }
/* Remember the lowest common denominator for it may be unique. */
lowest_common = savestring (matches[0]);
for (i = newlen = 0; matches[i + 1]; i++)
{
- if (strcmp (matches[i], matches[i + 1]) == 0)
+ if (strcmp (possibly_strip_dirname(matches[i]),
possibly_strip_dirname(matches[i + 1])) == 0)
{
xfree (matches[i]);
matches[i] = (char *)dead_slot;
@@ -1202,6 +1226,10 @@ remove_duplicate_matches (matches)
xfree (temp_array[1]);
temp_array[1] = (char *)NULL;
}
+ else if (j == 2 rl_executable_completion_desired ) {
+strcpy (temp_array[0], printable_part(temp_array[1]));
+temp_array[1] = (char *)NULL;
+ }
return (temp_array);
}
@@ -1227,7 +1255,19 @@ compute_lcd_of_matches (match_list, matches, text)
stop matching. */
if (matches == 1)
{
- match_list[0] = match_list[1];
+ /* command name completion requested but one match only was found.
+We forget (and reverse) about the absolute path.
+See bash:command_word_completion_function(). */
+ if(rl_executable_completion_desired == 1
[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,
