Skip to content

cat with backspace and newline characters

15 messages · Kenn Konstabel, Brian Ripley, Brian G. Peterson +7 more

#
It is user lack-of-understanding: there is no error here.  R outputs

a
b
c
backspace
newline

How the terminal displays that is up to the terminal, which was 
unstated.  (Capture the output and look at it in a hex editor.)

For

a
b
c
backspace

a normal terminal will output the prompt and overwrite 'c'.
On 05/11/2013 10:53, Renaud Gaujoux wrote:

  
    
#
> I just tried it on ubuntu but within RStudio:
    >> cat("abc\b")
    > ab
    >> cat("abc\b\n")
    > ab
    >> sessionInfo()

which --- as you allude to below --- shows that  RStudio  has changed R
in so far that it adds a '\n'  even when R, i.e.  cat()  does not.

I can understand that the RStudio programmers want to protect
their users (*) from getting funny looking output,
but I still don't like the fact that R inside RStudio is tweaked
to behave differently from regular R. 

Martin Maechler, R Core Team & ETH Zurich

--
(*) or their software from malfunctioning when the console "looks ugly"

    > R version 3.0.2 (2013-09-25) Platform: x86_64-pc-linux-gnu
    > (64-bit)

    > locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=C
    > LC_COLLATE=C [5] LC_MONETARY=C LC_MESSAGES=C LC_PAPER=C
    > LC_NAME=C [9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=C
    > LC_IDENTIFICATION=C

    > --------

    > On the same machine but running R in the terminal (tried
    > with GNOME terminal, Konsole, and xterm with no difference
    > )

    >> cat("abc\b")
    ab> cat("abc\b\n")
    > abc
    >> sessionInfo()
    > R version 3.0.2 (2013-09-25) Platform: x86_64-pc-linux-gnu
    > (64-bit)

    > locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=C
    > [4] LC_COLLATE=C LC_MONETARY=C LC_MESSAGES=C [7]
    > LC_PAPER=C LC_NAME=C LC_ADDRESS=C [10] LC_TELEPHONE=C
    > LC_MEASUREMENT=C LC_IDENTIFICATION=C

    > ---------


    > But then again ...

    > cat("abc\b \n")

    > ... seems to work the same way everywhere. It looks like
    > the logic in a unix terminal is that \b moves the cursor
    > backwards but does not replace or delete anything that was
    > there before.

    > Regards, Kenn





    > On Tue, Nov 5, 2013 at 12:53 PM, Renaud Gaujoux <
> renaud at mancala.cbio.uct.ac.za> wrote:
>> Maybe it's a Linux problem:
    >> 
    >> > cat("abc\b")
    ab> cat("abc\b\n")
    >> abc > sessionInfo() R version 3.0.2 (2013-09-25)
    >> Platform: x86_64-pc-linux-gnu (64-bit)
    >> 
    >> locale: [1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C [3]
    >> LC_TIME=en_US.UTF-8 LC_COLLATE=en_US.UTF-8 [5]
    >> LC_MONETARY=en_US.UTF-8 LC_MESSAGES=en_US.UTF-8 [7]
    >> LC_PAPER=en_US.UTF-8 LC_NAME=C [9] LC_ADDRESS=C
    >> LC_TELEPHONE=C [11] LC_MEASUREMENT=en_US.UTF-8
    >> LC_IDENTIFICATION=C
    >> 
    >> attached base packages: [1] stats graphics grDevices
    >> utils datasets methods base
    >> >
    >> > Sys.info() sysname "Linux" release "3.11.0-12-generic"
    >> version "#19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013"
    >> nodename "XXXXX" machine "x86_64" login "XXXXX" user
    >> "XXXXX" effective_user "XXXXX"
    >> >
    >> 
    >> 
    >> 
    >> 
    >> On 1 November 2013 19:54, Dennis Murphy
>> <djmuser at gmail.com> wrote:
>> 
    >> > I can't reproduce the error, either:
    >> >
    >> > > cat("abc\b") > ab> cat("abc\b\n") > ab
    >> > >
    >> > > sessionInfo() > R version 3.0.2 (2013-09-25) >
    >> Platform: x86_64-w64-mingw32/x64 (64-bit)
    >> >
    >> > locale: > [1] LC_COLLATE=English_United States.1252 >
    >> [2] LC_CTYPE=English_United States.1252 > [3]
    >> LC_MONETARY=English_United States.1252 > [4] LC_NUMERIC=C
    >> > [5] LC_TIME=English_United States.1252
    >> >
    >> > <package info snipped for brevity>
    >> >
    >> > Dennis
    >> >
    >> 
    >> [[alternative HTML version deleted]]
    >> 
    >> ______________________________________________
    >> R-devel at r-project.org mailing list
    >> https://stat.ethz.ch/mailman/listinfo/r-devel
    >> 

    > 	[[alternative HTML version deleted]]

    > ______________________________________________
    > R-devel at r-project.org mailing list
    > https://stat.ethz.ch/mailman/listinfo/r-devel
#
On 11/05/2013 07:22 AM, Martin Maechler wrote:
No, it just suggests exactly what Prof. Ripley alluded to...

... the output of cat() will be dependent on the display terminal.

RStudio doesn't include R at all, and in fact makes use of the/any R 
binary installed via other processes.  It is not 'tweaked'.

It *does* include a 'terminal' to display the interactions with the R 
console.

Regards,

Brian
#

        
> On 11/05/2013 07:22 AM, Martin Maechler wrote:
>> which --- as you allude to below --- shows that RStudio
    >> has changed R in so far that it adds a '\n' even when R,
    >> i.e.  cat() does not.
    >> 
    >> I can understand that the RStudio programmers want to
    >> protect their users (*) from getting funny looking
    >> output, but I still don't like the fact that R inside
    >> RStudio is tweaked to behave differently from regular R.

    > No, it just suggests exactly what Prof. Ripley alluded
    > to...

    > ... the output of cat() will be dependent on the display
    > terminal.

    > RStudio doesn't include R at all, and in fact makes use of
    > the/any R binary installed via other processes.  It is not
    > 'tweaked'.

    > It *does* include a 'terminal' to display the interactions
    > with the R console.

Well I know that (it does not modify R),
but I'd say that the above is just another way to say what I said:
RStudio tweaks R's output. I agree that this is much much less
problematic than changing R objects, but I'd claim that
where as the interpretation of  \b  depends on the
terminal/console (and so it is quite rarely used),
the functioning of  \n  should not depend on the platform.
RStudio users may conclude that it is a good idea to use things like
	cat("pi:", pi)
whereas they really should use something like
	cat("pi:", pi, "\n)

Martin

    > Regards,
    > Brian
#
On 05 Nov 2013, at 14:22, Martin Maechler <maechler at stat.math.ethz.ch> wrote:

            
[?]

I agree with you Martin, but what is a "regular R"? Because on a Mac, R.app does exactly the same as RStudio:
ab
ab
R version 3.0.2 (2013-09-25)
Platform: x86_64-apple-darwin10.8.0 (64-bit)

locale:
[1] en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

And this is R.app 1.62 Snow Leopard build (6558).

So, does it means that R run under R.app on Mac OS X is *not* considered as a regular R?
Best,

Philippe
#
PhGr> On 05 Nov 2013, at 14:22, Martin Maechler
PhGr> <maechler at stat.math.ethz.ch> wrote:
>>>>>>> Kenn Konstabel <lebatsnok at gmail.com> on Tue, 5 Nov
    >>>>>>> 2013 13:25:20 +0200 writes:
    >> 
    >>> I just tried it on ubuntu but within RStudio:
    >>>> cat("abc\b")
    >>> ab
    >>>> cat("abc\b\n")
    >>> ab
    >>>> sessionInfo()
    >> 
    >> which --- as you allude to below --- shows that RStudio
    >> has changed R in so far that it adds a '\n' even when R,
    >> i.e.  cat() does not.
    >> 
    >> I can understand that the RStudio programmers want to
    >> protect their users (*) from getting funny looking
    >> output, but I still don't like the fact that R inside
    >> RStudio is tweaked to behave differently from regular R.
    >> 
    >> Martin Maechler, R Core Team & ETH Zurich
    >> 
    >> --
    >> (*) or their software from malfunctioning when the
    >> console "looks ugly"

    PhGr> [?]

    PhGr> I agree with you Martin, but what is a "regular R"?
    PhGr> Because on a Mac, R.app does exactly the same as
    PhGr> RStudio:

    >> cat("abc\b")
    PhGr> ab
    >> cat("abc\b\n")
    PhGr> ab
    >> sessionInfo()
    PhGr> R version 3.0.2 (2013-09-25) Platform:
    PhGr> x86_64-apple-darwin10.8.0 (64-bit)

    PhGr> locale: [1]
    PhGr> en_US.UTF-8/en_US.UTF-8/en_US.UTF-8/C/en_US.UTF-8/en_US.UTF-8

    PhGr> attached base packages: [1] stats graphics grDevices
    PhGr> utils datasets methods base

    PhGr> And this is R.app 1.62 Snow Leopard build (6558).

    PhGr> So, does it means that R run under R.app on Mac OS X
    PhGr> is *not* considered as a regular R?  

good question....  I would have said so, but maybe we should
wait for my R core colleagues for a bit.... ;-)

Martin


    PhGr> Best, Philippe
#
On 05 Nov 2013, at 17:53 , Martin Maechler <maechler at stat.math.ethz.ch> wrote:

            
As far as I can tell, neither actually changes the output of cat(), witness
abab
So in a sense, it is the prompt that is tweaked to ?jump to beginning of next line, unless already at beginning of line?. I don?t recall any ?real? terminal having an escape sequence for that, but I wouldn?t put it past ESS to do something similar. 

I see your point about cat(?pi?, pi), but I would expect that the bad habit would get cured first time it was attempted to print something between it and the next prompt. I?m actually more worried/puzzled that ?\r? behaves strangely (in Rstudio, not R.app):
456
123456

People do sometimes use this pattern for displaying progress (e.g. iteration counts).

  
    
#
Yes, that indeed sounds like a problem, but example(txtProgressBar),
which is based on \r, works well in the RStudio console. Anyway,
thanks for all the experiments, and (to Renaud) support.rstudio.org is
the place to report such problems.

Regards,
Yihui
--
Yihui Xie <xieyihui at gmail.com>
Web: http://yihui.name
Department of Statistics, Iowa State University
2215 Snedecor Hall, Ames, IA
On Tue, Nov 5, 2013 at 4:57 PM, peter dalgaard <pdalgd at gmail.com> wrote:
#
On Nov 6, 2013, at 3:47 AM, Renaud Gaujoux <renaud at mancala.cbio.uct.ac.za> wrote:

            
That is not strange at all - just try adding something like Sys.sleep(2) to understand it - it?s exactly what you should expect in a typical terminal (but see below) and it?s happens with any program (try perl -e 'print STDERR "abc\b\b\b"; sleep 1;? for example).
I don?t think that there is any guaranteed behavior for anything other than ?\n?. All cat() guarantees is that this character sequence will be passed out to the console, there is no guarantee as to what effect it will actually have - that is entirely up to the front-end.

Thus your implicit assumption is that ?\b? is interpreted in some way, but it?s not - it?s simply passed on. When running on a terminal, it is interpreted by the terminal, and the standard interpretation is to move the cursor to the left by one character. If running R through any other means like a GUI, it?s entirely up to the GUI to decide whether to interpret non-ASCI characters in some way - or not.

Cheers,
Simon
#
I agree that the handling of \b is not that strange, once one agrees
on what \b actually means, i.e. "go back one character" and not
"delete previous character".
The fact that R GUI on Mac and Windows interprets/renders it
differently shows that normality and strangeness is quite relative
though.

To make my previous response clearer, I was just wondering if the
printing of R prompt character ">" after the evaluation of an
expression could detect trailing \b from cat in stdout/stderr and
shift its position so that it is displayed after the last printed
character. For example cat("abc\b\b\b") would give

abc>
and not
a> c

But this is:
0) Again platform, front-end dependent;
1) maybe not be possible (e.g., can we actually move forward without
printing a character that would erase the previous output?)
2) maybe not even desirable;
3) certainly not worth the effort anyway!

I guess we can happily close this thread :D
Many thanks.

Bests,
Renaud
#
On 07/11/2013, at 09:35 AM, Renaud Gaujoux wrote:

            
As a user DEC LA120 terminal I expect the following:
?
Everything else feels like a bug.

Cheers, Jari Oksanen