Screen Dump

The other week J.K. at SFVlug was asking if I could provide some notes on the GNU 'screen' program. Here, extracted from some earlier notes, and beefed up with a few references I use, without further commentary, are the basic commands, hotkeys, and other data I need for most of my 'screen' use.

some screen notes:

Note: keep in mind screen can be run inside of xterm and other environments

to kill a range of screens:

for i in {3..13} ; do screen -p $i -X kill ; done

screen -h / --help     (of course)
there are or can be /etc/screenrc ~/.screenrc files
screen -ls    list screen sessions
screen -r    ####.tty##.        attach to detached screen
screen  -r -DD   violently try to grab or start a screen session
                   if none available  doing whatever it takes
ESC == ^A  normally (I usually redefine to ^O)
            Some people like ^@  (which results in ^ as ESC)
ESC-?  help 
ESC-d      detach (throw into background) current screen session
ESC-c      open another virtual console
ESC-k      kill the current virtual console (or you can just exit it)
ESC-t  show system info (including time/date by default)
ESC-:  open screen command prompt at bottom of console
               (can enter commands normally mapped to keys etc.)
                    ~ ':' ex-mode in vi or lynx, or w3m
ESC-p/n     previous / next virtual console, cycling through them
ESC-#       (#==0-9) select console  #
ESC-A       give virtual console a name (or view the current console name)
ESC-'       pull up prompt to give a virtual console # or name & then switch
ESC-"       pull up virtual console selection menu
ESC-[       put in copy / scroll mode
  in copy/scroll mode:
      ('.'   for  a register, is interpretted as the paste buffer )
      (~vi cursor movement)
      c / C   set left / right margins
       or  set a mark (first or second)
      W       grab word under cursor
      Y       mark whole line
      y       mark from start of line
      x       eXchange current cursor position and mark
      a       kick into append (to buffer) (instead of overwrite buffer ) mode
      A           "          *AND* set a mark
      J     cycle through join/join with spaces/join with commas/multiple lines
      |       move to absolute column       
      g       go to top of scroll buffer
  ESC-]      dump paste buffer to stdout
   
shared sessions with screen:
http://www.lowlevelmanager.com/search/label/pair%20programming
              (courtesey local Perl Mongers chief)
http://www.caikesouza.com/blog/category/linux/
(see article for permissions set up)

(for user foo:)
screen -S pairprog
^A :multiuser on
^A :acladd bar  

To make other read-only:
^A :aclchg bar -w "#"

(user bar:)
Then to join:
screen -x foo/pairprog

http://www.lafn.org/~aw585/gh.html
           - has some examples of setting up a text console 'desktop',
               and stuffing commands on startup into a program on startup
                 with screen

http://isthereanotherquestion.blogspot.com/2008/06/full-screen-ahead.html

some packages/programs to interact with screen (I don't use any of these):
iselect
screenie
byobu

Some similar programs:
tmux (~a ground up rewrite)
dvtm   (simpler, more tiling oriented)
splitvt   (very simple lite horizontal split)
fbterm    (requires frame buffer) 

-- Dallas E. Legan 2015 March 04

Extracting the mp3 From a Video

(In reference to a recent SFVLUG meeting....)

At the last meeting the question of how to extract an audio already in mp3 format from a video into a stand alone file came up.

I suggested something along the lines of

$ ffmpeg -i videofile -ac copy audiofile.mp3

making sure the output file has an extension of '.mp3', which is almost right but has an error.

It should be:

$ ffmpeg -i videofile -acodec copy audiofile.mp3

I mentioned mkvextract if the file was already matroska in the conversation. This actually implies another method of doing this, first convert to matroska with mkvmerge, then use mkvextract to dump the audio track:

$ mkvmerge -o intermediate_video.mkv videofile

$ mkvextract tracks intermediate_video.mkv 1:audiofile.mp3



$ rm -f intermediate_video.mkv

assuming, as typically happens, that track 1 of the matroska is the audio file. That probably should be verified, with

$ mkvmerge --identify intermediate_video.mkv

Yet another approach would be


$ mplayer -dumpaudio -dumpfile audiofile.mp3 videofile

Apparently mpv, an mplayer fork, does not currently support '--dumpaudio'. (To my suprise.)

Undocumented scp

Recently I had need to set up some ssh keys and restrict their use to
only work with scp, not ssh in general.

After some fumbling around, I conducted some tests with no restrictions on the key
at the target remote host, with verbosity maximized with the local invocation of scp.
Scanning the output, there was mention of running 'scp -v -t ...' on the remote
system, which provided the key on how to do this.
With a bit of further testing, I found placing

command="/usr/bin/scp -v -t .../target/directory/"

in the options of the key involved in the ~/.ssh/aurthorized_keys
produced the desired effect.

Thinking I was probably not the only person to notice this, I googled
for "scp undocumented" and found references to '-d' and '-f' keys as well.

In the task of restricting ssh keys to only scp functionality there
seemed to be what I percieved as a lot of murkiness, with references
to a special 'scponly' shell etc., where an understanding of the
'-f' and '-t' keys would seem to be good for a lot of mileage.
Introducing other programs seems to introduce the possibility for
more bugs and confusion.
There is some mention of the '-f' and '-t' switches in O'Reilly's
SSH book, but not the man page.
("SSH, The Secure Shell: The Definitive Guide",
ISBN: 0-596-00011-1
Daniel J. Barrett and Richard E. Silverman
chapter 3.8.1, first edition 2001)

After some experiments, these are the guidelines I found for using
the '-t' and '-f' switches with cp in ~/.ssh/authorized_keys command="..." options.


1) Locally, everything after the ':', the user@host#port command line description of the remote
host, or ~/.ssh/config defined host parameters, is ignored.
This means you must specify the target directory or
file name in the remote hosts 'command=' option.
This may seem inflexible, but that is actually the goal of 'command=' options, to
reduce flexibility, and restrict the key to only desired effects.
Unless explicit, fully qualified directory paths are used,
directories are relative the home directory of the receiving user account.

