Re: Specify completion without name
Clark J. Wang wrote: On Fri, Jan 6, 2012 at 00:33, Peng Yu pengyu...@gmail.com wrote: But beware to clearly document these by giving working EXAMPLE code which include these three commands (not just text explanation without working code, by working code I mean code snippet is discouraged, a complete completion function should be provided). The bash man page already has ~70 pages manual. I don't like it to grow to ~700 pages (like the ABS Guide) with all the working examples you expected. :) Vs. having things undocumented, as is the case in the current bash man page. I think the bash doc maintainers would benefit greatly by looking at the perl manpages, which generally do a good job of documenting a complex product. Like... compat40 mentions it changes behavior, about interrupting a command list, yet try to find out what that behavior is, or what compat40 would change it 'to'? Or how about, does compat 31 imply compat32 and compat40? If not, does that really mean compat31 is really 'compat31', or just use feature 3.1 to specify that a specific feature be used in it's 3.1 version vs. a newer version. I agree insomuch as if every new incompatibility had to be thoroughly documented, the impact of such incompatibilities might be more thoroughly thought out, not to mention the benefit for users trying to read the man page to program by...
Re: Specify completion without name
On 1/11/12 3:03 PM, Linda Walsh wrote: Like... compat40 mentions it changes behavior, about interrupting a command list, yet try to find out what that behavior is, or what compat40 would change it 'to'? Thanks, I added that to the description. It means that bash versions later than 4.0 interrupt a list when one of the commands in the list terminates due to SIGINT and job control is in effect; previous versions just continued on. Or how about, does compat 31 imply compat32 and compat40? If not, does that really mean compat31 is really 'compat31', or just use feature 3.1 to specify that a specific feature be used in it's 3.1 version vs. a newer version. There is only a single shell compatibility level; the last variable set wins. The compatibility level variables are mutually exclusive. The descriptions of each option are self-contained. That's why the descriptions for compat32 and compat40 include the same text concerning using strcoll for and comparisons (and why the description for compat31 should include it as well). The COMPAT file in the bash distribution has a much more extensive description of incompatibilities between versions. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Specify completion without name
On 1/4/12 10:37 PM, Peng Yu wrote: empty lines. There is no programmable completion mechanism to complete on non-empty command names. I'm wondering if it is worthwhile to add such a feature. I have run into the problem that it is very slow to command complete an incomplete command especially when other programs are accessing the disk (note that I frequently open new terminals, so the caching done within a bash process does not help me much). That's a pretty good idea. I'll take a look and see what I can do. I have a feeling the most difficult part of the whole exercise will be choosing an appropriately mnemonic option letter. If I can configure how to complete on non-empty command names, I could just check a file with all the commands in PATH are stored. By checking just a single file, presumable the search can be much faster than searching many directories. Presumably you would also include aliases, shell builtins, and functions in this file. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Specify completion without name
Presumably you would also include aliases, shell builtins, and functions in this file. Yes. I just want to replace executables in PATH by the result from my custom function. I think that aliases, builtins, and functions are all in the memory of bash already, so it doesn't take extra time to search them from bash. Therefore, the ideal behaviors is that bash still search for aliases, builtins and functions, and in addition check the results returned by my custom function. Hence, my custom function should not return anything about them (this should be expect at least by default). -- Regards, Peng
Re: Specify completion without name
On 1/5/12 10:21 AM, Peng Yu wrote: Presumably you would also include aliases, shell builtins, and functions in this file. Yes. I just want to replace executables in PATH by the result from my custom function. I think that aliases, builtins, and functions are all in the memory of bash already, so it doesn't take extra time to search them from bash. Therefore, the ideal behaviors is that bash still search for aliases, builtins and functions, and in addition check the results returned by my custom function. Hence, my custom function should not return anything about them (this should be expect at least by default). That's inelegent, and it's inconsistent with how programmable completion works. A shell function run for programmable completion has complete control over the possible completions, as modified by options like -o bashdefault, not replacing only portions of the default completions to solve some perceived performance problem. I would envision that such a completion function would assemble its list of possible completions by using your read-from-a-file mechanism and augment the list using compgen -a/compgen -b/compgen -A function. It would probably also want to handle glob patterns and expand them to potentially multiple completions, but that gets tricky. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Specify completion without name
I would envision that such a completion function would assemble its list of possible completions by using your read-from-a-file mechanism and augment the list using compgen -a/compgen -b/compgen -A function. It would probably also want to handle glob patterns and expand them to potentially multiple completions, but that gets tricky. I did not know that it is so simple to get the alias (compgen -a), buildins (compgen -b) and functions (compgen -A function) as you mentioned. Once I know these, I agree with you that bash need not handle these internally, rather user can call these three functions directly. But beware to clearly document these by giving working EXAMPLE code which include these three commands (not just text explanation without working code, by working code I mean code snippet is discouraged, a complete completion function should be provided). BTW, as I mentioned several times the bash man favors document maintainer rather readers. For example, the following help doesn't help me much when I want to learn how to use compgen. ~$ help compgen compgen: compgen [-abcdefgjksuv] [-o option] [-A action] [-G globpat] [-W wordlist] [-P prefix] [-S suffix] [-X filterpat] [-F function] [-C command] [word] Display the possible completions depending on the options. Intended to be used from within a shell function generating possible completions. If the optional WORD argument is supplied, matches against WORD are generated. The manpage also use a reference rather than list all the options directly. Readers have to jump to complete to understand how to use compgen. This is also inconvenient to users. Generate possible completion matches for word according to the options, which may be any option accepted by the complete builtin If you consider it repetitive to discuss the same option twice in both compgen and complete, at least, you can expand help compgen to describe all the options (merge the current description of compgen and complete in man). Other help messages are so concise that they are not very helpful for learning how to use them. I'd suggest change all of them as well. -- Regards, Peng
Re: Specify completion without name
On Fri, Jan 6, 2012 at 00:33, Peng Yu pengyu...@gmail.com wrote: I would envision that such a completion function would assemble its list of possible completions by using your read-from-a-file mechanism and augment the list using compgen -a/compgen -b/compgen -A function. It would probably also want to handle glob patterns and expand them to potentially multiple completions, but that gets tricky. I did not know that it is so simple to get the alias (compgen -a), buildins (compgen -b) and functions (compgen -A function) as you mentioned. Once I know these, I agree with you that bash need not handle these internally, rather user can call these three functions directly. But beware to clearly document these by giving working EXAMPLE code which include these three commands (not just text explanation without working code, by working code I mean code snippet is discouraged, a complete completion function should be provided). The bash man page already has ~70 pages manual. I don't like it to grow to ~700 pages (like the ABS Guide) with all the working examples you expected. :) BTW, as I mentioned several times the bash man favors document maintainer rather readers. For example, the following help doesn't help me much when I want to learn how to use compgen. ~$ help compgen compgen: compgen [-abcdefgjksuv] [-o option] [-A action] [-G globpat] [-W wordlist] [-P prefix] [-S suffix] [-X filterpat] [-F function] [-C command] [word] Display the possible completions depending on the options. Intended to be used from within a shell function generating possible completions. If the optional WORD argument is supplied, matches against WORD are generated. The manpage also use a reference rather than list all the options directly. Readers have to jump to complete to understand how to use compgen. This is also inconvenient to users. Generate possible completion matches for word according to the options, which may be any option accepted by the complete builtin If you consider it repetitive to discuss the same option twice in both compgen and complete, at least, you can expand help compgen to describe all the options (merge the current description of compgen and complete in man). Other help messages are so concise that they are not very helpful for learning how to use them. I'd suggest change all of them as well. -- Regards, Peng
Re: Specify completion without name
The bash man page already has ~70 pages manual. I don't like it to grow to ~700 pages (like the ABS Guide) with all the working examples you expected. :) Do you use search at all? :) If you use search, it doesn't really matter if is a 700 page manual. -- Regards, Peng
Specify completion without name
Hi, I want to customize the command completion for completing executables, I want to search in a file (which includes all the executables in PATH) rather than the default PATH variable. But I don't see how to do so, as the following help indicates that it can only configure how to complete the arguments of a command. Does anybody know how to configure command completion for the name itself rather than its arguments? Thanks! ~/Downloads$ help complete complete: complete [-abcdefgjksuv] [-pr] [-o option] [-A action] [-G globpat] [-W wordlist] [-P prefix] [-S suffix] [-X filterpat] [-F function] [-C command] [name ...] For each NAME, specify how arguments are to be completed. If the -p option is supplied, or if no options are supplied, existing completion specifications are printed in a way that allows them to be reused as input. The -r option removes a completion specification for each NAME, or, if no NAMEs are supplied, all completion specifications. -- Regards, Peng
Re: Specify completion without name
On 1/4/12 8:54 PM, Peng Yu wrote: Hi, I want to customize the command completion for completing executables, I want to search in a file (which includes all the executables in PATH) rather than the default PATH variable. But I don't see how to do so, as the following help indicates that it can only configure how to complete the arguments of a command. If you upgrade, bash-4.1 added the `-E' option to complete to complete on empty lines. There is no programmable completion mechanism to complete on non-empty command names. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: Specify completion without name
empty lines. There is no programmable completion mechanism to complete on non-empty command names. I'm wondering if it is worthwhile to add such a feature. I have run into the problem that it is very slow to command complete an incomplete command especially when other programs are accessing the disk (note that I frequently open new terminals, so the caching done within a bash process does not help me much). If I can configure how to complete on non-empty command names, I could just check a file with all the commands in PATH are stored. By checking just a single file, presumable the search can be much faster than searching many directories. -- Regards, Peng -- Regards, Peng
