3

I am trying to create a small tutorial-like script to refresh my bash skills.

I have defined a variable DISPLAY_TEXT that has some text and a set of escape characters and colors like so:

DISPLAY_TEXT=${WHITE}\n\t \t ==== $HEADER ====\n\n${NOCOL}"

WHITE and NOCOL defined with their appropriate ANSI escape codes.

Then, using a simple pipe with echo, I redirect the value of a variable DISPLAY_TEXT to less with echo -e $DISPLAY_TEXT | less.

The arguments I have set for less are as so: 

less --prompt=["Navigate using arrows (or touchpad). Enter 'q' to exit"] -r

With -r to output raw characters.

The program gets executed fine and the output is as expected with colors showing (until I scroll down and up again). The main odd behaviour is displayed in the next picture.

odd less

Is there something I am not understanding with basic redirection, less or bash in general? This behaviour isn't limiting my script but it is something that I'm interested in understanding.

fedorqui
  • 275,237
  • 103
  • 548
  • 598
Dimitris Fasarakis Hilliard
  • 150,925
  • 31
  • 268
  • 253
  • Can you describe what the odd behavior is? – Emacs User Sep 11 '15 at 00:56
  • The odd behaviour is as displayed in the picture. Navigating up and down after reaching the end of the file causes `less`(?) to re-print that specific line. Maybe SO isn't the right community for this question, not sure. – Dimitris Fasarakis Hilliard Sep 11 '15 at 02:33
  • Which specific line is being reprinted? I'm still not able to tell. – Emacs User Sep 11 '15 at 03:02
  • 2
    I think you need to be more precise about the command you typed to get the picture you present. Your question uses both `DISPLAY_COLOR` and `DISPLAY_TEXT`; you don't specify exactly which ANSI codes you use and "\n\t \t ==== $HEADER ====\n\n" does not correlate in any obvious way with the display (and there is apparently a missing or extra quote). So it's not easy to attempt to reproduce. Also, it would help if you mentioned what terminal emulator you are using. – rici Sep 11 '15 at 03:13
  • `DISPLAY_COLOR` was a sleep induced typo. `DISPLAY_TEXT` is the variable I am using to display my text. The `tty` I am using is `/dev/pts/6`. The ANSI codes are not to blame since I removed them and that behaviour persisted. For completeness their codes were in the form `WHITE='\033[1;37m'` – Dimitris Fasarakis Hilliard Sep 11 '15 at 03:20
  • How is this a software development question, as opposed to an end-user technical support question? – Charles Duffy Sep 11 '15 at 03:20
  • 1
    Aside: `echo -e $FOO` is evil (BashPitfalls #14, http://mywiki.wooledge.org/BashPitfalls). Use `echo -e "$FOO"`, or -- much better, for reasons given in APPLICATION USAGE and RATIONALE sections of http://pubs.opengroup.org/onlinepubs/009604599/utilities/echo.html -- `printf '%b\n' "$FOO"`. – Charles Duffy Sep 11 '15 at 03:21
  • I have no idea if it something I have caused with the commands I executed or if it is due to the `less` utility. Like I previously stated I am not precisely sure if S.O is the right place. – Dimitris Fasarakis Hilliard Sep 11 '15 at 03:23
  • Also consider using lower-case variable names. See fourth paragraph of http://pubs.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap08.html, keeping in mind that shell variables and environment variables share a namespace. – Charles Duffy Sep 11 '15 at 03:23
  • Gotcha. No, there's nothing about basic redirection you're failing to understand; this is an unexpected and undesired interaction between `less` and your terminal. – Charles Duffy Sep 11 '15 at 03:24

1 Answers1

3

less -r tells less to pass codes through to the terminal rather than filtering them.

This doesn't mean that it understands what those codes do. Not understanding them, then, means that it's no longer accurately able to detect cursor position, and can inaccurately estimate when and where line wrap occurs; hence, unexpected and undesired behavior on scrolling.

Charles Duffy
  • 280,126
  • 43
  • 390
  • 441