Re: poor <&- behavior under ulimit -n

2010-11-05 Thread Chet Ramey
On 10/27/10 6:25 PM, Eric Blake wrote:

> Description:
> Bash does not behave well when under artificial fd pressure due to
> ulimit -n.  It issues a spurious warning to stderr because it tries
> to save necessary fds starting at 10.  Compare this with ksh93, which
> saves fds starting at 3.
> 
> Many other shells (for example, dash or BSD /bin/sh) exit with
> non-zero status if they can't use fd 10, rather than proceeding onwards.
> At any rate, bash MUST exit with failure if it cannot save an fd, even
> if you decide that it is unsafe to copy ksh93's action of saving at fd
> 3 rather than 10.  

That's not actually true.  What bash must do is to throw a redirection
error, which has specific Posix-defined consequences in a non-interactive
shell, which differ between special builtins and other utilities.

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: Trouble with PS1 special characters between \[ and \]

2010-11-05 Thread Chet Ramey
On 10/30/10 5:13 PM, Lluís Batlle i Rossell wrote:
> Hello,
> 
> I don't think this problem is related to any recent bash version only. I've 
> seen
> this since years I think.
> 
> Nevertheless I'm using GNU bash, version 4.0.17(1)-release
> (x86_64-unknown-linux-gnu) now.
> 
> My PS1 uses the "Change window title" sequence, to set the xterm window title 
> to
> something close to the prompt text. Hence my PS1 is:
> 
> PS1='\[\033]2;\h:\u:\w\007\]\n\[\033[1;31m\]...@\h:\w]\$\[\033[0m\] '

I can't reproduce this using bash-4.1 on Mac OS X using Terminal or
xterm.  Please try bash-4.1 and let me know if that works.

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: Trouble with PS1 special characters between \[ and \]

2010-11-05 Thread Bob Proulx
Lluís Batlle i Rossell wrote:
> I don't think this problem is related to any recent bash version
> only. I've seen this since years I think.
> 
> Nevertheless I'm using GNU bash, version 4.0.17(1)-release
> (x86_64-unknown-linux-gnu) now.

I am using 4.1.5(1)-release and I could not recreate your problem.

> My PS1 uses the "Change window title" sequence, to set the xterm
> window title to something close to the prompt text. Hence my PS1 is:
> 
> PS1='\[\033]2;\h:\u:\w\007\]\n\[\033[1;31m\]...@\h:\w]\$\[\033[0m\] '

This is something that you may have better luck if you put the window
title setting sequences into PROMPT_COMMAND instead.  Then you would
not need to use the \[...\] around the non-visible parts of PS1 since
they won't be there at all.  That would leave just your color changes
needing them.  This may be enough to avoid the problem you are having
regardless of its source.

The PROMPT_COMMAND won't expand the PS1 \u \h \w sequences though and
you would want to use the full variable names for them.  I have had
the following in my .bashrc for a long time.

  case $TERM in
xterm*)
  PROMPT_COMMAND='echo -ne "\033]0;${us...@${hostname}:${PWD/$HOME/~}\007"'
  ;;
  esac

Then add something like this for your adjusted PS1 prompt.

  PS1='\n\[\033[1;31m\]...@\h:\w]\$\[\033[0m\] '

That leading \n gives me pause though...

Bob