0

I need help in the conceptual area surrounding:

  • /usr/bin/screen,
  • ~/.screenrc,
  • termcap

My Goal: is to create a 'correctly' formatted log file via 'screen'.

Symptom: The log file contains hundreds of carriage-return bytes [i.e. (\015) or (\r) ]. I would like to replace every carriage-return byte with a linefeed byte [i.e. (\012) or (\n)].

My Approach: I have created the file: ~/.screenrc and added a 'termcap' line to it with the hope of intercepting the inbound bytes and translating the carriage-return bytes into linefeed bytes BEFORE they are written to the log file. I cycled through nine different syntactical forms of my request. None had the desired effect (see below for all nine forms).

My Questions:

  • Can my goal be accomplished with my approach?
  • If yes, what changes do I need to make to achieve my goal?
  • If no, what alternative should I implement?
  • Do I need to mix in the 'stty' command?
  • If yes, how?

Note: I can create a 'correctly' formatted file using the log file as input to 'tr':

   $  /usr/bin/tr  '\015'  '\012'  <screenlog.0  | head
   <5 BAUD ADDRESS: FF>  
   <WAITING FOR 5 BAUD INIT>  
   <5 BAUD ADDRESS: 33>  
   <5 BAUD INIT: OK>  
   Rx: C233F1 01 00                    @ 254742 ms  
   Tx: 86F110 41 00 BE 1B 30 13        @ 254753 ms  
   Tx: 86F118 41 00 88 18 00 10        @ 254792 ms  
   Tx: 86F128 41 00 80 08 00 10        @ 254831 ms  
   Rx: C133F0 3E                       @ 255897 ms  
   Tx: 81F010 7E                       @ 255903 ms  
   $  

The 'screen' log file ( ~/screenlog.0 ) is created using the following command:

$ screen -L /dev/tty.usbserial-000014FA  115200

where:

$ ls -dl /dev/*usb*
crw-rw-rw-  1 root  wheel   17,  25 Jul 21 19:50 /dev/cu.usbserial-000014FA  
crw-rw-rw-  1 root  wheel   17,  24 Jul 21 19:50 /dev/tty.usbserial-000014FA  
$  
$  
$ ls -dl ~/.screenrc
-rw-r--r--  1 scottsmith  staff  684 Jul 22 12:28 /Users/scottsmith/.screenrc 

$ cat ~/.screenrc

 #termcap         xterm*          'XC=B%,\015\012'          #  01  no effect  
 #termcap         xterm*          'XC=B%\E(B,\015\012'      #  02  no effect  
 #termcap         xterm*          'XC=B\E(%\E(B,\015\012'   #  03  no effect  
 #terminfo        xterm*          'XC=B%,\015\012'          #  04  no effect  
 #terminfo        xterm*          'XC=B%\E(B,\015\012'      #  05  no effect  
 #terminfo        xterm*          'XC=B\E(%\E(B,\015\012'   #  06  no effect  
 #termcapinfo     xterm*          'XC=B%,\015\012'          #  07  no effect  
 #termcapinfo     xterm*          'XC=B%\E(B,\015\012'      #  08  no effect  
  termcapinfo     xterm*          'XC=B\E(%\E(B,\015\012'   #  09  no effect  
$  
$ echo $TERM  

xterm-256color  

$ echo $SCREENRC  

$ ls -dl /usr/lib/terminfo/?/*  
ls: /usr/lib/terminfo/?/*: No such file or directory  
$ ls -dl /usr/lib/terminfo/*  
ls: /usr/lib/terminfo/*: No such file or directory  
$ ls -dl /etc/termcap  
ls: /etc/termcap: No such file or directory  
$ ls -dl /usr/local/etc/screenrc  
ls: /usr/local/etc/screenrc: No such file or directory  
$  

System:

  • MacBook Pro (17-inch, Mid 2010)
  • Processor 2.53 GHz Intel Core i5
  • Memory 8 GB 1067 MHz DDR3
  • Graphics NVIDIA GeForce GT 330M 512 MB
  • OS X Yosemite Version 10.10.4

Screen(1) Mac OS X Manual Page: ( possible relevant content ):

CHARACTER TRANSLATION

Screen has a powerful mechanism to translate characters to arbitrary strings depending on the current font and terminal type. Use this feature if you want to work with a common standard character set (say ISO8851-latin1) even on terminals that scatter the more unusual characters over several national language font pages.

Syntax: XC=<charset-mapping>{,,<charset-mapping>}  

<charset-mapping> := <designator><template>{,<mapping>}  

<mapping>         := <char-to-be-mapped><template-arg> 

The things in braces may be repeated any number of times. A tells screen how to map characters in font ('B': Ascii, 'A': UK, 'K': german, etc.) to strings. Every describes to what string a single character will be translated. A template mechanism is used, as most of the time the codes have a lot in common (for example strings to switch to and from another charset). Each occurrence of '%' in gets substituted with the specified together with the character. If your strings are not similar at all, then use '%' as a template and place the full string in . A quoting mechanism was added to make it possible to use a real '%'. The '\' character quotes the special char- acters '\', '%', and ','. Here is an example: termcap hp700 'XC=B\E(K%\E(B,\304[,\326\\,\334]' This tells screen how to translate ISOlatin1 (charset 'B') upper case umlaut characters on a hp700 terminal that has a german charset. '\304' gets translated to '\E(K[\E(B' and so on. Note that this line gets parsed three times before the internal lookup table is built, therefore a lot of quoting is needed to create a single '\'. Another extension was added to allow more emulation: If a mapping translates the unquoted '%' char, it will be sent to the terminal whenever screen switches to the corresponding . In this special case the template is assumed to be just '%' because the charset switch sequence and the char- acter mappings normally haven't much in common. This example shows one use of the extension: termcap xterm 'XC=K%,%\E(B,[\304,\\\326,]\334' Here, a part of the german ('K') charset is emulated on an xterm. If screen has to change to the 'K' charset, '\E(B' will be sent to the terminal, i.e. the ASCII charset is used instead. The template is just '%', so the mapping is straightforward: '[' to '\304', '\' to '\326', and ']' to '\334'.

1 Answers1

0

The section on character translation is describing a feature which is unrelated to logging. It is telling screen how to use ISO-2022 control sequences to print special characters on the terminal. In the manual page's example

termcap xterm 'XC=K%,%\E(B,[\304,\\\\\326,]\334'

this tells screen to send escape(B (to pretend it is switching the terminal to character-set "K") when it has to print any of [, \ or ]. Offhand (referring to XTerm Control Sequences) the reasoning in the example seems obscure:

  • xterm handles character set "K" (German)
  • character set "B" is US-ASCII
  • assuming that character set "B" is actually rendered as ISO-8859-1, those three characters are Ä, Ö and Ü (which is a plausible use of German, to print some common umlauts).

Rather than being handled by this feature, screen's logging is expected to record the original characters sent to the terminal — before translation.

Thomas Dickey
  • 51,086
  • 7
  • 70
  • 105