On 2010-08-24 15:59 , Chet Ramey wrote:
> Well, if they cause bash to crash, I suppose removing that code (or
> removing the #define) is a good place to start.
>
> That code has been there for a very long time. Maybe if you changed it
> to turn on the FD_CLOEXEC bit instead of closing the fd we c
PROMPT_COMMAND doesn't create a subshell.
xyz () { ((num++)); date; echo -n "num: $num"; }
PROMPT_COMMAND='xyz'
PS1=' '
On Wed, Aug 25, 2010 at 11:20 AM, E R wrote:
> I've been trying to get a function called from PS1 to set a variable, e.g.:
>
> num=1
>
> function xyz {
> ((num++))
> date; ec
On Wed, Aug 25, 2010 at 11:20:28AM -0500, E R wrote:
> I've been trying to get a function called from PS1 to set a variable, e.g.:
>
> num=1
>
> function xyz {
> ((num++))
> date; echo "num: $num"
> }
>
> PS1="\$(xyz): "
The problem here is that the command substitution (the $(...) bit)
creat
I've been trying to get a function called from PS1 to set a variable, e.g.:
num=1
function xyz {
((num++))
date; echo "num: $num"
}
PS1="\$(xyz): "
In this example, the global value of num doesn't change if it is
called from PS1. However num does get incremented if xyz is called
directly.
Is
On 8/25/10 1:39 AM, Jan Schampera wrote:
> Okay, I think I found something
>
> [POSIX excerpts]
> - When a function is executed, it shall have the syntax-error and
> variable-assignment properties described for special built-in utilities in
> the enumerated list at the beginning of Special Built-
