OT: Funny tab behaviour on terminals

[Andy Parkins <andyparkins@gmail.com>]

On Tuesday 2007 February 27 20:32, Junio C Hamano wrote:

>  * refs.c::log_ref_write() gets an optional log message and
>    writes it after the GMT offset, with an explicit "\t", so
>    this is not it, either.

Your mention of tabs set off alarm bells in my head.  I had another look at 
the files with "less -S" instead of tail and lo-and-behold, the tab is shown.

Panic over.  This isn't a fault with git.  Stop reading now if you're only 
interested in git.

It's some weird interaction with tabs and my terminal and those particular 
line lengths.  The two repositories I was comparing logs in have different 
email addresses for me, so the column at which the tab activates is 
different.  Bizarrely, in one case the tab appears swallowed, in the other it 
appeared correctly.

-- time passes ---

It seems like a fault in terminals in general to me (perhaps it's specified in 
a standard somewhere, so everyone just implements it):  if a tab is output in 
the last column of the terminal, it's just swallowed - no space at all is 
shown.

It's easily repeatable.
 * Open an xterm
 * Resize it so that it's 50 columns wide.
 * echo -e "0xxxxxxxxx1xxxxxxxxx2xxxxxxxxx3xxxxxxxxx4xxxxxxxx\t5xxxxxxxxx"
 * Notice that the "5" is not on the next line where one might expect, but is
   in column 49

Am I wrong to think this is wrong?  I've always thought that there was an 
implicit tab just off the end of a terminal line, which effectively brings 
the output to the next tab stop (i.e. column 0 of the next line).


Andy

-- 
Dr Andy Parkins, M Eng (hons), MIET
andyparkins@gmail.com