2) '-t' ("To:")seems to closely parrallel the '-t' option in Gnu implimentations of 'cp' and
'mv' commands, but with scp you use it only in the remote 'command=' option.
It is used when the remote host is to recieve files.
If a file name is specified after '-t', it will be used literaly, so patterns
in this name are useless - they will only result in awkward file names that
use file matching metacharacters.
This also means that if a file name is specified, it will be overwritten each time
scp using the key is used, unless other actions have been taken
between invocations. Example:

command="/usr/bin/scp -v -t some/dir/".......

3) '-f' ("From:") is used when the remote host is sending files.
A pattern for a file name must be
appended to the directory specification. This pattern can be an explicit, particular file name.
To copy and entire directory, you would use '*', so:

command="/usr/bin/scp -v -f some/dir/*".....

4) If the desired effect is to recursively send a directory tree,
the '-r' switch must be used at both ends of the network connection, the simple invocation of
scp, and the 'command=' forced command.
When the remote host is recursively sending the tree, some pattern matching files
and directories must be part of the path specified in the 'command=' option.
This would most likely be '*' (dir/path/*).
When the remote host is receiving a recursively send directory tree, no file name
can be included 'command=' option, or on metacharacter garbage will result.
If you are sending directory trees recursively, it is likely you really want to
use rsync, but there may be obscure uses for this feature of scp.

5) I've yet to determine anything about the '-d' switch.

Dallas Legan,
dallas.legan@gmail.com
2013 Nov. 24

Rebirth?

I'm taking a break from the series on PDF handling,
for a bit, while reviving my blog.
Originally, I was going to post to thank Google for re-enabling support for Lynx some time back.
I'd noticed being able to log in with Lynx again after apparent Google
spokespersons had posted in various lists that they had gone through
their services and thrashed out various accessability/usability
issues.
But when I tried to log in tonight to actually post,
it had all evaporated.
No matter what obstructions Google places in the way of my posting,
the browser is only a tool to get to the point of running vi
to enter the actual content.
Maybe they will go back and clean up these obstructions
to browser choice. There is nothing intrinsicly graphical or
javascript necessary to edit a blog post, so maybe this will change.
I will be checking into submitting via e-mail to get past this.
d.e.l. 2012 Apr. 23
All that was last night.
Now, I'm posting with Lynx no problem, but there is a warning that
the old interface will be gone by the end of the month.
I'll see what happens. I'm not trying to bad mouth Google,
they are trying to balance somewhat conflicting goals,
but I'm confident they will find a way.
d.e.l. 2012 Apr. 23

zgv'ing Again

When I started the series of posts on console tools for PDF files, I had another computer, and it handled graphics from the console differently. The chipset on the old computer was directly supported by SVGAlib and everything was working fine as far as I was concerned. When I upgraded to the current computer I found many of the graphics programs I was using needed to be shifted over to using frame buffer drivers or versions, as the video chipset on this PC seemed to be marginally (or in some instances brittly) supported in Linux. In some instances this was a gain, one example being w3m, which I can if so choosing run as a graphical web browser. In a couple of instances, zgv and svncviewer, I had to do without a console program and use an X program.

zgv is one of the more amazing graphic applications that run from the raw console in Linux. Perhaps even more amazing than watching videos in a naked command line interface. It is an image viewer that can be used on single images, slide shows, or a directory of image files, handling most of the formats we are familiar with. It has some simple image processing capabilities, and when navigating a directory of images, can generate thumbnails of all the images and can present a graphical navigation interface with these thumbnails. The alternate viewer 'fbi' (Frame Buffer Imageviewer) if fine, but to date simply lacks some of the many capabilities of zgv. I first encountered zgv as a default image viewer for text browsers such as Lynx and w3m.

It's been over a year since I got the new computer, and the other morning, I decided to try to see if there was some way to revive use of zgv. It never failed to run, but in maybe half the images colors were distorted beyond reasonable use - something like solarization of color phototgraphic film - great if you want an LSD/Timothy Leary effect but not for daily use.

In the SVGAlib configuration file, I'd hardcoded use of the framebuffer driver (as opposed to SVGAlib choosing one of the supported chipsets) by uncommenting the line:

chipset FBDEV           # Use kernel fbdev, instead of direct hardware.

in the file /etc/vga/libvga.config. With this, applications that use SVGAlib will now indirectly use the video framebuffer. I rummaged around a bit through the zgv man pages, trying various things. One clue I searched on to see if there was something that might get it working consistently was the word 'force'. My notion was that perhaps something was being misinterpreted by the program and it 'forcing' some initial condition might solve the problem. I finally found a switch '--force-viewer-8bit' (or briefly '-j') that seems to do the trick. No solarization effects. It may be that some images could be displayed with greater sharpness or color accuracy, '8bit' throwing away parts of 16/24 bits of pixel information, but everything *looks* reasonable. Nothing is reduced to psychedelic poster (or even comicbook) appearence. The worst thing I've encountered so far is that after looking at information on the image file sometimes I need to refresh the display with a CTL-L or CTL-R, but this is a minor point. To make this default behaviour, edit the file /etc/zgv.conf and add the line:

force-viewer-8bit on

A few other settings I include in the file (you can look them up in the man page) are:

zoom on
centre on
auto-mode-fit on
jpeg-speed 1
mousescale 2.0
mouse on
block-cursor on
fs-perfect-cols on
jpeg-index-style 3
fs-thick-text on

A couple that apparently must be left out of the configuration file and placed among command line switches are:

#  show-dimensions on
# reload-delay 1000000
#   - fatal in this file

A few of the more important commands of zgv:

?        -  help
ESC      -  return to previous mode (eventually exiting)
Enter    -  go to the next image
v        -  toggle file selector mode between graphical or text
/        -  help for video modes available
:        -  display file information
;        -  reset brightness/contract/etc. to default
Alt-u    -  generate/update thumbnail images
Ctrl-I   -  start a slide show of files tagged in file selector mode.
Ctrl-R   -  refresh view/directory
Ctrl-L   -  refresh view/directory
Right Mouse button  -  context sensitive menu
Left  Mouse button  -  select an image or directory in file selector/directory view mode

You can navigate the file selector or large images with cursor, vi or (what I think are) WordStar keys. I leave exploring the various zooming, rotating, mirroring, flipping, contrast, brightness, gamma, rendering and file tagging capabilities to you, the reader. The ironic reality is that using this as the viewer for a text mode web browser, the surfer has more control over image viewing than any I've encountered with so called graphical web browsers.

A few of the command line switches can be of use. The '--reload-delay 100000' mentioned above effectively sets the default slide show interval to totally at the users decision to move on, instead of the default 4-sec. '--show-dimensions' (or -s) causes zgv to print the dimensions of displayed files to standard out, perhaps to pass on to some program for image processing. '-T' causes zgv to print the names of tagged files to standard out, where they could (for instance) be passed on via a script to CUPS and printed out, or copied/moved to a holding directory. And this really is the tie-in with these article with on .pdf. After using ghostscript to convert the pages of a pdf document to images, you can browse through them with zgv in file selector mode, tag some, and have them printed out.

With bmv ...

When I first started this series of posts on command line access to pdf files I had a different computer, one that was pretty compatible with SVGALib tools. The newer computer seems to work with SVGALib with extreme unpredictability. There seems to be decision 'out there' to not bother with keeping SVGALib current, to try and shift things towards use of frame buffers, which seem to work fine on the new PC> A while back I became aware of a frame buffer based tool for viewing postscript files called bmv. To take advantage of in pdfmenu, I added some lines:

alias PDFTOPS='/usr/bin/pdftops  '  ;
alias BMV='/usr/bin/bmv -m1 -v13 '  ;
    #       the -m/-v values were tuned by tests to what seemed
    #       to work best on my computer for typical .pdf files.
..........
 10 )
    THEPSFILE="${INSIDEFILE#/tmp/}"  ;
    THEPSFILE="/tmp/${THEPSFILE%.pdf}.ps"  ;
    RM  ${THEPSFILE}  ;
    PDFTOPS  ${INSIDEFILE}   ${THEPSFILE}  ;
    BMV      ${THEPSFILE}  ;
    RM ${THEPSFILE}  ;
    ;;
  

and appropriate entries to the select menu. bmv is fairly easy to figure out how to navigate. In general, I'm satisfied with it's job of showing .pdf files.

pdfmenu

As you may have figured out by now, I created a master script for handling pdf files when in text consoles. I've put this up at http://www.lafn.org/~aw585/pdfmenu. There are probably many improvements that can be made to this but it provides a simple way to attack pdf files.