bug#10620: Improper handling of newline characters

[Bob Proulx]

tags 10620 + notabug moreinfo
thanks

Philippe Grégoire wrote:
> If I type the command '/usr/bin/printf "hi\b"', the result is as
> expected -- "h" without a newline character.

Actually it is "hi\b".  It isn't "h".

  $ printf "hi\b\n" | od -tx1 -c
  0000000 68 69 08 0a
          h   i  \b  \n

I don't know why you would think it would be "h" only.  That would be
incorrect.

> However, if I type '/usr/bin/printf "hi\b\n"', the result is "hi"
> followed by a newline.

Right.  That is what you are specifying.

  $ printf "hi\b\n" | od -tx1 -c
  0000000 68 69 08 0a
          h   i  \b  \n

> The newline character seems to force a buffer flush without respecting
> what precedes it.

Huh?  The buffer is going to be flushed regardless when the printf
program exits.  If it wasn't flushed then the output would be lost.
And the program will be exiting at that point regardless.

> The behavior is the same no matter what precedes the backspace
> character and the number of backspace characters -- try "a\b\b\n".

Right.  That is the way it is supposed to work.

  $ printf "a\b\b\n" | od -tx1 -c
  0000000 61 08 08 0a
          a  \b  \b  \n

All as expected.  Right?

> Now testing the same strings using the C version of printf (libc6
> 2.11.2), I get the same result.

Unsurprising, no?  The command line printf is intentionally not much
removed from the behavior of the library routine.

> As such, I am wondering if it is the result of a bug in the terminal
> driver;

What would be the bug?  Please explain what you are expecting to see.

> sorry to bother, I discovered it using. I tested with bash,
> dash, konsole, xterm and a linux console with the same results.

So if all of those different programs all do the same thing then it
would seem that the likelihood of it being a bug is very small.
Because surely somewhere along the way someone would have noticed a
bug if it were there and reported it.  Since they all behave the same
it is very unlikely that it is actually a bug.

> By the way, I get the same behavior using "/bin/echo -e" with and
> without the -n flag".

Right.  But 'echo' is not portable if options, arguments that might be
confused with options, or any control character sequence is included.
Use of echo is only good for plain and simple strings and nothing more.

I don't see any bug anywhere here.  You have only stated that it is
behaving as itis supposed to behave.  Please say what bug you think
exists.

Bob