Re: when last output lacks \n, bash gets confused about cursor position

> When using 'echo -n' or printf without a final \n, and then using > the Up and Down keys to walk through previous commands, bash can > get confused about its cursor position (or rather its prompt > position) and either leave some stray text in the middle of the > line, or overwrite part of it

Re: builtin printf ignores straight '\c'

> Bash's printf appears to ignore the \c backslash escape: This is, as you noted, as Posix specifies. > When \c is provided via the %b conversion specifier, it is > interpreted: Again, this is as posix specifies. I'm not inclined to change the current behavior. Chet -- ``The lyf so short, t

when last output lacks \n, bash gets confused about cursor position

Hi, When using 'echo -n' or printf without a final \n, and then using the Up and Down keys to walk through previous commands, bash can get confused about its cursor position (or rather its prompt position) and either leave some stray text in the middle of the line, or overwrite part of its pr

builtin printf ignores straight '\c'

Hi, Bash's printf appears to ignore the \c backslash escape: $ printf "before \c after \a" before \c after $ $ type printf printf is a shell builtin Of course the Open Group's description of printf (http://www.opengroup.org/onlinepubs/95399/utilities/printf.html) does not specify that \c i

[patch] a better description of \c

Hi, The help text for echo describes the effect of the backslash escape \c like this: $ help echo | grep '\\c' \c suppress trailing newline But what it actually does is different: $ echo -e "before \c after \a" before $ It cancels all characters that come after it. The printf c