2 regressions related to PROMPT_COMMAND
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu' -DCONF_VENDOR='unknown' -DLOCALEDIR='/a/local/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -g -O2 uname output: Linux ul 2.6.27-12-generic #1 SMP Thu Feb 5 09:26:42 UTC 2009 x86_64 GNU/Linux Machine Type: x86_64-unknown-linux-gnu Bash Version: 4.0 Patch Level: 0 Release Status: release Description: Neither of these happen on the same system with 3.2.39(1)-release. Bug #1: do: PROMPT_COMMAND='$(cd)' Then do anything that would change your prompt, for example change directories when PS1 contains the current directory. You will see the prompt will never update when PROMPT_COMMAND contains any command substitution. It just remains whatever it was when this was set. I used $(cd) as a trivial command substitution, but any command substitution seems to have the same effect. I actually had some useful code including parameter expansions going on in my PROMPT_COMMAND. This took quite a while to figure out. Bug #2: do: PS1= PROMPT_COMMAND='echo -ne $PWD' press up, then down. This brings up the last history and then goes to the new command again. The cursor goes goes to the beginning of the line screwing up text from PROMPT_COMMAND. This also happens with vi-mode commands. I put PS1= so that it doesn't confuse the issue, but that is not necessary. Btw, thanks for bash 4. :) - Ian Kelling
Re: Creating directories with sticky bit set
Angel Tsankov wrote: Greg Wooledge wrote: Let's say that removing '-p' is straightforward, but what about setting the sticky bit to every newly created directory component? mkdir also has the -m argument, so you could do mkdir -m 1755 dir interestingly -m does not apply to parent directories created with -p If you wanted to deal with the -p, I would remove it and not pass it to mkdir, but create them yourself in the function. I'd use parameter expansion to deal with parts of the path 1 by 1. - Ian Kelling
fc command substitution behavior, possible bug
$ echo $BASH_VERSION 3.2.48(1)-release $ echo $(fc -nl -1) echo $BASH_VERSION $ echo $BASH_VERSION 4.0.10(2)-release $ echo $(fc -nl -1) echo $(fc -nl -1) I see there were a lot of changes to fc, is this intended or a bug? It seems there is another way to get the last history entry that works the same in command substitution regardless of 3.2 vs 4.0: $(history -p '!!') - Ian Kelling
Re: dir*/** behavior
m...@ice.filescope.com wrote: Configuration Information [Automatically generated, do not change]: Machine: i686 OS: linux-gnu Compiler: i686-pc-linux-gnu-gcc Compilation CFLAGS: -DPROGRAM='bash' -DCONF_HOSTTYPE='i686' -DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='i686-pc-linux-gnu' -DCONF_VENDOR='pc' -DLOCALEDIR='/usr/share/locale' -DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H -I. -I. -I./include -I./lib -DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin' -DSTANDARD_UTILS_PATH='/bin:/usr/bin:/sbin:/usr/sbin' -DSYS_BASHRC='/etc/bash/bashrc' -DSYS_BASH_LOGOUT='/etc/bash/bash_logout' -DNON_INTERACTIVE_LOGIN_SHELLS -DSSH_SOURCE_BASHRC -march=pentium4 -O2 -pipe uname output: Linux ice.filescope.com 2.6.25.10 #5 PREEMPT Thu Nov 27 16:10:07 EST 2008 i686 Intel(R) Pentium(R) 4 CPU 1400MHz GenuineIntel GNU/Linux Machine Type: i686-pc-linux-gnu Bash Version: 4.0 Patch Level: 10 Release Status: release Description: (Note: I am in the root directory of the bash source code) [~/desktop/bash-4.0]$ ls -adl exampl*/** ls: cannot access examples/examples: No such file or directory ls: cannot access examples/examples/complete: No such file or directory ls: cannot access examples/examples/complete/bashcc-1.0.1.tar.gz: No such file or directory ls: cannot access examples/examples/complete/bash_completion: No such file or directory [...] The above-mentioned "ls -adl exampl*/**" command should work the same as "ls -adl examples/**"; however, as shown above, the behavior of the former command is wrong. The commands work properly in both KornShell and Z shell. --Matt Zyzik I get the same thing. Looks like a bug to me. - Ian Kelling
