smallnow small...@gmail.com writes:
Bug #1:
do:
PROMPT_COMMAND='$(cd)'
Since $(cd) expands to nothing this is mostly a no-op.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
On Sun, Mar 01, 2009 at 10:29:00PM -0800, smallnow wrote:
Bug #1:
do:
PROMPT_COMMAND='$(cd)'
I've never found any reasonable use for PROMPT_COMMAND. If you just
want to perform command substitutions at prompt-writing time, use PS1:
PS1='$(pwd)\$ '
Of course, this trivial example is more
Chris F.A. Johnson wrote:
In bash4.0, the terminal is not reset if this is times out:
read -st1
Thanks for the report. The cleanup functions were not called on timeout.
The attached patch fixes things for me.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
Chet Ramey,
Ray Parrish wrote:
And as another note, even 'though I've used the -d switch to show only
directories in the output I'm still getting filenames with it.
Please see the Coreutils FAQ on 'ls -d'.
http://www.gnu.org/software/coreutils/faq/#ls-_002dd-does-not-list-directories_0021
I had to
Andreas Schwab wrote:
smallnow writes:
PROMPT_COMMAND='$(cd)'
Since $(cd) expands to nothing this is mostly a no-op.
True. But he did say this as well:
I used $(cd) as a trivial command substitution, but any command
substitution seems to have the same effect.
I actually had some
This completion function worked in previous versions, but fails in
bash4.0 when I press TAB:
_cpsh() {
COMPREPLY=( `
cd $HOME/scripts || return 3
printf %s\n ${COMP_WORDS[$COMP_CWORD]}*-sh`
)
COMPREPLY=( ${comprep...@]%-sh} )
}
complete -F _cpsh cpsh
Chris F.A. Johnson-3 wrote:
This completion function worked in previous versions, but fails in
bash4.0 when I press TAB:
_cpsh() {
COMPREPLY=( `
cd $HOME/scripts || return 3
printf %s\n ${COMP_WORDS[$COMP_CWORD]}*-sh`
)
COMPREPLY=(
On Mon, 2 Mar 2009, Richard Leeden wrote:
...
Have you applied the tab completion patch that Chet provided here:
http://lists.gnu.org/archive/html/bug-bash/2009-02/msg00153.html
http://lists.gnu.org/archive/html/bug-bash/2009-02/msg00153.html
I missed that. Thanks... that fixed it.
--
Hi,
I have some questions about the paragraph in Bash Reference on redirections:
Note that the order of redirections is significant. For example, the
command
ls dirlist 21
directs both standard output (file descriptor 1) and standard error (file
descriptor 2) to the
file dirlist, while the
lehe wrote:
I have some questions about the paragraph in Bash Reference on redirections:
Note that the order of redirections is significant. For example, the
...
ls dirlist 21
directs both standard output (file descriptor 1) and standard error (file
descriptor 2) to the
file dirlist,
On Monday 2 March 2009 23:34, lehe wrote:
Hi,
I have some questions about the paragraph in Bash Reference on
redirections: Note that the order of redirections is significant. For
example, the command
ls dirlist 21
directs both standard output (file descriptor 1) and standard error
code that uses case statements in a subshell and then uses comments causes
bash to trigger a parsing error:
$ cat test.sh
echo $(case a in (a) echo ok ;; # comment
)
$ sh ./test.sh
./test.sh: line 1: unexpected EOF while looking for matching `)'
./test.sh: line 3: syntax error: unexpected end of
12 matches
Mail list logo
