Re: [Bash-completion-devel] Namespace
+1 for BASHCOMP_* for the setting variables (maybe we can also support a '.bashcomprc' file to allow a user to get rid of the globals)? Side-looking at this git-completion-thread (http://git.661346.n2.nabble.com/Custom-git-completion-td4479814.html), they're using: _git_foo: for completing `git foo' __git_foo: for public/private functions How are we going to rename the completion functions, for example _cd: _bc_cd? This would mean ideally we're giving away the _bc_* namespace to API users (completion writers). So we'd better leave the _bc_* namespace for completions only and revert to uppercase or two underscores for library functions? What namespace can completion writers safely use for helper functions? _bc_foo_*? Using two underscores for public API functions and three underscores for private is getting confusing I think, so I like the idea of using uppercase _BC_ for public. Maybe we'd better use __BC_ (two underscores and uppercase) for private library functions as well so that __bc_ is also free for completion writers (what are the chances of acroread creating a _bc_filedir or __bc_filedir where they ideally should use _bc_acroread_filedir?). Summary: Completion functions: _bc_* Helper functions for specific completion (foo): _bc_foo_* Public API functions: _BC_* Private functions and private non-local variables: __BC_* Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Dynamic completion loader.
On 110409 13:51, Ville Skyttä wrote: So, given the answers so far, should we add a drop bash 4.1 support roadmap item, and already for 2.0 (my answer would be yes, and +1)? I Yes and +1 ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. c86b336769cdc025a63c13bf3448ce5d5019a563
On 101119 21:44, Ville Skyttä wrote: Yep, all unit tests pass again here now. Thanks. Great. I'm having trouble with `completion/ssh.exp' though, I'm looking into that now. I'll try to rewrite the passing of optional parameters as done in `match_items()' to avoid the use of eval in tcl if $args need to be passed between functions. Then there are still some test suite improvements of Leonard Crestez in the expect-fixes branch I'd like to integrate in master. Greetings, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. c86b336769cdc025a63c13bf3448ce5d5019a563
I've made `match_items()' to match on the bash-prompt in commit 11da957. Can you give this a try? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. c86b336769cdc025a63c13bf3448ce5d5019a563
Comparing the logs, I can see your `expect' is matching chunks (i.e. more than one letter at once) whereas my `expect' is comparing one letter at a time. This might be because I'm running the tests on a slow machine. This difference causes a match - for example ^1$ - to pass my `expect', but to fail yours because it's receiving ^1/@$ before it gets a chance to compare a ^1$. I've changed this: Function `assert_bash_list()' is expecting a newline terminated list, whereas `_count_args()' erroneously returned NO newline, using an echo -n. This was of no problem on my machine, but nevertheless wrong and probably causing the failures on your machine. I removed the -n from the echo. Do the _count_args tests pass on your machine now? If not, probably the prompt is included in the result (^1\r\n/@$), before match_items() can match on ^1\r\n$. If that's the case, the fix might be to let `match_items()' also match on an (optional) subsequent bash-prompt. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. c86b336769cdc025a63c13bf3448ce5d5019a563
On 101115 20:46, Ville Skyttä wrote: ... Attached is the complete log/unit.log for a ./runUnit _count_args.exp run which finished with: ... I have the same output, only with PASSes (and ^M's): ... /@COMP_WORDS=(a b); COMP_CWORD=1; COMP_LINE='a b'; COMP_POINT=3; _count_args; echo -n $args^M 1/@PASS: a b| should set args to 1 ^C^M /@COMP_WORDS=(a bc); COMP_CWORD=1; COMP_LINE='a bc'; COMP_POINT=3; _count_args; echo -n $args^M 1/@PASS: a b|c should set args to 1 ^C^M ... Looks like we have to dig deeper. What's your output of `dbg.log' after doing: ./runUnit _count_args.exp --debug Mine is pasted here: http://paste2.org/p/1092035 after doing: ./runUnit _count_args.exp --tool_exec /opt/bash-4.1/bin/bash --debug ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. c86b336769cdc025a63c13bf3448ce5d5019a563
On 101113 11:04, Ville Skyttä wrote: Cool, work on make (dist)check is appreciated. But (seemingly) all unit tests are failing for me now, both when run with runUnit and with make check. Both runUnit and `make check' running fine here. What is the error message exactly? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] using external helpers for completion
On 101101 09:10, Ville Skyttä wrote: I suppose something like SUBDIRS = helpers in completions/Makefile.am would fix installing the helper (untested). Yes, that seems to fix it. I've added strengthen use of GNU Autotools (add to README, fix `make distcheck`) to the roadmap as an objective for version 2.0. Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Removal of quot; -o filenamesquot; to quot; completequot;
Ville Skyttä ville.skytta at iki.fi writes: The notification mail for a change I just committed is being held for moderator approval for the commits list due to its size, so here's a separate heads up about it: http://git.debian.org/?p=bash-completion/bash- completion.git;a=commitdiff;h=0f450219b667ec5f8d951b0c41593c7b983e2ada I've been running with this locally for a while, ironing out issues, and am not aware of any real regressions any more. I haven't been able to test every single command, so please keep an eye on things that were previously escaped as filenames and should still be, but no longer are. I had one test failing with the new _compopt_o_filenames, on both bash-3 and bash-4: Running ./completion/ls.exp ... FAIL: ~part should complete to ~full I think it is fixed by adding a call to _compopt_o_filenames within _tilde, see commit dfb8406. Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Removal of quot; -o filenamesquot; to quot; completequot;
On 101103 21:23, Ville Skyttä wrote: On my system ls.exp ends up testing ls ~avahi-autoipd and avahi-autoipd's home dir does not exist, perhaps that's why it passed. Maybe the test case should be modified so that it checks the existence of the chosen user's home dir and if it does exist, expects to see a slash appended to it? On my system ls.exp ends up testing ls ~Debian-exim which has a home dir. Indeed maybe we could split the test in two, once for ~user with and once for ~user with home dir. Debian has a user `nobody' with home dir `/nonexistent' which should (and does) complete with a space instead of a slash. But this should be detected dynamically by the test suite. I think looping over the `compgen -u' in `ls.exp' and make the two lists for two separate tests would do..? Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] assert_bash_exec output treatment
On 100919 11:30, Ville Skyttä wrote:
Hello,
The _filedir.exp unit test currently outputs:
ERROR Unexpected output from bash command _filedir should run without
errors:
bash: compopt: not currently executing completion function
...but that's just an error message output, it doesn't actually cause a test
suite failure. I wonder if that's on purpose, and what's multipass_name in
assert_bash_exec?
I used multipass_name as a detection mechanism to see if DejaGnu was fully
initialized. I think I inserted this check after calling `assert_bash_exec' in
an early stage during the initialization of the test suite, where the `fail'
method wasn't yet available causing a DejaGnu unknown method error. There
might be a better way...
So commented code looks like this:
// Is DejaGnu fully initialized, i.e. is fail method available?
if {[info exists multipass_name]} {
fail ERROR Unexpected output from bash command \$title\
}
send_user ERROR Unexpected output from bash command \$title\:\n$results
I'll add these comments (commit ba41910).
Greetings,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] _filedir case sensitivity
On 100914 21:15, Ville Skyttä wrote: The attached patch provides some automatic case insensitivity to _filedir and _filedir_xspec by automatically matching all-uppercase versions of the passed patterns as well as the original ones. The idea is that if this goes in, all glob arguments to _filedir and the _filedir_xspec things can be cleaned up to all lowercase and we'd get better case insensitivity support automatically even without this work. The downsides are that this isn't exactly that pretty, and that strictly case sensitive (non-all-uppercase) completions would no longer be possible. I don't think these are big issues at all. Thoughts, objections? So from a glance this patch only effects file extensions, it doesn't make the whole filename matching case insensitive? If just for extensions, +1. Freddy http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] using external helpers for completion
On 100828 18:32, Guillaume Rousse wrote: However, I'd like us to decide on a final setup, that would be: 1) FHS-compliant 2) efficient in term of time spent to source files at each new bash process start (that's the initial goal of distinguishing between installation and activation directory) 3) enforced by our installation process (we currently hardcode /etc/bash_completion.d in bash_completion file, instead of relying on installation process to set it according to --sysconfdir variable) 4) avoid conveniancy symlinks, as the one we're just discussing here That is supposed to be a 2.0 release objective, after all. Yes, it would be nice if could tackle this and now incorporate any `helpers' directory in it. What if we would create an environment variable `BASHCOMP_PATH' (prefix is going to be `bashcomp_' isn't it?), containing colon-separated (:) directories. Each of these directories should contain mandatory directories, being: - completions (the renamed `contrib') - helpers BASHCOMP_PATH typically would contain these directories: /usr/share/bash-completion /etc/bash_completion.d/ ~/bash_completion.d but allows for each distribution to vary. I'm not sure how we would incorporate per-user config settings. Maybe bash_completion could look in each of the BASHCOMP_PATH directories for a `bash_completion' or `.bashcomprc' file? If we would first agree on BASHCOMP_PATH, we could then second decide on how BASHCOMP_PATH should be set up by an installer. Thoughts? I'm hesitating to add yet another configuration variable, especially since contrib helpers are so tied together (we would also need a BASH_COMPLETION_COMPAT_DIR_HELPER, ugh). I still don't know what's this variable is for, BTW. I was thinking if BASH_COMPLETION_DIR/contrib gets a `helpers' dir with a variable pointing to it, then BASH_COMPLETION_COMPAT_DIR/contrib would need one as well. So, I'm absolutly OK for another symlink as a temporary solution, but I'd prefer to achieve our long-time objective as well. And if testing has specific issues, I'd prefer them to be solved by test-time only solutions/hacks/whatever than permanent setup ones. Let's add the symlink then until we decide on a final setup. I'm fine with adjusting the test suite, but I also expect people - just like me - running bash_completion directly from git HEAD without doing a `make', and I think it would be better if we can defer `make' substitutions to the install phase so that the bash_completion source stays simpler. Greetings, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] using external helpers for completion
On 100825 22:58, Guillaume Rousse wrote:
That's a good idea, that would avoid install-time substitution.
However, $BASH_COMPLETION_DIR point to the directory where completions
are sourced, whereas many of us (fedora and mandriva maintainers) only
put symlinks there, and use a distinct directory for installing the
whole set of available completions.
Then you can also create a `helpers' symlink there?
So, I'd rather use a distinct BASH_COMPLETION_DIR_HELPER for this, and
provide it a default value (/usr/share/bash-completion/helper) in main
bash_completion file.
I'm hesitating to add yet another configuration variable, especially
since contrib helpers are so tied together (we would also need a
BASH_COMPLETION_COMPAT_DIR_HELPER, ugh).
complete -C ${BASH_SOURCE[0]%/*}/helpers/perldoc perldoc
Installation setup doesn't mandatorily match archive setup.
But we could make it mandatory for BASH_COMPLETION_DIR to have a
(symlinked) `helpers' subdir? More enforcements are coming if we're
going to merge bash-completion-lib...
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Tab Completion Problem
On 100720 08:38, Eric Blake wrote: Thanks for the report; I'm redirecting it upstream to the bash-completion developers, since it is not cygwin-specific, and since there are probably other instances where running with 'set -u' will impact bash completion. Yes, if `set -o nounset' is active, bash-completion will report many errors and fixing this will take some effort. Nevertheless, I think striving for a 'nounset'-proof bash-completion is worth the effort, because making sure variables are set, is good practice and will make bash-completion more error-proof. I'll put the task on the roadmap, ok team? I'm putting this last as an objective for version 3.0. See: http://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [bash-completion-Bugs][312646] _command() bug
On 100820 00:46, Ildar Mulyukov wrote: Please apply the patch to GIT HEAD. Oops. Doing a `git push' right now... ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] bash3 versus bash4 policy
On 100810 20:24, Ildar Mulyukov wrote: I'd like to know better about status of bash3. Will it be supported by bash-completion ? Bash-completion is currently supporting bash = 3.2. See also the README file: Use the full power of bash = 3.2. We no longer support earlier bash versions, so you may as well use all the features of that version of bash to optimise your code. However, be careful when using features added since bash 3.2, since not everyone will be able to use them. Be ESPECIALLY careful of using features exclusive to 4.x, as many people are still using 3.x. For example, extended globs often enable you to avoid the use of external programs, which are expensive to fork and execute, so do make full use of those: ?(pattern-list) - match zero or one occurrences of patterns *(pattern-list) - match zero or more occurrences of patterns +(pattern-list) - match one or more occurrences of patterns @(pattern-list) - match exactly one of the given patterns !(pattern-list) - match anything except one of the given patterns Greetings, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Test suite errors
Guillaume, The addition of `contrib/Makefile.am' in commit c030827f dynamic creation of perldoc completion, to point to helper script is causing me errors because bash is sourcing ./contrib/Makefile.am: bash: static_bashcomp: command not found bash: generated_bashcomp: command not found bash: static_bashcomp: command not found bash: generated_bashcomp: command not found bash: bashcomp_DATA: command not found bash: perl:: command not found bash: srcdir: command not found bash: srcdir: command not found bash: /.in: No such file or directory bash: bashcomp_DATA: command not found bash: EXTRA_DIST: command not found bash: CLEANFILES: command not found Can you have a look? Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Colon completion woes
On 100511 00:54, Ville Skyttä wrote: Maybe we should start thinking about adding a begin and end hook to every completion for things like this; put it at the end of the roadmap? No objections here. Added objective for version 3.0 to the roadmap: Provide begin and end hook to every completion, so things like __ltrim_colon_completions() can be called standard. Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Namespace prefix?
On 100425 13:18, Ville Skyttä wrote: Does bash officially reserve any variable/function prefix to itself? At least BASH_* and COMP_* are used in it I've put the question on the bug-bash mailing list, see: http://www.mail-archive.com/bug-b...@gnu.org/msg07539.html If we're going to use bashcomp_/BASHCOMP_ prefixes, that would mean we'd also have the change the global configuration constants: COMP_CONFIGURE_HINTS BASHCOMP_CONFIGURE_HINTS COMP_CVS_REMOTE BASHCOMP_CVS_REMOTE COMP_KNOWN_HOSTS_WITH_HOSTFILE BASHCOMP_KNOWN_HOSTS_WITH_HOSTFILE COMP_TAR_INTERNAL_PATHS BASHCOMP_TAR_INTERNAL_PATHS I'd like to propose we do so, and mark the COMP_ constants as deprecated, but still take them into consideration. This way users have a transition period to change their configuration constants. Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Committed: (testsuite) Drop ending block comments
My commit message to commit-list is being held because of size limit. This is the commit: (testsuite) Drop ending block comments Instead of writing `}; # if', write just `}' as was discussed here: http://www.mail-archive.com/bash-completion-devel@lists.alioth.debian.org/msg01815.html - Forwarded message from bash-completion-commits-boun...@lists.alioth.debian.org - Date: Fri, 18 Jun 2010 15:22:33 + From: bash-completion-commits-boun...@lists.alioth.debian.org To: fvu...@gmail.com Subject: Your message to Bash-completion-commits awaits moderator approval Your mail to 'Bash-completion-commits' with the subject [SCM] bash-completion branch, master, updated. 51b3e20ebcf5f5b598ea33a6d1d393ffa5990430 Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 157126 bytes with a limit of 40 KB Either the message will get posted to the list, or you will receive notification of the moderator's decision. If you would like to cancel this posting, please visit the following URL: http://lists.alioth.debian.org/mailman/confirm/bash-completion-commits/1f459aeb378dfa82c55cda21c13010b45b7507ab - End forwarded message - ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Bug#511788: Bug#511788: fixed in bash-completion 1:1.2-1
On 100617 12:22, Antoine wrote: However, before the fix, if you backspace deleted the extra, and then typed a dot . and then triggering [tab] completion again, it would complete with available groups like for example from chown username.group[tab] to chown username.groupname Since the fix, there is not anymore groupname completion Usergroup completion has been improved indeed, but the dot isn't supported anymore, see: http://www.mail-archive.com/bash-completion-devel@lists.alioth.debian.org/msg01515.html Instead of typing a dot, you can type a colon ':' and then trigger [tab] completion again. Greetings, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Release 1.2? (Re: Namespace prefix?)
On 12:13, David Paleino wrote: Freddy, do you want me to make it into 1.2 as well? If possible, yes? The work is done, so I think it's good to get it out. The new `_get_comp_words_by_ref' definitely requires bash = 3.1, but as I understand the requirement of bash = 3.2.0 is already going to be the case for 1.2? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Release 1.2? (Re: Namespace prefix?)
On 100609 07:56, David Paleino wrote: I merged master into 1.x -- if you're ok with the current status, I'm going to prepare a 1.2 relese in the next few days. Otherwise, please tell me, and let's only get bugfixes in the 1.x branch. Sorry, meant to have sent the mail underneath Wednesday, but it ended up in a local mail queue :-( Here it is finally: ---8--- Date: Wed, 9 Jun 2010 22:32:27 +0200 From: Freddy Vulto fvu...@gmail.com To: bash-completion-devel@lists.alioth.debian.org I've been trying to find the perfect solution for `passing variables by reference', and I think it can be achieved by adding two helper methods `_upvar' and `_upvars'. For more information, see: http://www.fvue.nl/wiki/Bash:_Passing_variables_by_reference In a minute I'll add this to the branch `use-_get_comp_words_by_ref'. Then I would like to merge this into `master'. I think it would also be nice if we could merge this into the 1.2 release, because the `upvar(s)' solution is much nicer than the wrapper-workaround which is currently in master. ---8--- Anyway, things turned out right with branch `use-_get_comp_words_by_ref' merged in 1.2, thanks. I'll try doing some more testing on the 1.x branch the next few days. Greetings, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Release 1.2? (Re: Namespace prefix?)
Merged branch 'use-_get_comp_words_by_ref' to 'master'. It's not showing up in the 'Bash-completion-commits' because the message is too big: ---Forwarded mail--- Date: Thu, 10 Jun 2010 21:53:41 + From: bash-completion-commits-boun...@lists.alioth.debian.org To: fvu...@gmail.com Subject: Your message to Bash-completion-commits awaits moderator approval Your mail to 'Bash-completion-commits' with the subject [SCM] bash-completion branch, master, updated. 94372b2aa6e9df90d47bedb1dabedb3a71ee1e0e Is being held until the list moderator can review it for approval. The reason it is being held: Message body is too big: 89374 bytes with a limit of 40 KB ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Passing variables by reference
The way we now do passing variables by reference (working around the conflict
with local variables) felt a bit awkward so I put my workaround to the test on
the bug-bash mailing list.
After having discovered some surprising (at least for me) behaviour of `unset'
the final outcome seems to be an elegant solution, similar to Tcl's `upvar':
upvar() { unset -v $1 eval $1=\\$2\; }
blackbox() { local $1 upvar $1 bar; }
f() { local b; blackbox b; echo $b; }
f # Ok: b=bar
If anyone wants to read and/or contribute, the thread is:
http://www.mail-archive.com/bug-b...@gnu.org/msg07285.html
I'm summarizing the solution here:
http://fvue.nl/wiki/Bash:_Passing_variables_by_reference
and explaining the behaviour of `unset' here:
http://fvue.nl/wiki/Bash:_Unset
I'll do some further testing and if things look all right I'll apply the
`upvar' solution to bash-completion, getting rid of the additional call-layer
in:
- _get_comp_words_by_ref __get_comp_words_by_ref
- __get_cword_at_cursor_by_ref ___get_cword_at_cursor_by_ref
BTW, I'm trying to reuse the bash-completion test suite for testing standalone
bash solutions like this, but reusing the bash-completion test suite is not
straightforward at the moment. Perhaps somewhere in the roadmap we can try
thinking about separating the test suite into a standalone project? I think
this would benefit other bash projects (they'll have a test suite) and
bash-completion (the test suite would become better).
Greetings,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] e7d7ae81 (testsuite) Always look for command availability before?testing?completion.
On 100412 20:40, Ville Skyttä wrote: I don't remember seeing any objections, so done in git now. It's working great, except for 3 failing completions on my Debian test machine: grub, screen and xhost. Problem with grub is that on my Debian it's in /usr/sbin/grub, so when the test-user is running, grub completion doesn't work because _longopt can't execute grub. I have fixed this by reinstating the `assert_bash_type()' but now within assert_source_completions(), in commit 6586c32. Another solution could be to do the check in lib/completions/grub.exp. Or don't let the `have' command modify the PATH when looking for installed commands? I'll have to look into the other fails (screen xhost). Greetings, Freddy http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] _get_cword breaks with non-ascii characters when completion files
I made a test case for this problem, see commit 3d4941f. I have to change LC_CTYPE=C to see the problem, probably because my default locale is en_US? You can run the test case(s) with: ./run ./unit/_filedir.exp I was able to move the fix centrally to _quote_readline_by_ref in commit 50824f9. Can you confirm this works for you as well? Greetings, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Bug#551780: Fix by reading from avahi-browse with a timeout
I like your solution leaving the user -/+ posix setting intact. Leaving a small chance the user does a ^C before we restore the setting I think is the best we can do. Letting bash-completion disable posix globally just doesn't feel good. The same goes for doing shopt -s extglob globally - see also this work of Martin von Gagern: https://alioth.debian.org/tracker/?func=detailatid=413095aid=311628group_id=100114 Great if you can offer both bash-3.2 and bash-4 a solution, albeit different. I'm not experiencing problems with avahi though, so I can't comment on the fix working. Greetings, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Expect buffering fixes
On 100318 06:27, Crestez Dan Leonard wrote: I downloaded bash-static from lenny, it seems to be the close to the version you are talking about. I was unable to reproduce the issue. I had the problem on stock bash-3.2.39 coming with Debian-5.0.4. I'm running this on a Pentium III 450 MHz. This is a rather slow system, hence the slow timings(?), but a good test... Unfortunately I can't reproduce the problem now either(?). Maybe some other processes were slowing the system down... So I made this all optional instead, sync_after_int will sleep unless you pass --fast-sync to run. This seems like a reasonable compromise. I don't insist on merging this, I just find long runtest times annoying. I agree. But also I think a fast test suite is key to proliferation/success of automated testing. Thus said, I think the bash-4 way of synchronizing (synchronizing on ^C in output) is king and we: - should make this the default for bash-4 - should merge this into the master branch (after getting it right in this branch) The default for bash-3 should then be to synchronize using `sleep'. I compiled bash-3.2.0 (since this is the minimum required version now) and also had some timing problems (albeit not reproducable again). I had to increase the timing between the ^C and prompt-matching from .1 to .5. Maybe instead of an option `--fast-sync' we can make an option `--sleep' which switches to slow-sync (on bash 3, since for bash = 3 it already would be the default) and allows specifying an alternate timing. Since the test-library is containing more and more tweaks, I'm thinking of creating an additional test area (DejaGnu 'tool') called self in which we can test the test suite itself is behaving as expected. What do you think? I'm thinking of self-testing the sending of \005 (^E) and also another regression I noticed, regarding this test which used to FAIL but is now PASSing because we removed the `$' (match on end) somewhere (I think in match_items): expected: foo bar real: foo bar cee Greetings, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Bug#551780: Fix by reading from avahi-browse with a timeout
Crestez Dan Leonard cdleonard at gmail.com writes:
I had to mangle +o posix to get tests to pass. I don't know why the test
suite puts the shell into posix mode anyway.
Because users 'out there' might run bash-completion in bash POSIX mode. I
regard POSIX as just stricter bash script and supportable with little effort, so
I put it in the test suite to make sure bash-completion honours POSIX. A
notable error is that POSIX doesn't allow a hyphen (-) in a function name,
whereas standard bash does allow:
$ f-a() { echo foo; }
$ set -o posix
$ f-a() { echo foo; }
bash: `f-a': not a valid identifier
Perhaps the test suite should test completions both with and without POSIX
mode...
Another solution - if bash-completion really demands noPOSIX :-( - could be to
disable POSIX on entering bash-completion and restore POSIX (if it was enabled)
on exit, but this 'on exit' is hard to catch...
Greetings,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] _get_comp_words_by_ref
On 100210 21:48, Freddy Vulto wrote: Maybe we can make the varnames non-optional, and also provide shortcuts by using the arguments, indicating which fixed varnames to return: Done so in commit bdca37a in branch `use-_get_comp_words_by_ref': Improve _get_comp_words_by_ref to return `words' and `cword': Usage: _get_comp_words_by_ref [OPTIONS] [VARNAMES] Available VARNAMES: cur Return cur within varname cur prevReturn prev within varname prev words Return words within varname words cword Return cword within varname cword Available OPTIONS: -n EXCLUDE Characters out of $COMP_WORDBREAKS which should NOT be considered word breaks. This is useful for things like scp where we want to return host:path and not only path, so we would pass the colon (:) as -n option in this case. Bash-3 doesn't do word splitting, so this ensures we get the same word on both bash-3 and bash-4. -c VARNAME Return cur within specified VARNAME -p VARNAME Return prev within specified VARNAME -w VARNAME Return words within specified VARNAME -i VARNAME Return cword within specified VARNAME Example usage: $ _get_comp_words_by_ref -n : cur words cword Greetings, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Undo commit 00560a8 (_filedir: bash 4 ... $cur beginning with ' or not)
Hello David, Commit 00560a8 (_filedir: bash 4 has the same behaviour regardless of $cur beginning with ' or not) is failing tests on bash-4.0 and 4.1: FAIL: completing f a\'b/ should return i FAIL: completing f a\b/ should return i FAIL: f a\$b/ should show completions FAIL: f a\\b/ should show completions FAIL: completing f2 a\'b/ should return i FAIL: completing f2 a\b/ should return i FAIL: f2 a\$b/ should show completions FAIL: f2 a\\b/ should show completions In your example `_filedir' is run from the command line, causing this command: compgen -f -X '!*.in' -- ''\'''\''' to fail. I could modify `_quote_readline_by_ref()' to return empty string instead of '', but `compgen' is a peculiar thing and not really supposed to run from the command line. Hence I can't reproduce your bug with an added test (completing with filter '.e1' should show completions) and therefore I'll undo your commit in commit caaf588. Or do you have a completion example where things go wrong? Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Undo commit 00560a8 (_filedir: bash 4 ... $cur beginning with '?or not)
On 100312 14:19, David Paleino wrote: I'll report as soon as I see that happening again. ... On a side note: maybe it's better if I avoid committing anything, for ... No offense taken/intended. Don't hesitate to commit as far as I'm concerned (just don't let bash-completion endanger your exams ;-). The test suite is proving its worth and should actually encourage commits/refactoring... At least the _filedir unit tests and comments have been improved now. As soon as the error is reproducable we'll write more tests and a fix... Greetings, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Expect buffering fixes
On 100226 00:49, Crestez Dan Leonard wrote:
I pushed a new attempt at this in the expect-fixes branch. It first
matches a random string then the new prompt as distinct stages. This
seems to avoid races. Link to code: http://alturl.com/tf7u
Please test this; it was broken before.
Hmm, still getting errors, e.g.:
$ ./run completion/awk.exp --debug
Running ./completion/awk.exp ...
FAIL: Sync after INT at timeout
...
File dbg.log contains this:
---8---
...
expect: does sync361 (spawn_id exp9) match regular expression .*sync361$?
yes^M
expect: set expect_out(0,string) sync361^M
expect: set expect_out(spawn_id) exp9^M
expect: set expect_out(buffer) sync361^M
send: sending \u0019\u0003 to { exp9 }^M
^M
expect: does (spawn_id exp9) match regular expression ^(\^C)?\r\n/@$? no^M
1^H1^M
expect: does 1\u00081 (spawn_id exp9) match regular expression
^(\^C)?\r\n/@$? no^M
^M
^M
expect: does 1\u00081\r\n (spawn_id exp9) match regular expression
^(\^C)?\r\n/@$? no^M
/@^M
expect: does 1\u00081\r\n/@ (spawn_id exp9) match regular expression
^(\^C)?\r\n/@$? no^M
expect: timed out^M
FAIL: Sync after INT at timeout
...
---8---
Something fishy is going on: from 1^H1^M it looks like an additional 1 is
inserted, then backspaced (^H) and then inserted again. At other FAILs this
1 character is always the last character of the random sync string...?
The problem goes away on bash-3 if I add a tiny `sleep' again just before
sending QUIT/INT:
sleep .001
send \031\003;
Then things run ok on both bash-3.2:
$ time ./runCompletion
=== completion Summary ===
# of expected passes351
# of expected failures 1
# of unsupported tests 191
..., bash-3.2.39(1)-release
real1m17.044s
user0m10.125s
sys 0m15.029s
and bash-4:
$ time ./runCompletion --tool_exec /opt/bash-4.0/bin/bash
=== completion Summary ===
# of expected passes350
# of expected failures 2
# of unsupported tests 191
..., bash-4.0.28(1)-release
real1m15.654s
user0m9.761s
sys 0m12.065s
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Expect buffering fixes
This is the thread: http://www.mail-archive.com/bug-b...@gnu.org/msg07023.html Looks like we can/should use this for bash-4: echo 'set echo-control-characters on' ~/.inputrc bind 'set echo-control-characters on' but need another solution for bash-3. I did a short try with the workaround, like this: # Send QUIT/INT send \031 send \003 send sync001 expect -re .*sync001$prompt$ but for some reason the sync001 interferes with the output. Otherwise we should maintain the `sleep .1' just for bash-3? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Expect buffering fixes
On 100223 19:28, Ville Skyttä wrote: Confirmed. Ditto with bash 3.2.25. I notice the difference when just typing a ^C. On bash = 4 it is echoed as ^C, but on bash-3 it is echoed as a newline. I think I'll ask the bug-bash mailing list. If we could just make bash-3 echo the ^C... ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Expect buffering fixes
On 100221 12:42, Ville Skyttä wrote:
On Sunday 21 February 2010, Crestez Dan Leonard wrote:
I pushed this is in the expect-fixes branch in git. It would be great if
you could confirm my findings; I don't want to cause regressions.
On bash-4.0 and 4.1 it runs ok, the speed improvement is great, but on
bash-3.2.39 I get lots of errors:
FAIL: Sync after INT at timeout
This is what's in dbg.log:
PASS: Tab should complete alias
send: sending \u0019\u0003 to { exp9 }^M
^M
expect: does (spawn_id exp9) match regular expression .*\^C\r\n/@$?
no^M
^M
^M
expect: does \r\n (spawn_id exp9) match regular expression
.*\^C\r\n/@$? no^M
/@^M
expect: does \r\n/@ (spawn_id exp9) match regular expression
.*\^C\r\n/@$? no^M
expect: timed out^M
FAIL: Sync after INT at timeout
The ^C doesn't seem to get through to 'expect' on bash-3.2?
On bash-4.0 and bash-4.1 it looks like this:
PASS: Tab should complete alias
send: sending \u0019\u0003 to { exp9 }^M
^M
expect: does (spawn_id exp9) match regular expression .*\^C\r\n/@$?
no^M
^C^M
expect: does ^C (spawn_id exp9) match regular expression
.*\^C\r\n/@$? no^M
^M
^M
expect: does ^C\r\n (spawn_id exp9) match regular expression
.*\^C\r\n/@$? no^M
/@^M
expect: does ^C\r\n/@ (spawn_id exp9) match regular expression
.*\^C\r\n/@$? yes^M
Is the error reproducable on bash-3.2?
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] BASH_XTRACEFD and scripts to run tests.
On 100220 23:08, Crestez Dan Leonard wrote: Anyway; here's what I came up with. I'll commit this later unless there are any objections (like breaking crontabs). +1 (I still need to install bash-4.1, but the more reason now) ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] BASH_XTRACEFD and scripts to run tests.
On 100217 19:29, Crestez Dan Leonard wrote: DejaGnu claims to have a powerful configuration system and it's been used in very complex situations. Could anyone point me to a straight-forward way to add an option like this? Maybe you can pass the BASH_XTRACEFD via the --tool_opts option of runtest? Within the testsuite we could then examine the TOOL_OPTIONS tcl variable and set BASH_XTRACEFD via `assert_bash_exec()'. Where do you see a tclvar option? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [alioth tracker] can't attach to bug report i'm not the owner of
On 100213 13:31, Raph wrote: As an additionnal information I can reproduce the following bug : [alioth tracker] CAN'T ATTACH TO BUG REPORT I'M NOT THE OWNER OF That's pretty annoying and has already been reported here. I remember there's been a discussion in Feb/Mar 2009 about choosing a bugtracker program, but the conclusion was to keep using Alioth at least for a short while: http://www.mail-archive.com/bash-completion-devel@lists.alioth.debian.org/msg00744.html Alioth is actually FusionForge-4.8.2 (http://fusionforge.org/) but I couldn't find any references to a bug not being able to include attachments... FWIW, from this article Review: Free Software Project Hosting (http://changelog.complete.org/archives/1123-free-software-project-hosting), dated August 2009, it appears the Github Issue Tracker doesn't support attachments either. Maybe a workaround is to send attachments via the bash-completion-devel mailing list as a reply to an issue update? David, do you know if making attachments can be allowed to Alioth bug commenters? Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Weird compopt.exp unit test problem
On 100211 09:11, Ville Skyttä wrote:
On Wednesday 10 February 2010, Freddy Vulto wrote:
On 100210 18:16, Ville Skyttä wrote:
Maybe this is what you meant above put in other words, but removing the
-re {a\\\'b/c} { block from compgen.exp or hacking the regexp so that
it does not match makes the problem go away for me. I don't think that's
the correct fix at all, but my tcl/expect-fu is not good enough so it'd
make sense for me to try to dig deeper.
I can't reproduce the problem on Debian or Ubuntu Jauny unfortunately.
Perhaps you can try putting:
sleep 1
in between sending bash commands to see if it's a timing problem.
Bingo. The patch below appears to fix it for me, do you think it
would be appropriate to commit it? Dan, does this fix it for you as well?
:-) Does a `sleep .1' suffice as well? This would shorten test
duration. And maybe we'd better move this central to the end of
`sync_after_int' to prevent us from being bitten by this in similar
situations. Because now theoretically every case like this:
sync_after_int
assert_bash_exec ...
has a chance of `expect' sending the next command faster than `bash' is
restoring after the QUIT/INT signals -- having sent the prompt though...
strange still.
Regards,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Weird compopt.exp unit test problem
On 100211 23:44, Ville Skyttä wrote: No objections, go ahead. I'm not worried at all about adding to the time taken by the tests if it makes them more reliable. I think we need to find a mean/middle. I'd like to run the tests as fast as possible when running the tests manually during development. Let's start with .1 and as soon as anyone reports problems we raise it with .1? I added the `sleep .1' right after sending the QUIT/INT. It's before waiting for the bash prompt, but I think this should fix it as well(?) and it's symmetric with the `sleep .1' before the QUIT/INT. See commit: 9f1073 Greetings, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] _get_comp_words_by_ref
On 100209 13:14, Crestez Dan Leonard wrote: I'm not sure about the arguments to the _get_comp_words_by_ref function. Passing multiple [cur] [prev] [prev2].. arguments doesn't seem all that useful. More than cur and prev would very rarely be useful; and in such a case it might be better to just fetch the array and current index. You've got a point there. Returning `words' and `cword' would be useful as well. So what about turning this into --cur --prev with default arguments? I'd like to use builtin `getopts' to parse arguments but `getopts' doesn't support long options, so that would turn into something like this: Usage: _get_comp_words_by_ref OPTIONS Available OPTIONS: -c [VARNAME] Return cur within specified varname (defalt cur) -p [VARNAME] Return prev within specified varname (default prev) -w [VARNAME] Return words within specified varname (default words) -i [VARNAME] Return words within specified varname (default cword) This has the drawback that from a first glance, variables cur/prev/words/cword 'magically' get filled. For example, after calling: _get_comp_words_by_ref -cpwi suddenly variables: cur, prev, words and cword contain values. I don't think we should do that. Maybe we can make the varnames non-optional, and also provide shortcuts by using the arguments, indicating which fixed varnames to return: Usage: _get_comp_words_by_ref [OPTIONS] [VARNAMES] Available OPTIONS: -c VARNAME Return cur within specified varname (default cur) -p VARNAME Return prev within specified varname (default prev) -w VARNAME Return words within specified varname (default words) -i VARNAME Return words within specified varname (default cword) Available VARNAMES: cur Return cur within varname cur prev Return prev within varname prev words Return words within varname words cword Return cword within varname cword This way: - because VARNAME's to OPTIONS aren't optional, within a completion it's always obvious where the variables are being set - we make it advantageous (because of a simpler function call) for people to use the preferred variables cur, prev, cword and words. - the preferred variable names can be overridden by using the options syntax Example calls would then be: # Fill local $cur _get_comp_words_by_ref cur # Or by using longer syntax _get_comp_words_by_ref -c cur # Using another variable name for retrieving cur _get_comp_words_by_ref -c current_word_to_complete # Using unknown varname would give error _get_comp_words_by_ref current # Error: unknown varname current # Retrieving all variables _get_comp_words_by_ref cur prev words cword # Different order is ok _get_comp_words_by_ref words cword cur # Using non-default variables _get_comp_words_by_ref -c comp_cur -i comp_cword -w comp_words -p comp_prev Having a single function avoids multiple __reassemble_comp_words_by_ref calls further down, so I guess it's worth doing for performance. But it would be nicer to just reimplement _get_cword with a cache. Otherwise anything that uses __reassemble_comp_words_by_ref would be turn into an argument to _get_comp_words_by_ref (think _count_args). Unfortunately a cache is impossible to implement without leaking variables to the shell environment. Maybe bash-completion-lib has a way to execute cleanup code after every completion? It is possible with bash-completion-lib, but only if you'd set COMP_INSTALL=0. This way `comp_load' would remain active for every completion and it'll call `comp_load_deinit()' after completion has been done. This might be an idea indeed once we do the merge with bash-completion-lib. I don't see how we could do so right now. Maybe if we'd put things inside a bash `trap' or something but I think that's getting too complicated let alone possible. But for now, what are the opinions about a _get_comp_words_by_ref [OPTIONS] [VARNAMES] as proposed above? Greetings, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] completion for ipv6calc
On 100116 11:38, Ville Skyttä wrote:
On Friday 15 January 2010, Freddy Vulto wrote:
Maybe we'd also better merge _get_cword and _get_pword together to a new:
_get_cwords_by_ref 'nonwordbreakchars' cur [prev [prevprev] ...]
with `prev', `prevprev', etc. being optional arguments.
This circumvents doing the same cwords-parsing repeatedly when calling
both _get_cword and _get_pword. This also fixes situations where
`nonwordbreakchars' passed to _get_cword and _get_pword aren't the same,
which they should be. Plus it saves us a subshell call and we have
consistent naming.
Sounds good to me, even better if it was necessary to specify
nonwordbreakchars only when one actually needs to, like
_get_cwords_by_ref [-n 'nonwordbreakchars'] cur [prev [prevprev] ...]
Done in commit b529cee:
Added _get_comp_words_by_ref()
This solves the following problems:
- now one function call suffices instead of two (_get_cword; _get_pword) if
subsequent words need to be retrieved. Also more than two words can be
retrieved at once, e.g.: _get_comp_words_by_ref cur prev prev2 prev3
Also this prevents passing of `wordbreakchars' to differ in calls to
`_get_cword' and `_get_pword', e.g.: _get_comp_words_by_ref -n : cur prev
- passing by reference, no subshell call necessary anymore
- _get_pword now also takes into account the cursor position
If we all agree, we can entirely replace _get_cword() with
_get_comp_words_by_ref()?
I've added this as a proposal to the wiki for bash_completion-2, see:
http://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap
Word of caution:
The passing-arguments-by-ref system in bash doesn't work if the new variable is
also declared local. For example:
t() {
local a
# ...
eval $1=b
}
a=c; t a; echo $a # Outputs c, should be b
# Variable a is 'forbidden'
To make name collissions like this less likely to happen, but make the real
function still use readable variables, I've wrapped the `*_by_ref'
functions within an additional layer using variables prefixed with double
underscores (__). For example:
_t() {
# Readable variables can still be used here
local a
# ...
eval $1=b
}
t() {
local __a
_t __a
eval $1=\$__a
}
a=c; t a; echo $a # Outputs b
# Variable __a is 'forbidden'
Now only more obfuscated variables (starting with double prefix (__)) are
forbidden to use.
Regards,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] TCL styleguide?
Ville Skyttä ville.skytta at iki.fi writes:
On Friday 05 February 2010, Freddy Vulto wrote:
Just to be sure, does that mean we're also not commenting
end-of-functions anymore, like:
proc assert_complete {} {
}; # assert_complete()
I wouldn't mind dropping them there as well at all.
Plus:
On 100205 19:58, Crestez Dan Leonard wrote:
I'd say yes? At least in '}; # setup' and '}; # teardown'.
Conclusion: thou shall not comment any tcl end-of-block...
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] TCL styleguide?
On 100204 08:41, Crestez Dan Leonard wrote: What about some guidelines for TCL test code? I only found one style guide floating around: http://wiki.tcl.tk/708 . Good to have one. I added a reference to this Tcl Style Guide to the documentation. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] file inclusions in test suite
On 100131 22:29, Guillaume Rousse wrote: Le 04/01/2010 20:49, Freddy Vulto a écrit : On 100103 13:23, Guillaume Rousse wrote: Also, why do we need to move actual completion test to lib/completion/ssh.exp, instead of leaving it in completion/ssh.exp ? I've had a quick look, it doesn't seems to be included from anywhere else. The separation originates from bash-completion-lib where completions are tested twice; once before dynamic loading and a second time after: it proved to be useful to have the completions in a separate file so the completions can be tested twice easily. [..] Thanks. This explanation should be present in doc/testing.txt Yes, added to documentation now. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] TCL styleguide?
On 100205 11:43, Freddy Vulto wrote:
On 100204 08:41, Crestez Dan Leonard wrote:
There are actually only two things that bug me:
1) Ending blocks with }; # if
2) ...
Just to be sure, does that mean we're also not commenting
end-of-functions anymore, like:
proc assert_complete {} {
}; # assert_complete()
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] e7d7ae81 (testsuite) Always look for command availability before testing?completion.
I've added helper methods to the test suite (commit c70c1ec): - assert_source_completions() - is_bash_completion_installed_for() and modified `completion/perldoc' accordingly: assert_source_completions perldoc If all agree, we can propagate this to the other tests in completion/*. By the way, skeleton test files for a command can be generated easily by executing: $ ./generate command Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Line wrapping
On 09:48, Guillaume Rousse wrote: Le 03/02/2010 19:00, David Paleino a écrit : Do we have consensus for 79? OK for me. Ok for me too. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] TCL styleguide?
On 03:05, Crestez Dan Leonard wrote: http://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap mentions something about merging bash-completion-lib's test suite and it's not marked at done. Mangling library.exp with sed would probably not help. Merging is done actually: I updated the wiki. Test suite of bash-completion is containing much improvements compared to bash-completion-lib, and it's standing on its own now. Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Bump match_max for test suite?
On 10:38, Guillaume Rousse wrote: Le 20/01/2010 22:27, Freddy Vulto a écrit : What are your ideas on creating a constant test environment? Would chroot be useful? It seems a bit oversized, and requires root privileges morevoer. I was more thinking about abusing environment variables whenever possible, such as HOSTFILE each time hostname completion is used, for example. And sharing those tricks in generic fixtures, as you suggest. Agreed: using `test/fixtures' is preferred. The reason why the ssh/scp/sftp tests are using the current user environment is because I was unable to direct ssh/scp/sftp to `fixtures', but perhaps we should try again... For these and other cases, maybe we can make a subdirectory: test/fixtures/shared/ containing shared fixtures (and move `test/fixture1' there as well). Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] e7d7ae81 (testsuite) Always look for command availability before testing completion.
On 100131 00:29, Crestez Dan Leonard wrote:
I don't understand why every test has two files.
The two-files system stem from bash-completion-lib
(http://code.google.com/p/bash-completion-lib/, which I hope we can implement
soon) where tests are run twice per completion; once before dynamic loading and
a second time after to confirm that all dynamic loading has gone well.
For example
(http://code.google.com/p/bash-completion-lib/source/browse/trunk/test/completionLib/awk.exp):
---8---
set test Completion via comp_load() should be installed
set cmd complete -p awk
send $cmd\r
expect {
-re ^$cmd\r\ncomplete -o filenames -F comp_load awk\r\n/@$ { pass $test
}
-re /@ { fail $test at prompt }
}; # expect
source lib/completions/awk.exp
set test Completion via _longopt() should be installed
set cmd complete -p awk
send $cmd\r
expect {
-re ^$cmd\r\ncomplete -o filenames -F _longopt awk\r\n/@$ { pass $test }
-re /@ { fail $test at prompt }
}; # expect
source lib/completions/awk.exp
---8---
Looking to tests from a broader perspective, every test for a command has two
stages which are now reflected in the two files:
1. Tests concerning the command completions' environment (typically in
test/completion/foo)
2. Tests invoking actual command completion (typically in
test/lib/completions/foo)
I agree with your first point though, some completions work without calling the
actual command, so it's not always necessary to test if the command is really
available.
I think the tests in `completion/foo' for now should reflect the use of `have
command ...' on the bash-side. For example, because `contrib/perl' on the
bash-side contains `have *perl*':
have perl {
complete .. perl
complete .. perldoc
}
, the test `completion/perldoc' should test for the availibility of *perl* and
not *perldoc* (as it does now..., having my signature, changing it right
away ;-)
if {[assert_bash_type perl]} {
source lib/completions/perldoc.exp
}; # if
Regards,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Running tests against multiple bash versions.
I've updated http://wiki.debian.org/Teams/BashCompletion/Proposals/DropBash2Support and set the minimum required version for bash-completion-2 to bash-3.2.39. Bash-3.2.39 happens to be the minimal bash version on Debian-5.0.3, but this minimal version is open for debate. Right now 3.2.39 is the lowest version of bash against which I run nightly tests, so if we decide on a lower version, I could compile this and run tests against this as well, but as said: I'd rather move forward and develop towards bash-4 then below bash-3.2(.39). Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 2f78769d6537e936a4981e641eb75d229da81d98
On 100117 15:40, Ville Skyttä wrote: Oh, crap. They ship that as the system default awk? I'm afraid so. I've Ubuntu-9.04 (Jaunty Jackalope) and Debian-5.0.3 (Lenny) running, and they both report: $ awk -W version mawk 1.3.3 Nov 1996, Copyright (C) Michael D. Brennan FWIW, from http://ubuntuforums.org/archive/index.php/t-619985.html, I understand the rationale behind using mawk is that it's much faster... ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] completion for ipv6calc
On 100114 20:56, Ville Skyttä wrote: On Sunday 10 January 2010, Freddy Vulto wrote: On 100103 12:43, Guillaume Rousse wrote: Shouldn't we try to have variable and function names more consistent ? Aka rename _get_cword and _get_pword to _get_cur and _get_prev, or rename cur and prev to cword and pword ? Maybe we can put this to the roadmap and join this with the effort of centralizing the call to _get_cword alltogether once we do dynamic completion? If planning to rename something, please keep in mind the namespace prefix item in the roadmap. Maybe we'd also better merge _get_cword and _get_pword together to a new: _get_cwords_by_ref 'nonwordbreakchars' cur [prev [prevprev] ...] with `prev', `prevprev', etc. being optional arguments. This circumvents doing the same cwords-parsing repeatedly when calling both _get_cword and _get_pword. This also fixes situations where `nonwordbreakchars' passed to _get_cword and _get_pword aren't the same, which they should be. Plus it saves us a subshell call and we have consistent naming. Regards, Freddy http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Bump match_max for test suite?
On 100114 20:45, Ville Skyttä wrote:
If I'm right, should whitespace be left-trimmed when chunking, or the regexp
be changed to tolerate leading whitespace?
Yes, I think you're right. `expect' does 'eager matching', so head
whitespace on chunks 1 should be allowed. Maybe somethink like this:
diff --git a/test/lib/library.exp b/test/lib/library.exp
index fe8d7e2..4cc80f7 100644
--- a/test/lib/library.exp
+++ b/test/lib/library.exp
@@ -510,6 +510,8 @@ proc match_items {items test {prompt /@} {size 20}} {
regsub -all {([\^$+*?.|(){}[\]\\])} $item {\\\1} item
append expected $item
if {[llength $items] 1} {append expected {\s+}};
+# For chunks 1, allow head whitespace
+if {$i $size} {set expected \\s+$expected}
}; # for
if {[llength $items] == 1} {
expect {
Regards,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Bump match_max for test suite?
On 100109 13:21, Ville Skyttä wrote: Expect's default buffer size is too small - 2000 bytes according to the man page here - for cases where we have a lot of completions. In addition to rpm, there are at least pkg_info, portupgrade, portinstall, and probably quite a few other tests that have this problem. I think I had similar problems with dpkg. I found that increasing the buffer size made investigating the dbg.log file a tough job. That's why I wrote match_items() in lib/library.exp which matches items in chunks (default 20). Most complete test wrapper functions use `match_items()', so if you'd use the test wrappers like `assert_complete()' things would work also without increasing buffer size? Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] completion for ipv6calc
On 100103 12:43, Guillaume Rousse wrote: Shouldn't we try to have variable and function names more consistent ? Aka rename _get_cword and _get_pword to _get_cur and _get_prev, or rename cur and prev to cword and pword ? Maybe we can put this to the roadmap and join this with the effort of centralizing the call to _get_cword alltogether once we do dynamic completion? Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] file inclusions in test suite
On 100103 13:23, Guillaume Rousse wrote:
I recently commited autotools-integration of test suite. It works, but
only in classical usage scenarion, meaning running ./configure inside
the source directory. Using vbuild (running configure from another
directory), as in the 'make distcheck' scenario, doesn't work, because
all inclusions path are relative to current working directory.
For instance, file 'completion/ssh.exp' include
'lib/completions/ssh.exp'. If you're executing the test from anywhere
else as 'test' directory, it does't work.
test
├── completion
│ └── ssh.exp
└── lib
└── completions
└── ssh.exp
Is there a way to make those inclusions relative to either including
file location, or to a variable sourcedir instead ?
I've looked in DejaGnu's `runtest' and saw they're their own method called
`load_file' instead of `source'. Maybe we can use this as well:
load_file $libdir/completions/ssh.exp
But how are the tests executed from within autotools, via runtest,
runCompletion or run, and can't these be made to do a change dir to the `test'
directory before executing tests? Anyway, no objections to replace `source ..'
with `load_file $libdir/..' if this makes autotools work.
And - forgive me if a dumb question - what's the benefit/typical-usage, once
having autotools-integration of the test suite?
Also, why do we need to move actual completion test to
lib/completion/ssh.exp, instead of leaving it in completion/ssh.exp ?
I've had a quick look, it doesn't seems to be included from anywhere else.
The separation originates from bash-completion-lib where completions are tested
twice; once before dynamic loading and a second time after: it proved to be
useful to have the completions in a separate file so the completions can be
tested twice easily.
The effect is that tests in `test/completion' contain tests for the completion
*loading* (but also ignite the testing of the real completions), whereas
`test/lib/completions' contain tests for the actual completions.
Although the double inclusing isn't used right now, the idea was to keep this
structure intact, since the goal is to copy the dynamic loading of
bash-completion-lib to bash-completion in the near future. For example, this
is `completion/find.exp' from bash-completion-lib:
---8---
set test Completion via comp_load() should be installed
set cmd complete -p find
send $cmd\r
expect {
-re ^$cmd\r\ncomplete -o filenames -F comp_load find\r\n/@$ { pass
$test }
-re /@ { fail $test at prompt }
}; # expect
source lib/completions/find.exp
set test Completion via _find() should be installed
set cmd complete -p find
send $cmd\r
expect {
-re ^$cmd\r\ncomplete -o filenames -F _find find\r\n/@$ { pass $test }
-re /@ { fail $test at prompt }
}; # expect
source lib/completions/find.exp
---8---
Regards,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Bug#560851: Bug#560851: bash-completion: completion doesn't works if file name has an apostrophe
On 091212 20:38, skizzhg wrote: if I try with ls or mv then TAB to obtain the file list inside, it doesn't complete anything ~$ ls Pills\ \'n\'\ Thrills\ and\ Bellyaches/TAB I think there's a bug in `compgen -f' if a directory contains a single or double quote. I asked the bug-bash mailing list, see: http://www.mail-archive.com/bug-b...@gnu.org/msg06684.html We need to look into this and probably apply the workarounds below to _filedir(). Excerpt from bug-bash mail: ---8 So, these are the workarounds: $ ls a\'b/ # For reference, works on both bash-3 bash-4 c $ compgen -f a\\\'b/ # Workaround for bash-4 a\'b/c $ compgen -f a\\\'b/ # Workaround for bash-3 a\'b/c ---8 Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. cbf7e1f96387bdccdc965e5ed49de58b7dfceeef
On 091210 15:55, Todd Zullinger wrote:
Freddy Vulto wrote:
On 091209 22:25, Guillaume Rousse wrote:
Why doesn't remove the colon from COMP_WORDBREAKS works with bash
3?
COMP_WORDBREAKS is a bash-4 variable, see:
http://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html
Bash-3 always splits command line words using a fixed set of
wordbreak-characters, I thinks it's: \t\n\'=;|(:, and it
can't be modified...
Sure it can. The same text from the bash manual link above is present
in the bash-3.2 documentation. I don't know how far back it goes,
though it's not mentioned in the one bash-2.05b man page I have at
hand.
Hmm, my mistake, the solution of:
COMP_WORDBREAKS=${COMP_WORDBREAKS//:}
indeed works on bash-3 as well. It turns out the effect of modifying
COMP_WORDBREAKS is twofold and I only noticed the first on bash-4:
1. COMP_WORDS is split by COMP_WORDBREAKS-characters (bash-4 only)
2. CWORD (cur) is right-trimmed up to the first COMP_WORDBREAKS-character.
For example, with:
_a() {
echo; printf %s ${comp_wor...@]}
COMPREPLY=( foo1 foo2 )
}
complete -F _a a
This is what I get on bash-4.0.33:
$ COMP_WORDBREAKS=${COMP_WORDBREAKS}:
$ a b:cTAB
a b : c# (1) Split at :
foo1 foo2
$ a b:foo^C# (2) `c' is right-trimmed
$ COMP_WORDBREAKS=${COMP_WORDBREAKS//:}
$ a b:cTAB
a b:c # (1) No more split at :
foo1 foo2
$ a foo# (2) No right-trim
On bash-3.2.29, only the right-trim is done:
$ COMP_WORDBREAKS=${COMP_WORDBREAKS}:
$ a b:cTAB
a b:c # (1) No split at :
foo1 foo2
$ a b:foo^C# (2) `c' is right-trimmed
$ COMP_WORDBREAKS=${COMP_WORDBREAKS//:}
$ a b:cTAB
a b:c # (1) No split at :
foo1 foo2
$ a foo# (2) No right-trim
Let's continue the discussion on the thread Completion words containing
colons?
Regards,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. cbf7e1f96387bdccdc965e5ed49de58b7dfceeef
On 091209 22:25, Guillaume Rousse wrote: Why doesn't remove the colon from COMP_WORDBREAKS works with bash 3 ? COMP_WORDBREAKS is a bash-4 variable, see: http://www.gnu.org/software/bash/manual/html_node/Bash-Variables.html Bash-3 always splits command line words using a fixed set of wordbreak-characters, I thinks it's: \t\n\'=;|(:, and it can't be modified... This make me think a configuration file for the project, with all the project-specific variables, and additional variables, such as this one, would be useful. It's not a bash-completion variable, so I'm not sure if we should set this. Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] RFC: Turn on -o filenames in _filedir() if compopt is available
On 091205 00:43, gibbo...@gmail.com wrote:
What are the manual tweak bash 3 compatibles you think about ?
The only thing I imagine (saw in upstream mpc completion) is to append ' '
or '/' (and do backslashes hell tricks) to emulate -o filename while using a
global -o nospace (don't know if the 'idea' has been dug before)
From what I see, the wrapper only way to 'know' the bash 3 completion
currently
used is to sed $(complete -p $cmd) though the {run,load}time behavior is still
unknown to me.
Yes, the bash-3 improvements I'm thinking about are emulating `-o
filenames' and (also necessary for bash-4) `+o nospace'.
Indeed from within a completion, `_filedir' should be able to figure out if `-o
filenames' is in effect, here's the prove:
_a() {
if [[ $(complete -p ${COMP_WORDS[0]}) != *-o filenames* ]]; then
echo Emulate -o filenames
fi
}
complete -F _a a
These would be the pseudo-codes:
_filedir() {
...
if $bash_version = 4
compopt -o filenames
elseif `-o filename' isn't in effect for $CWORDS[0]
loop through completions
emulate `-o filanames': escape spaces, append slashes, etc.
}
__space_suffix_completions() {
if $bash_version 4.1 (?)
loop through completions
append a space
else
# In case `-o nospace' is in effect, disable it.
# Unfortunately `compopt +o' is not working in bash-4.0, maybe 4.1?
# See: http://www.mail-archive.com/bug-b...@gnu.org/msg06183.html
compopt +o nospace
fi
}
In fact I've already been trying on a real `__space_suffix_completions()' to
use for the `finger' completion, but it's not finished yet. Nevertheless, here
it is sofar:
# Usage: __space_suffix_completions CWORD
__space_suffix_completions() {
# Loop through completions
local i=${#COMPREPLY[*]}
while [ $((--i)) -ge 0 ]; do
# Is completion empty while there are other completions?
if [[ ${COMPREPLY[$i]} == ${#COMPREPLY[*]} -gt 1 ]]; then
# Remove item
unset COMPREPLY[$i]
elif [[ ${COMPREPLY[$i]} == ${#COMPREPLY[*]} -eq 1 ]]; then
local WORDBREAKS=$COMP_WORDBREAKS
[ ${BASH_VERSINFO[0]} -lt 4 ] WORDBREAKS= \t\n\'=;|(:)@
# Remove leftmost characters of CWORD until the last
COMP_WORDBREAKS char
local totrim=${COMP_WORDS[$COMP_CWORD]} trimmed=$totrim
while true; do
trimmed=${totrim#*[$WORDBREAKS]}
[ $trimmed = $totrim ] break
totrim=$trimmed
done
COMPREPLY=($trimmed )
else
# Suffix space
#COMPREPLY[$i]=$(__ltrim_wordbreak ${COMPREPLY[$i]} )
COMPREPLY[$i]=${COMPREPLY[$i]}
fi
done
}; # __space_suffix_completions()
Regards,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Merging __get_cword3 and __get_cword4 for bash = 4.0.35
I'll try to merge __get_cword3 and __get_cword4, now that bash-4.0 patch 35 addresses the splitting-quoted-strings problem: http://www.mail-archive.com/bug-b...@gnu.org/msg06337.html We'll probably have to keep __get_cword4 for bash-4.0.0 to bash-4.0.34, but I'll have a look. Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] finger test suite failure
On 091121 10:18, Freddy Vulto wrote: However, next issue is that the `finger' test is using the first host which now happenes to be `::1' and is causing troubles. ... But other tests (e.g. ssh) are now failing as well, so we'd better fix this for real? Assuming this should happen: $ finger test@:TAB $ finger test@::1 bash-completion is failing on my machine: it's offering a list of usernames to complete... so the testsuite has now revealed a bug in bash-completion? I think I've fixed completion of 'filenames' containing colon, see commit 4230265. Do the finger and ssh tests now pass on your machine? Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Style proposals: case labels and [[ ]]
On 11:31, Ville Skyttä wrote: On Thursday 05 November 2009, Ville Skyttä wrote: I'd like to propose two coding style guidelines: No comments? Silence means acceptance? +1 Another +1 to add the rationale to the documentation as well. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Test suite failures/questions
On 11:06, Ville Skyttä wrote: Just for kicks, did you try other TERM values, for example vt110? Using these commands - interactive: ./runUnit _known_hosts_real.exp --debug - cron/batch: ./runUnit _known_hosts_real.exp --debug /dev/tty40 These are the results for other terminal settings: TERM=vt100 - interactive: OK - cron/batch: ERROR: Commands send to bash are wrapped at 79 chars TERM=vt110 - interactive: OK - cron/batch: ERROR: Commands send to bash are wrapped at 75 chars. ^H (backspaces) appear in output. Maybe we can try to isolate the bug in libreadline5 and see if libreadline5 can be patched or do a bugreport. But at least cron is now working for me again; I'll have a look at the other actual test suite failures. Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] .netrc support for ftp, lftp, sitecopy, [curl, fetchmail, ... wget]
On 091120 15:13, gibbo...@gmail.com wrote:
Should this go into _known_hosts_real ? _known_host_netrc ? ${1} or
SIDE NOTE: If all agree `_known_hosts_real' gets renamed to
`__known_hosts'?
That said, I'd rather have a separate `__hosts_netrc' and keep
`_known_hosts_real' for completing commands who really use ssh's
`known_hosts' files.
I'm confused whether all commands who access hosts can be treated the
same? Right now we gather hostnames from different locations:
- compgen -A hostname (using $HOSTFILE)
- ssh known_hosts files
- avahi-browse
- .netrc
and seem to present them to all commands asking for hostnames. I can
image not every command can cope with all hostnames? Or am I thinking
too complicated? E.g. can `xhost' really cope with all
hostnames/aliases extracted from ssh's known_host files?
Anyway, that's why I think separate __hosts_... functions, being easy to
chain differently in different situations, would be a better choice.
Regards,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Bug#550634: mutt mailbox autocompletion broken
tags 550634 confirmed fixed-upstream ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Bug#549550: [PATCH] bash-completion: Defined functions clash with user environment
On Sun, Oct 4, 2009 at 12:33 PM, Jari Aalto jari.aa...@cante.net wrote: By installing bash completion package, there are serious environment clashes. The function in the package do not have distinct prefixes to differentiate them from the user's aliases and functions; so there will be an inevitable clash at some point. Thanks for the report/patch. I agree we should really claim a bash 'namespace' by prefixing all functions. But since we have backwards compatibility to worry about if we rename all functions, I think we'd best implement such a major change for a next major release ( 1.1). I've proposed prefixing within the roadmap (see http://wiki.debian.org/Teams/BashCompletion/Proposals/Roadmap) as an objective for version 2.0 (?): * create namespace by prefixing all functions with ...? Maybe we'd better vote about the prefix also. I was thinking of using `comp_' and `_comp_' prefixes. Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] RFC: complete only long options where they exist and work
On Tue, Sep 29, 2009 at 7:28 PM, Ville Skyttä ville.sky...@iki.fi wrote: I'd like to suggest that when we complete available options, we'd generally offer only the long options as completions if an option has a short option/alias/other counterpart and if it is known that the long option works well enough (basically if the long option takes no arguments, or takes an argument that can be separated with space (not only =, but possibly both), it is ok). For example, if let's say -f, -F, and --foo are equivalent, we offer only --foo out of them when $cur = -*. +1 Hadn't thought of it, but completing one-letter options makes little sense indeed. Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] dd completion not working (was: Fwd: [arch-general] dd and bash_completion)
On Thu, Sep 24, 2009 at 6:36 PM, David Paleino d.pale...@gmail.com wrote:
This is due to COMP_WORDBREAKS containing =:
I guess this bug turns up on bash-4 only?
This can be fixed by adding `=' as an argument to `_get_cword' so that
_get_cword on bash-4 doesn't split words on `='.
Done so in commit f871fe4.
Explanation:
Bash-4 breaks COMP_WORDS by characters listed in COMP_WORDBREAKS:
$ echo -n $COMP_WORDBREAKS | od -abc
000 sp ht nl ' = ; | ( :
040 011 012 042 047 076 074 075 073 174 046 050 072
\t \n ' = ; | ( :
015
whereas bash-3 didn't. If you use COMP_CWORDS, this is what you get on
bash-4:
$ dd if=TAB
COMP_CWORD: 2
COMP_CWORDS:
0: dd
1: if
2: =
Bash-3 returns:
COMP_CWORD: 1
COMP_CWORDS:
0: dd
1: if=
To reproduce: Create function `_cword' and let it complete `dd'
_cword() {
echo
echo COMP_CWORD: $COMP_CWORD
echo COMP_CWORDS:
for ((i=0; i ${#comp_wor...@]}; i++)); do
echo $i: ${COMP_WORDS[$i]}
done
}
complete -F _cword dd
By using _get_cword you can overcome this difference.
Greetings,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] scp remote path completion broken?
Commit f733e71e should fix things: _get_cword is restored with the version from commit f6497298 as __get_cword3() for bash3. bash-4 now uses __get_cword4() which should solve scp's remote path completion on bash-4. Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] scp remote path completion broken?
I've been mixing up bash-3 and bash-4 :-( But now I know, these are my findings: Commit f6497298 actually fixed quoted arguments under bash-3. Bug #474094 is actually fixed under bash-3, but reappears under bash-4 as it did at my box... It appears the contents of COMP_CWORDS has changed as of bash-4: The programmable completion code now uses the same set of characters as readline when breaking the command line into a list of words. This affects quoted arguments. When completing this: $ a 'b cTAB bash-3 is returning this: COMP_CWORD: 1 COMP_CWORDS: 0: a 1: 'b c whereas bash-4 is returning: COMP_CWORD: 3 COMP_CWORDS: 0: a 1: ' 2: b 3: c The old _get_cword gives better results on bash-4 because it's not relying on COMP_CWORDS and allows for temporarily disabling of COMP_WORDBREAKS characters. But the old _get_cword fails on bash-4 with quoted arguments. I tried fixing _get_cword with quoted arguments under bash-4, but it's becoming rather difficult since quotes can be escaped in so many ways and COMP_WORDS is of so little help now. I'm going to ask on the bug-bash mailing list for a KISS solution. In the mean time I'll restore _get_cword like this: if bash-4 old _get_cword using COMP_WORDBREAKS (dubbed _get_cword4) else _get_cword of commit f6497298 (dubbed _get_cword3) fi Meaning that under bash-4, _get_cword of quoted arguments will go wrong. All other _get_cwords should give no problems on bash-3 bash-4... Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] scp remote path completion broken?
I'm looking further into _get_cword, but COMP_CWORDS appears to behave
differently depending on the bash-version. Can other people confirm
this? Try this script:
---8--
_cword() {
echo
echo COMP_CWORD: $COMP_CWORD
echo COMP_CWORDS:
for ((i=0; i ${#comp_wor...@]}; i++)); do
echo $i: ${COMP_WORDS[$i]}
done
}
complete -F _cword a
---8--
On bash-4 I get:
$ a 'b cTAB
COMP_CWORD: 3
COMP_CWORDS:
0: a
1: '
2: b
3: c
Whereas on bash-3, bash-2 I get:
$ a 'b cTAB
COMP_CWORD: 1
COMP_CWORDS:
0: a
1: 'b c
Is this because of bash-4 or because of some other setting?
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] scp remote path completion broken?
On Fri, Sep 4, 2009 at 11:50 PM, Ville Skyttäville.sky...@iki.fi wrote:
scp's remote path completion appears broken to me - the : to _get_cword does
not seem to affect anything and thus the hostname always disappears and things
go south from there. On a brief look, it seems to me that _get_cword doesn't
actually do anything with the argument given to it.
This is on Fedora 11, bash 4.0.23. Did I overlook something?
I can confirm the same problem on Ubuntu, bash-4.0-28.
Steps to reproduce the problem:
1. Complete foo with _foo:
_foo() {
cur=$(_get_cword ':')
echo; echo cur: $cur
} # foo()
complete -F _foo foo
2. On bash-3, output is this:
$ foo a:bTAB
cur: a:b
Whereas on bash-4, output is this:
$ foo a:bTAB
cur: b
It looks like processing argument $1 has been dropped from
_get_cword() in commit: f6497298 fixed _get_cword() (2008-06-23),
coming from Ubuntu. David, can you recall what this fixed?
Using the original _get_cword fixes the problem.
I looks we should move the `WORDBREAKS' code back into _get_cword,
or restore the original?
More info:
An explanation for the problem might be, from
http://taskwarrior.org/issues/show/241:
It appears that the real problem may have been with bash 3.x.
According to the bash man page, the env. variable
COMP_WORDBREAKS provides a list of characters that are to
delimit words. In both Fedora 10 and 11 this does contain the
colon (:) character and Fedora 11 (i.e., bash 4) correctly does
delimit at the colon, but Fedora 10 (i.e., bash 3) does not.
Apparently, completion of projects under bash 3 is working only
because of what appears to be a bug in bash 3.
See also E13, http://tiswww.case.edu/php/chet/bash/FAQ:
E13) Why does filename completion misbehave if a colon appears
in the filename?
Filename completion (and word completion in general) may appear
to behave improperly if there is a colon in the word to be
completed.
The colon is special to readline's word completion code: it is
one of the characters that breaks words for the completer.
Readline uses these characters in sort of the same way that bash
uses $IFS: they break or separate the words the completion code
hands to the application-specific or default word completion
functions. The original intent was to make it easy to edit
colon-separated lists (such as $PATH in bash) in various
applications using readline for input.
This is complicated by the fact that some versions of the
popular `bash-completion' programmable completion package have
problems with the default completion behavior in the presence of
colons.
The current set of completion word break characters is available
in bash as the value of the COMP_WORDBREAKS variable. Removing
`:' from that value is enough to make the colon not special to
completion:
COMP_WORDBREAKS=${COMP_WORDBREAKS//:}
You can also quote the colon with a backslash to achieve the
same result temporarily.
This was the original _get_cword before the fix:
# Get the word to complete
# This is nicer than ${COMP_WORDS[$COMP_CWORD]}, since it
# handles cases where the user is completing in the middle of a
# word.
# (For example, if the line is ls foobar,
# and the cursor is here ^
# it will complete just foo, not foobar, which is what the
# user wants.)
#
# Accepts an optional parameter indicating which characters out
# of $COMP_WORDBREAKS should NOT be considered word breaks. This
# is useful for things like scp where we want to return
# host:path and not only path.
_get_cword()
{
local i
local LC_CTYPE=C
local WORDBREAKS=${COMP_WORDBREAKS}
if [ -n $1 ]; then
for (( i=0; i${#1}; ++i )); do
local char=${1:$i:1}
WORDBREAKS=${WORDBREAKS//$char/}
done
fi
local cur=${COMP_LINE:0:$COMP_POINT}
local tmp=${cur}
local word_start=`expr $tmp : '.*['${WORDBREAKS}']'`
while [ $word_start -ge 2 ]; do
local char=${cur:$(( $word_start - 2 )):1}
if [ $char != \\ ]; then
break
fi
tmp=${COMP_LINE:0:$(( $word_start - 2 ))}
word_start=`expr $tmp : '.*['${WORDBREAKS}']'`
done
cur=${cur:$word_start}
echo $cur
}
Regards,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] scp remote path completion broken?
On Sun, Sep 6, 2009 at 11:25 AM, David Paleinod.pale...@gmail.com wrote: Sorry for being of totally no help. Good to have you back though ;-) Maybe this bug has something to do with it: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474094 It's closed but I can still reproduce the bug? $ mkdir 'album first' 'album second' first $ cd 'album TAB album first/ album second/ first/(1) $ cd 'album fTAB $ cd 'first/ (2) $ cd 'album sTAB(3) (1) first shouldn't be in the list of completions (2) album f becomes first instead of album first (3) album s doesn't complete Maybe an experimental _get_cword was checked-in the month after #474094 was closed (2008-05-11)? Regards, Freddy Vulto http://www.fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] scp remote path completion broken?
On Sun, Sep 6, 2009 at 5:27 PM, Ville Skyttäville.sky...@iki.fi wrote: If nobody can remember/decipher exactly what the problematic commit was supposed to fix, I suggest we just revert it and see what breaks. +1, committed e663e1c `_get_cword' is reverted to before commit f6497298. This fixes test 8 (see below), notably by restoring passing an argument to _get_cword to omit characters from $COMP_WORDBREAKS. At the end of `get_cword', `echo $cur' has been changed to `printf %s $cur'. This fixes test 9 (see below). Let's do some heavy testing (add more unit tests?) on _get_cword before releasing bash-completion-1.0-4. I've added unit tests for _get_cword (| = cursor position): 1. a b| should return b 2. a | should return nothing 3. a b|c should return b 4. a b\ c| should return b\ c 5. a 'b c| should return 'b c 6. a b c| should return b c 7. a b:c| should return c 8. a b:c| with WORDBREAKS -= : should return b:c 9. a -n| should return -n Tests 5 6 yield expected failures, see bugreport: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=474094 . At a first glance this bugreport contains useful ideas, so anyone willing to try to make tests 5 6 pass, be sure to have a look there first. To run the automated tests: $ cd test ./runUnit _get_cword.exp This is what my test/log/unit.sum looks after having given the command above: $ cat log/unit.sum Test Run By freddy on Mon Sep 7 00:07:34 2009 Native configuration is i686-pc-linux-gnu === unit tests === Schedule of variations: unix Running target unix Running ./unit/_get_cword.exp ... PASS: a b| should return b PASS: a | should return nothing PASS: a b|c should return b PASS: a b\ c| should return b\ c XFAIL: a 'b c| should return 'b c XFAIL: a b c| should return b c PASS: a b:c| should return c PASS: a b:c| with WORDBREAKS -= : should return b:c PASS: a -n| should return -n PASS: Environment should not be modified === unit Summary === # of expected passes8 # of expected failures 2 Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Bug#525293: Latest patch for bash-completion/1:1.0-3
Hello Paul,
This bug has already been fixed upstream, but not yet released. You
can apply attached patch to fix the problem.
See also: https://alioth.debian.org/tracker/?func=detailaid=311595
(tab Attachments).
To reproduce the problem:
$ cat /tmp/config EOF
Host foo
UserKnownHostsFile /dev/null
UserKnownHostsFile /dev/null
EOF
$ ssh -F/tmp/config TAB
$ ssh -F/tmp/config bash: /dev/null: Permission denied
...
After the patch, completion should succeed without any error Permission
denied:
$ ssh -F/tmp/config TAB
...
Regards,
Freddy Vulto
http://fvue.nl
--- bash_completion.orig 2009-04-02 22:01:39.0 +0200
+++ bash_completion 2009-08-14 12:22:41.0 +0200
@@ -2666,10 +2666,18 @@
fi
if [ ${#conf...@]} -gt 0 ]; then
+ local OIFS=$IFS IFS=$'\n'
# expand path (if present) to global known hosts file
- global_kh=$( eval echo $( sed -ne 's/^[ \t]*[Gg][Ll][Oo][Bb][Aa][Ll][Kk][Nn][Oo][Ww][Nn][Hh][Oo][Ss][Tt][Ss][Ff][Ii][Ll][Ee]['$'\t '']*\(.*\)$/\1/p' ${conf...@]} ) )
+ global_kh=($( sed -ne 's/^[ \t]*[Gg][Ll][Oo][Bb][Aa][Ll][Kk][Nn][Oo][Ww][Nn][Hh][Oo][Ss][Tt][Ss][Ff][Ii][Ll][Ee]['$'\t '']*\(.*\)$/\1/p' ${conf...@]} ))
+ for (( i=0; i ${#global_...@]}; i++ )); do
+ global_kh[i]=$(echo ${global_kh[i]//\/})
+ done
# expand path (if present) to user known hosts file
- user_kh=$( eval echo $( sed -ne 's/^[ \t]*[Uu][Ss][Ee][Rr][Kk][Nn][Oo][Ww][Nn][Hh][Oo][Ss][Tt][Ss][Ff][Ii][Ll][Ee]['$'\t '']*\(.*\)$/\1/p' ${conf...@]} ) )
+ user_kh=($( sed -ne 's/^[ \t]*[Uu][Ss][Ee][Rr][Kk][Nn][Oo][Ww][Nn][Hh][Oo][Ss][Tt][Ss][Ff][Ii][Ll][Ee]['$'\t '']*\(.*\)$/\1/p' ${conf...@]} ))
+ for (( i=0; i ${#user_...@]}; i++ )); do
+ user_kh[i]=$(echo ${user_kh[i]//\/})
+ done
+ IFS=$OIFS
fi
# Global known_hosts files
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] _filedir only escaping whitespace when `-o filenames' is in effect?
On Sun, Aug 2, 2009 at 9:23 PM, Ville Skyttäville.sky...@iki.fi wrote: ...but why wouldn't simply adding $filenames to their complete calls be the right thing to do? The above sounds somewhat messy to me and personally I'd rather start thinking about getting rid of most of _filedir's current contents (when we can assume -o plusdirs) than adding more hair that duplicates existing functionality to it. Because complete $filenames carves `-o filenames' in stone for all the command's completions. I assume $filenames hasn't been added to the aforementioned function list because their main intention is NOT to complete on filenames, yet *sometimes* they whish to do so - calling _filedir. Adding $filenames has the side effect that if a completion happens to have a directory with the same name, a slash will be appended. Take for example, the `ssh' command which essentially completes on hostnames. Adding `-o filenames' would erroneously append a slash if a directory happens to exist with the same name: $ complete -p ssh # Show current ssh completion has no `-o filenames' complete -F _ssh ssh $ mkdir localhost $ ssh locTAB $ ssh localhost# Correct $ complete -o filenames -F _ssh ssh $ ssh locTAB $ ssh localhost/ # Wrong, slash is appended $ rmdir localhost # Cleanup tmp directory You only want to add `-o filenames' to ssh completion when completing specific file-expecting options, like ssh's -F, -i or -S. I don't see how `-o plusdirs' is going to save us here? I think our only saviour is the `compopt' command (bash = v4) *1) which allows you to modify completion options for the currently-execution completion - in contrast to having the options 'carved in stone'. Unfortunately we don't have `compopt' in bash-3, and I'm reluctant to add `-o filenames' everywhere - introducing the bug mentioned above. So I think our only options are to wait for bash-4 or to fix _filedir working correctly also if `-o filenames' isn't in effect. Maybe we can even make the new _filedir do some introspection and make it look for itself if `-o filenames' is in effect - changing it's behaviour on the fly. *1) http://gnu.april.org/software/bash/manual/html_node/Programmable-Completion-Builtins.html Greetings, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] _filedir only escaping whitespace when `-o filenames' is in effect?
I just noticed `ssh -F TAB' doesn't escape spaces in filenames.
Further investigation showes that _filedir only works if `-o
filenames' is in effect:
$ touch 'a b'
$ _foo() { cur=$(_get_cword); _filedir; }
$ complete -F _foo foo
$ foo aTAB
$ foo a b # Incorrect, space isn't escaped
$ complete -o filenames -F _foo foo
$ foo aTAB
$ foo a\ b # This is correct
I was under the assumption that `_filedir' was to be trusted
anywhere, but it seems it isn't or am I overlooking something?
Otherwise, wouldn't it be nice to add an option to `_filedir' to
escape spaces? Or better, create a new function `_compgen_filedir'
with this optional behaviour ;-)? At least the following
completions have the same problem at the point where they call
`_filedir', because they don't have `-o filenames' ($filenames) in
effect:
../bash-completion/contrib$ for f in $(grep -l _filedir *)
do
grep -L \$filenames $f
done
aptitude
bitkeeper
bittorrent
bluez-utils
cfengine
cksfv
clisp
cpan2dist
cpio
dhclient
dsniff
freeciv
gcl
gkrellm
gpg
gpg2
heimdal
lilo
lisp
lvm
minicom
mkinitrd
munin-node
ntpdate
openldap
openssl
rpmcheck
samba
sbcl
screen
smartctl
strace
tcpdump
update-alternatives
vncviewer
vpnc
wvdial
xm
Regards, Freddy
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] hostname completion issues
On Sat, Jul 25, 2009 at 6:28 PM, Ville Skyttäville.sky...@iki.fi wrote:
On Saturday 25 July 2009, Guillaume Rousse wrote:
I like the idea, but using stdout for output would force to use
subshells to get the result.
[...]
I guess there would be additional overhead added.
It would also require the caller to take care of $IFS stuff, whereas if adding
directly to an array, functions can take care of that internally as
appropriate.
The helper functions already do a subshell and this gets removed, so
isn't the overhead only in each caller repeating a subshell
assignment - not in doing an additional subshell?
However, to avoid the redundancy, what about two helper-helper
functions `_compfset' and `_compfadd' - defaulting to IFS=$'\t\n':
# @param $1 Function id
# @param $2 CWORD to complete on
_compfadd() {
local IFS=$'\t\n'
COMPREPLY=( ${comprep...@]:-} $( _compgen_$1 $2) )
}
# @param $1 Function id
# @param $2 CWORD to complete on
_compfset() {
COMPREPLY=()
_compfadd $@
}
_compgen_pci_ids() {
compgen -W $( lspci -n | awk '{print $3}') -- $1
}
_compgen_filedir() { ... }
etc.
Then we could have something as:
case f)
_compfset filedir $cur
The `_compfadd', `_compfset' and `_compgen_...' functions can be
adorned with additional options for prefixes and suffixes, as bash's
`compgen': [-P prefix] [-S suffix].
What do you think?
Regards,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Bug#535585: Bug#535585: ssh: only sees foo in 'Host foo bar baz' in .ssh/config
On Fri, Jul 3, 2009 at 3:11 PM, Trent W. Bucktrentb...@gmail.com wrote: you can have multiple patterns Host foo.example.net bar.example.net Port 443 AFAICT bash-completion only sees the first one. I'd like it to complete all of them. Bonus points will be awarded if you can work out an intelligent way to handle globbing patterns, e.g. Host *.example.net *.example.com Port 443 Fixed in git commit 3fe193f81a3e. I'll leave the bonus points for now... Within _known_hosts_real, IFS was set to just newline (\n), whereas `compgen -W' relies on IFS being space-tab-newline ( \t\n) to expand hostnames which are separated by whitespace. Thanks for reporting, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] hostname completion issues
On Thu, Jun 18, 2009 at 10:34 AM, Guillaume Rousseguillaume.rou...@inria.fr wrote: And I favor the splitted solution because: - calling directly the function with the proper behaviour is faster than having this function test its argument at runtime to select which behavior to use - distinguishing between completion functions (those directly attached to a command) and helper functions (those called by completion functions) make the code easier to maintain Right now the differences are that _known_hosts: - clears COMPREPLY (_known_hosts_real does not) - determines cur=`get_cword` (_known_hosts_real does not) I think I'm in favour of the splitted solution as well (especially because of the unnecessary calls to `get_cword'), although I'd prefer another name instead of `..real'. Maybe we can call these helper functions `add...', e.g. `_add_known_hosts', since they *add* to COMPREPLY where the directly called functions *set* COMPREPLY. More suggestions? Should we rename all helper functions, e.g. _filedir _filedir_real (or _add_filedir), _services _services_real (or _add_services), etc.? Or is this something to defer till after we branched off bash-2 support? Another issue regarding function names, maybe also better to do till after we dropped bash-2 support, is namespaces. We're using quite common function names and I can image bash completion functions clashing with user defined functions, e.g. _cd(). Shouldn't we prefix all functions with _bc_ or _comp or ? (suggestions?) to simulate some kind of namespace in which we avoid function name conflicts out there? - bash isn't wise enough to to distinguish between an empty string argument and an non-existing one: calling the '_known_host -a' function with no current host will call '_known_host_real -h -a', and result in completion for hosts called -a* I'm not sure if this is really the problem or if this happened because getopts encountered an empty string in the middle of the options (see previous reply)? Turning the -h option into a mandatory argument is fine with me too, I think I don't really understand your point, but feel free to change. I see e.g. _filedir and _services are also relying on a global `cur' :-( I think it would be better for all helper functions not to rely on globals and pass `cur' to them as an option/argument? But maybe this is not the right time/branch to change it all. Maybe we should try to get more consensus about what everybody think is desired. We can also restore the `ocur' backup variable to `_known_hosts_real' so at least all helper functions are working the same, i.e. relying on global `cur'. Greetings, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] hostname completion issues
On Wed, Jun 17, 2009 at 10:26 PM, Ville Skyttäville.sky...@iki.fi wrote: Some recent changes (known hosts stuff?) have broken ssh hostname completion quite badly for me in git master. ... This is with bash 3.2.39(1)-release. Anyone else seeing this? Anyone working on known hosts completion? Yes, I'm having the same problem. I think it's caused by my recent changes concerning _known_hosts_real. From a quick look it appears the `getopts' in _known_hosts_real isn't catching the -h $cur option. I'll have a further look as soon as I have some more time. The shell functions and builtins should only have been returned when argc 1. I'd accidentally removed this. I'll upload the fix. Greetings, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
[Bash-completion-devel] Merging _known_hosts_real with _known_hosts again
Guillaume, about commit: d5fd1c34120c6bae2cf459e386aa08c6bc7ad223: split split _known_hosts into _known_hosts and _known_hosts_real, instead of using an option to set current word I'm having troubles with _known_hosts_real. I already added: [ $ocur ] cur=$ocur || unset -v cur at the end, because _known_hosts_real is relying on global `cur' but subsequently messes it up. I'm not really satisfied with my added line. I think splitting has made things overcomplicated, so I'm thinking of merging them back again. Can you recall what the split fixed? Maybe I can write an automated test for it. ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] roadmap ?
On Thu, Jun 11, 2009 at 10:05 PM, Guillaume Rousseguillaume.rou...@inria.fr wrote: David Paleino a écrit : Agreed, go change the wiki now! ;) Done, according to various replies. I'll keep on working on the test suite in the mean time, supposing the `test' `doc' directories are not standing in the way of releasing 1.1 without them? ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Style guide (was: Re: [SCM] bash-completion branch, master, updated. 95cd673b5cbd5658cbf56a56a4113722aab92177)
On Fri, Apr 17, 2009 at 9:52 PM, Ville Skyttä ville.sky...@iki.fi wrote: This is my first experience with asciidoc (tried 8.4.3), and I must say I'm not too impressed. Does this mean one needs to know the DocBook DTD and be able to write the docs in a asciidoc/plaintext format that kind of conforms to the DTD, instead of asciidoc just taking care of that stuff? If so, doesn't sound too interesting. $ ./makeHtml.sh ./main.xml:18: element preface: validity error : Element preface content does not follow the DTD, expecting (...), got (title) ... a2x: failed: xmllint --nonet --noout --valid ./main.xml Installing asciidoc-8.4.3 (was asciidoc-8.2.6) gave me the same problem. I fixed it by adding a `Preface' section to main.txt. This is what AsciiDoc has to say about this gotcha: (from http://www.methods.co.nz/asciidoc/userguide.html#_gotchas): Invalid output AsciiDoc attempts to validate the input AsciiDoc source but makes no attempt to validate the output markup, it leaves that to external tools such as xmllint(1) (integrated into a2x(1)). Backend validation cannot be hardcoded into AsciiDoc because backends are dynamically configured. The following example generates valid HTML but invalid DocBook (the DocBook literal element cannot contain an emphasis element): +monospaced text with an _emphasized_ word+ It is possible to omit the DocBook DTD validation by adding `-L' or `--no-xmllint' to `a2x', but I think adhering to the DocBook DTD is the way to go. Another solution would be to let AsciiDoc generate HTML without using DocBook (from http://www.methods.co.nz/asciidoc/userguide.html#_html_generation): HTML generation AsciiDoc produces nicely styled HTML directly without requiring a DocBook toolchain but there are also advantages in going the DocBook route: - HTML from DocBook includes automatically generated indexes, tables of contents, footnotes, lists of figures and tables. - DocBook toolchains can also (optionally) generate separate (chunked) linked HTML pages for each document section. - Toolchain processing performs link and document validity checks. - If the DocBook lang attribute is set then things like table of contents, revision history, figure and table captions and admonition captions will be output in the specified language (setting the AsciiDoc lang attribute sets the DocBook lang attribute). On the other hand, HTML output directly from AsciiDoc is much faster, is easily customized and can be used in situations where there is no suitable DocBook toolchain (see the AsciiDoc website for example). This can be done with: $ asciidoc -d book main.txt Or just generating a particular section, e.g.: $ asciidoc -d book styleguide.txt Hope this helps in gaining confidence using AsiiDoc. Greetings, Freddy Vulto ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Style guide (was: Re: [SCM] bash-completion branch, master, updated. 95cd673b5cbd5658cbf56a56a4113722aab92177)
On Fri, Apr 17, 2009 at 9:52 PM, Ville Skyttä ville.sky...@iki.fi wrote: This is my first experience with asciidoc (tried 8.4.3), and I must say I'm not too impressed. Does this mean one needs to know the DocBook DTD and be able to write the docs in a asciidoc/plaintext format that kind of conforms to the DTD, instead of asciidoc just taking care of that stuff? If so, doesn't sound too interesting. I don't think one needs to know the DocBook DTD and I agree that AsciiDoc should just take care of that stuff. I was using standard Ubuntu package asciidoc-8.2.6 a2x-1.0.0 which generates compiles docbook-4.2 without errors. So I think it's just a version issue and that our main AsciiDoc structure needs fixing. I'll try upgrading and see what happens. I've been looking at various formats. DocBook XML seems a logical choice, but I don't like the verbosity of reading/writing plain XML. A standardized wiki language Creole I didn't think as mature as AsciiDoc. For me AsciiDoc looks like the perfect approach as we can generate everything from man to web pages (just as Git, which is using Asciidoc too), and we have readable plain text to maintain. Regards, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] [Bash-completion-commits] [SCM] bash-completion branch, master, updated. 5ece6956cf2410185616dfec92b301d28fafcec3
On Thu, Apr 16, 2009 at 8:43 AM, David Paleino d.pale...@gmail.com wrote: Use \n instead of \r\n as line separator Hello David, Actually `main.xml' is generated: maybe we'd better put in the git ignore list or specify a tmp directory. `main.txt' is the main file to edit. The `a2x' command in `makeHtml.sh' converts `main.txt` to `main.xml` and further to html. I don't know where the \r\n comes into play. Greetings, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Style guide (was: Re: [SCM] bash-completion branch, master, updated. 95cd673b5cbd5658cbf56a56a4113722aab92177)
On Tue, Apr 14, 2009 at 8:50 PM, Ville Skyttä ville.sky...@iki.fi wrote: Yeah... why not :). Anyone want to write a style guide? Here's a start for a table of contents, in no particular order: I'm in the process of writing documentation for the test suite and I'd like to propose using asciidoc: http://www.methods.co.nz/asciidoc/ for all bash completion documentation. I'll add a `doc' subdirectory as a proposal to master, with an additional style guide section (just the title ;-) Greetings, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] wget completion
On Fri, Mar 20, 2009 at 1:22 PM, gibbo...@gmail.com wrote:
- I *tried* the completion of the beginning of the host. But I
can't get the -o nospace working :[
You have to add the `-o nospace' option after `complete' instead of
`compgen'. See diff.
Another problem is that after 'http', 's://' and '://' ARE
proposed BUT all is messed up with filename completion if I add a
':' (maybe because of the slash or something around $IFS ?).
You can take a look at `scp' completion in file `contrib/ssh' which
already solves processing `:'. Note the: cur=`_get_cword :` (?)
I found it difficult though: I tried copying things to wget
but couldn't get it work. Maybe you can give it a try.
[parenthesis]
It makes me think : would an algorithm to convert a regexp in
a completion script like this be useful ?
--- (ht|f)tps?://(www.)?
--- (h = http, ht = http, f = ftp, http = ( http:// https://),...)
--- h) COMPREPLY=( $( compgen -o nospace -W 'http' -- $cur ) );return 0;;...
[/parenthesis]
Or use bash parameter expansion (see also diff):
COMPREPLY=( $( compgen -W http{,s}://{,www} ftp://; -- $cur ) )
Regards,
Freddy Vulto
http://fvue.nl
---8---
--- wget.sh.orig2009-03-20 22:20:13.0 +0100
+++ wget.sh 2009-03-20 22:55:39.0 +0100
@@ -93,23 +93,11 @@
COMPREPLY=( $( compgen -W $(wget -h | sed -n 's/^[
[:blank:]]*\(-[a-zA-A46]\).*$/\1/p') -- $cur ) )
return 0
;;
- h)
- COMPREPLY=( $( compgen -o nospace -W 'http' -- $cur ) )
- return 0
- ;;
- f)
- COMPREPLY=( $( compgen -o nospace -W 'ftp://' -- $cur ) )
- return 0
- ;;
- http)
- COMPREPLY=( $( compgen -W 'http:// https://' -- $cur ) )
- return 0
- ;;
- https\?://w)
- COMPREPLY=( $( compgen -W ${cur}ww. -- $cur ) )
+ *)
+ COMPREPLY=( $( compgen -W http{,s}://{,www} ftp://; -- $cur ) )
return 0
;;
esac
return 0
}
-complete -F _wget -o default wget
+complete -F _wget -o nospace wget
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] wget completion
gibboris at gmail.com writes:
Hello,
I just tried a first attempt for the wget completion (see attachement).
Here're some thoughts. See also proposed diff at the end.
The `=' in long options isn't mandatory for wget, so I personally
think you'd better leave them off as default suffix. The `='-suffix
has also recently been removed from the `alias' completion as the
thought was to keep completion minimalistic. Another problem with
appending `=' is that unless you specify `-o nospace', a superfluous
space is appended after the `='. Problem with `-o nospace' is that
it's either set or unset for *all* wget completions:
complete-options cannot be modified from within a completion
(bash-4.0 contains a `compopt' builtin which supposedly makes this
possible).
Users may or may not use the `=' option assignment. We can support
both users by splitting the current word on `=' at the beginning of
`_wget()'. See diff.
But maybe you can omit completing long options and call `_longopt()'
for that? (Perhaps we should drop '='-suffixing from _longopt() as
well because of the nospace problem?) See diff.
The `I' sed-modifier is a GNU-extension to sed and therefore cannot
be used for the bash-completion package.
- long option where a short option exists are not given in the
completion of long options ([ [:blank:]]), why ? Don't know
myself, but I feel I should handle them separatly.
I'm not sure what's your intention but I found it annoying and
counter-intuitive as I tend to remember long options and I'm missing
options, e.g. --output-file...
- any way to complete (or at least to give a clue about the value
expected) for an option waiting for a numeric parameter ?
I don't know of any way to do this without violating the minalistic
approach... So perhaps we shouldn't want this.
- doubts about completion of main argument, ideas :
f -- tp://
h -- ttp
http -- s:// | ://
w | http://w; | https://w; -- www.
Seems useful to me.
Greetings,
Freddy Vulto
http://fvue.nl
---8-
--- wget.sh.orig2009-03-18 21:30:04.0 +0100
+++ wget.sh 2009-03-18 21:03:42.0 +0100
@@ -12,6 +12,12 @@
cur=`_get_cword`
prev=${COMP_WORDS[COMP_CWORD-1]}
+# If `cur' is long option containing `=', reassign prev and cur
+if [[ $cur == --*=* ]]; then
+ prev=${cur/=*}
+ cur=${cur/*=}
+fi
+
case $prev in
--progress)
COMPREPLY=( $( compgen -W 'bar dot' -- $cur ) )
@@ -64,19 +70,10 @@
case $cur in
--*)
- #parametered ones first (only those defined above)
- #then long non-parametered ones
- COMPREPLY=( $( compgen -W --progress --bind-address
--restrict-file-names
--prefer-family
---directory-prefix \
- --load-cookies --save-cookies --post-file --certificate
--ca-certificate
--private-key
---random-file \
- --egd-file --secure-protocol --append-output --input-file \
- --certificate-type --private-key-type --ca-directory
--exclude-domains
--domains --follow-tags
---ignore-tags \
- \
- $(wget -h | sed -n 's/^[ [:blank:]]*\(--[a-z-]*\)[
[:blank:]].*$/\1/Ip')
-- $cur ) )
+ _longopt wget
return 0
;;
+
-*)
COMPREPLY=( $( compgen -W $(wget -h | sed -n 's/^[
[:blank:]]*\(-[a-z46]\).*$/\1/Ip') -- $cur ) )
return 0
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] vncviewer
On Tue, Mar 3, 2009 at 11:49 AM, Guillaume Rousse guillaume.rou...@inria.fr wrote: assuming `/usr/bin/vncviewer' is a symlink to `tightvncviewer' on your machine? No, it is not, that's what I'm trying to explain :) We only have one only 'vncviewer' in the distribution, from the 'tightvnc' package, and it's the actual executable name. I think we should try to find a generic way to handle distributions difference, and that way may eventually be manageable at the packaging level, not mandatorily at runtime. Maybe both solutions are needed. I think the runtime-symlink-resolving-solution would address the Debian-alternatives system which can happen at runtime. Are the options below feasible as a package-level solution on Mandriva (without waiting for the new directory layout)? 1. If the `tightvnc' package would provide its own completion: Let the `tightvnc' package install a file `$BASH_COMPLETION_DIR/tightvncviewer' to complete `vncviewer'. This would override any default `vncviewer' completion installed by bash-completion. 2. If the `tightvnc' package would rely on bash-completion: Provided that bash-completion installs `xvnc4viewer' and `tightvncviewer' completion as separate files, the `tightvnc' package could install a file in $BASH_COMPLETION_DIR containing: . /etc/bash_completion/contrib/tightvncviewer complete -F _tightvncviewer vncviewer Regards, Freddy Vulto http://fvue.nl ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] vncviewer
On Tue, Mar 3, 2009 at 3:12 PM, Mike Kelly pi...@pioto.org wrote:
Actually, which is available on every UNIX system I've ever used...
What you actually want is $(type -P vncviewer). Otherwise, if they
have set alias vncviewer='vncviewer -foo' somewhere, type -p returns
nothing, while type -P will return the expected results.
Also, readlink -f isn't portable -- it doesn't work on FreeBSD, at
least. On FreeBSD, you need to use realpath instead.
Then I suggest we use `type' instead of `which', since `type' is a
builtin. What do you think about this code then:
---8---
# Get real command.
# @param $1 Command
# @stdout Filename of cmd in PATH, possible symbolic links resolved.
# @return True (0) if command found, False ( 0) if not.
_realcommand() {
if type -p realpath /dev/null; then
realpath $(type -P $1)
elif type -p readlink /dev/null; then
readlink -f $(type -P $1)
else
echo $1
fi
}
have vncviewer
_vncviewer_bootstrap() {
local fname
case $(_realcommand vncviewer) in
*xvnc4viewer) fname=_xvnc4viewer;;
*tightvncviewer|*) fname=_tightvncviewer ;;
esac
# Install real completion for subsequent completions
complete -F $fname vncviewer
$fname # Generate completions once for now
unset -f _vncviewer_bootstrap
}
complete -F _vncviewer_bootstrap vncviewer
---8---
If we would let the `_vncviewer_bootstrap' `*-case' default to
`_tightvncviewer' this solution is gonna work on Mandriva... untill
a distribution comes along with another default `vncviewer' :-( so
we still can improve with a package-level solution indeed.
Regards,
Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] ./current r1326: Improved s trace completion, undefined _command_offset( ) found.
Freddy Vulto fvulto at gmail.com writes:
Debian is giving me whole other problems though:
$ sudo rpm -q TABrpm: To install rpm packages on Debian systems, use
...
bash: bad substitution: no closing `)' in $(
compgen -d -- $(quote_readline $cur) | {
while read -r tmp; do
# TODO: I've removed a [ -n $tmp ] before,
It appears that: both single and double quotes, appearing in a comment within a
subshell, causes the error above, up to and including bash-3.1. See also:
http://www.mail-archive.com/bug-b...@gnu.org/msg01667.html
I'm moving the `TODO' comment outside of the subshell.
Regards, Freddy Vulto
http://fvue.nl
___
Bash-completion-devel mailing list
Bash-completion-devel@lists.alioth.debian.org
http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Roadmap proposal
David Paleino d.paleino at gmail.com writes: On Fri, 13 Feb 2009 14:14:29 + (UTC), Freddy Vulto wrote: [..] maybe we'd better release bash_completion-2 (or ..200902xx) [..] I was starting a branch for the release process... what version number you believe is sane? I'd start at 1.0, (so as not to be necessarily linked to the bash version), and the date format is kinda weird to me. 1.0 is fine with me too - better than date format, as long as the major number is going to be increased once we drop bash-2 support. Can you elaborate on which releases you have in mind? Regards, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
Re: [Bash-completion-devel] Roadmap proposal
David Paleino d.paleino at gmail.com writes: On Fri, 13 Feb 2009 00:11:41 +0200, Ville Skyttä wrote: On Wednesday 04 February 2009, David Paleino wrote: On Wed, 04 Feb 2009 21:59:25 +0100, Guillaume Rousse wrote: I'd insert the following items between 1 and 2, or between 2 and 3: - finish splitting every command into its own file - finish reviewing new completions Agreed. I'd rather see a real release being made before split every command takes place, no objections otherwise. Well, releasing another headache-making bash-completion doesn't really sound good to me :) Isn't there a concern that splitting every command into its own file is going to make bash_completion slower? If so, maybe we'd better release bash_completion-2 (or ..200902xx) with the improvements made so far, stop supporting bash-2, branch and make the splitting every command into its own file part of the new branch: bash_completion-3? Regards, Freddy ___ Bash-completion-devel mailing list Bash-completion-devel@lists.alioth.debian.org http://lists.alioth.debian.org/mailman/listinfo/bash-completion-devel
