Re: bug in force_interactive handling

2012-01-05 Thread Stas Sergeev

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

2012-01-05 Thread Chet Ramey
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

2012-01-05 Thread Peng Yu
 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

2012-01-05 Thread Chet Ramey
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

2012-01-05 Thread Dave
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

2012-01-05 Thread Peng Yu
 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

2012-01-05 Thread Dave
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

2012-01-05 Thread Chris F.A. Johnson

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

2012-01-05 Thread Chet Ramey
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

2012-01-05 Thread Clark J. Wang
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

2012-01-05 Thread Peng Yu
 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