Re: bug in force_interactive handling
05.01.2012 06:50, Chet Ramey wrote: So you'd like the shell to act on a signal without `consulting' the foreground job? For only the dedicated traps. For example: trap -b /bin/true USR1 -b here would mean that the foreground job, if any, is to be moved to the background before executing the command. Since the command is not really needed (I only need to move the job to the background), I specified /bin/true as an example, and in my previous example I used bg which was not needed too.
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/
Issue with errtrace
Hi all, Recently upgraded to 3.2 and noticed some differences in a lot of my scripts, consider the following example: #!/bin/bash trap error_reporter ERR set -o errexit set -o errtrace set -o nounset set -o pipefail logf_error=/dev/null function _exit { local -ri retval=${1:-$?} exit ${retval} } function error_reporter { local -ri retval=$? #echo Error in script setup. Exiting with error value ${retval}. local -i i=0 #echo Function call stack: 2 while caller $i 2; do (( i++ )); done _exit ${retval} } function echo_ { #this is called as a $(command) #a subcommand might return with 1 in the script, but in most cases it is not a problem. #At least in our scripts there are a lot of cases like this where the error is handled afterwards echo | grep b echo Execution continues } echo Turning off errtrace set +o errtrace var=$(echo_)#calling as a $(command) echo $var echo Turning on errtrace set -o errtrace echo Next command will fail in bash3.2 var=$(echo_)#calling as a $(command) echo $var Doesnt work right on 3.2 Output from 3.0 root@atrcus365:/# /tmp/test /tmp/test Turning off errtrace Execution continues Turning on errtrace Next command will fail in bash3.2 Execution continues root@atrcus365:/# echo $BASH_VERSION echo $BASH_VERSION 3.00.16(1)-release root@atrcus365:/# Output from 3.2 root@atmwsnfd:/# /tmp/test Turning off errtrace Execution continues Turning on errtrace Next command will fail in bash3.2 26 echo_ /tmp/test 42 main /tmp/test 42 main /tmp/test root@atmwsnfd:/# echo $BASH_VERSION 3.2.51(1)-release root@atmwsnfd:/# Could anyone point me in correct direction on this one ? Regards Dave
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
bash 3.2 vs 3.0
Hi all, Recently upgraded to 3.2 and noticed some differences in a lot of my scripts, consider the following example: #!/bin/bash trap error_reporter ERR set -o errexit set -o errtrace set -o nounset set -o pipefail logf_error=/dev/null function _exit { local -ri retval=${1:-$?} exit ${retval} } function error_reporter { local -ri retval=$? #echo Error in script setup. Exiting with error value ${retval}. local -i i=0 #echo Function call stack: 2 while caller $i 2; do (( i++ )); done _exit ${retval} } function echo_ { #this is called as a $(command) #a subcommand might return with 1 in the script, but in most cases it is not a problem. #At least in our scripts there are a lot of cases like this where the error is handled afterwards echo | grep b echo Execution continues } echo Turning off errtrace set +o errtrace var=$(echo_)#calling as a $(command) echo $var echo Turning on errtrace set -o errtrace echo Next command will fail in bash3.2 var=$(echo_)#calling as a $(command) echo $var Doesnt work right on 3.2 Output from 3.0 root@atrcus365:/# /tmp/test /tmp/test Turning off errtrace Execution continues Turning on errtrace Next command will fail in bash3.2 Execution continues root@atrcus365:/# echo $BASH_VERSION echo $BASH_VERSION 3.00.16(1)-release root@atrcus365:/# Output from 3.2 root@atmwsnfd:/# /tmp/test Turning off errtrace Execution continues Turning on errtrace Next command will fail in bash3.2 26 echo_ /tmp/test 42 main /tmp/test 42 main /tmp/test root@atmwsnfd:/# echo $BASH_VERSION 3.2.51(1)-release root@atmwsnfd:/# Could anyone point me in correct direction on this one ? Regards Dave
Re: bash 3.2 vs 3.0
On Thu, 5 Jan 2012, Dave wrote: Hi all, Recently upgraded to 3.2 and noticed some differences in a lot of my scripts, consider the following example: ... Could anyone point me in correct direction on this one ? Upgrade to 4.2; you are years behind the times! -- Chris F.A. Johnson, http://cfajohnson.com/ Author: Pro Bash Programming: Scripting the GNU/Linux Shell (2009, Apress) Shell Scripting Recipes: A Problem-Solution Approach (2005, Apress)
Re: bash 3.2 vs 3.0
On 1/5/12 5:12 AM, Dave wrote: Hi all, Recently upgraded to 3.2 and noticed some differences in a lot of my scripts, consider the following example: You might have a tough time getting help on this. Bash-3.2 was released over five years ago; bash-3.0 two years before that. I point people to bash-4.2, the current version, which was released over a year ago. The CHANGES file from bash-3.2 might be helpful. I found in the changes between bash-3.1 and bash-3.2: z. The inheritence of the DEBUG, RETURN, and ERR traps is now dependent only on the settings of the `functrace' and `errtrace' shell options, rather than whether or not the shell is in debugging mode. It looks like the failing pipeline triggered the ERR trap, which bash-3.2 inherits (correctly) and bash-3.[01] did not. -- ``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 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