## Log output for screen

The one thing that annoys me when I use screen is that I can’t scroll up after a long output has printed. To log outputs, add the following near the top (required!) of your screenrc file (\$HOME/.screenrc):

# auto-log http://www.cmdln.org/2007/07/20/automatic-session-logging-and-monitoring-with-gnu-screen-for-the-paranoid/
## search for "STRING ESCAPES" in the manpage
# logfile /tmp/screen_%Y-%m-%d-%c:%s_%n.log
## not using above because every window gets its own time too.  rather use session name; need 4.01.00devel (GNU450e8f3) 2-May-06 and above
logfile /tmp/screen-%S-%n.log
deflog on


For example, my rc file now looks like:

escape ^Oo
# auto-log http://www.cmdln.org/2007/07/20/automatic-session-logging-and-monitoring-with-gnu-screen-for-the-paranoid/
## search for "STRING ESCAPES" in the manpage
# logfile /tmp/screen_%Y-%m-%d-%c:%s_%n.log
## not using above because every window gets its own time too.  rather use session name; need 4.01.00devel (GNU450e8f3) 2-May-06 and above
logfile /tmp/screen-%S-%n.log
deflog on
##escape \56\56 ##ascii octal http://www.robelle.com/library/smugbook/ascii.html http://www.ncsu.edu/it/mirror/ldp/LDP/LGNET/147/appaiah.html Use C-. for escape
## following for starting screen at 1 instead of 0
## http://www.linuxquestions.org/questions/linux-software-2/gnu-screen-start-window-numbering-at-1-keep-window-number-0-from-ever-being-used-772580/
bind c screen 1
bind 0 select 10
screen 1
select 1


When I originally had the log options at the bottom, logging did not work for me.

Finally, you can use the %S string escape to refer to the session name in screen 4.01.00devel (GNU450e8f3) 2-May-06 and after. It might be wise to install the git version of screen.

## Compiling bleeding edge version of screen

sudo apt-get remove screen
git clone git://git.savannah.gnu.org/screen.git
cd screen
./mktar
tar xvf screen-*.tar.gz
cd screen*/
./autogen.sh
./configure
make
sudo make install


## Version control and collaborating with LaTeX files

This post finally pushed me to explore ways to version control and collaborate with others using LaTeX files. I’m assuming the collaborators also use LaTeX, which is rare in itself when your primary collaborators are scientists that work mainly with WYSISWG editors, in particular, MS Word. I will outline how I collaborate with non-LaTeX users in a future post.

One issue arises with LaTeX files. When writing prose, I tend to write continuously on a line until a line break is necessary, usually when a new paragraph begins or when I introduce long math formulas. When diff is used to compare two LaTeX files, it is hard to see where a change occured in long line since diff looks at changes in lines; this problem is well documented.

The first obvious solution is to break up your lines. A fill-type solution will probably not work too well with diff with that 80 character restriction since a small change might affect more than one line. Comments from the original post suggests using a single line for each sentence. I think this is reasonable for readability and for diff to work. However, when collaborating with others, they might not abide by this preference.

The utility wdiff is another suggested solution that looks at differences in words instead of lines. The only problem I see with it is that the entire file will be printed, with words that are added and removed “highlighted” in the text using braces and brackets; its hard to see all the changes immediately with long files. This site shows how to add additional LaTeX markup that will highlight the changes visually on a generated dvi/ps/pdf file. The utility latexdiff also carries this out, and appears to be very popular among users. The output document is marked up similar to the “Track Changes” feature of your typical WYSIWYG editors.

latexdiff install on ubuntu:

<pre class="src src-sh">sudo apt-get install latexdiff


Moving forward, I will abide by the one sentence per line principle. However, I cannot force collaborators to do this, so will use wdiff and latexdiff to compare their changes. To assist in the first task, I can insert a new line after period using with the help of regexp-replace or replace-string on a region (two spaces to new line C-q C-j).

## Finally started to version control my files using Git

I’ve been aware of different version control systems since I started using Linux. Why? Often times I am asked to install the latest development version of a software as the last tarball (*.tar.gz) has not been updated for a while. I’ve pulled code most often using Subversion (SVN), Git, and CVS. Of the various version control systems, I must say Subversion is the most prevalent out there. However, I’ve heard many preach about Git, similar to people preaching about Emacs (me being one of them). Even though Git is not as “standard” as Subversion, I chose Git because

1. many acquaintances I think highly of use Git,
2. many tutorials out there (although this is true for most popular systems),
3. Linux kernel is managed using Git, and
4. existence of git-svn, so I can still use SVN through Git.

I will write more about my experience with Git on particular projects later (e.g., Git with SVN on R-Forge). For this post, I’ll just post some references I’ve used to learn Git and the common commands I use (reminder to self).

First, read this short tutorial to understand Git. Like the author described, most tutorials show you command. The author tries to explain the concept of version control and their principles in Git.

Try out Git on one of your projects (create a folder and create and edit some files).

Next, read the Git Magic book (online). It gives a good analogy of version control to video games, along with

Re-read how Git works, play with files, and Git Magic.

For Git and SVN, this site and this site helped me get started. Note: I did not use -s in the git svn clone. This is also a good intro to Git.

To undo what you’ve edited since the last commit, remember git reset --hard HEAD.

Once I get the command lines down well to know exactly what’s going on, I plan to incorporate magit, an emacs extension for git, into my workflow.

Now, my notes to remember:

 <pre class="src src-sh"><span style="color: #ff4500;">## </span><span style="color: #ff4500;">start version control in a project/folder</span>


git init git add … ## files, folders, etc. git commit -a -m “COMMENTS” ## commit

Uhh, how about just google “git reference card” to obtain this card and this card.

## Managing a statistical analysis project – guidelines and best practices

Had to share this link today as I better read all the content it refers to and incorporate a lot of the recommended practices into my work flow. Thanks Tal Galili for compiling all those information.