For some reason, a portable solution (i.e., something that works on most common flavors of POSIX systems, from the Linux variety to the Unix ones) to this is a little tricky. Here is one that seems to do the job: get_abs_path()
The solution to this problem is to the “Argument list too long” error when trying to archive a large number of files is the “-T” option of the “tar” command to pass in a list files generated by a “find” command: Create a list of the files to be archived using the “find” command: $ find . -name="*.tre" > filelist.txt Use the “-T” option of the “tar” command to pass in this list of filenames:
R R is like a microwave oven. It is capable of handling a wide range of pre-packaged tasks, but can be frustrating or inappropriate when trying to do even simple things that are outside of its (admittedly vast) library of functions. Ever tried to make toast in a microwave? There has been a push to start using R for simulations and phylogenetic analysis, and I am actually rather ambiguous about how I feel about this.
Here I present a script that provides diagnostics about the current Python execution context, or the Python environment of the interpreter passed as an argument. As a Python developer, I have multiple Python versions side-by-side for testing purposes, using scripts that munge my $PATH variable to “import” and “unimport” different versions of Python as I need them. While “which python” is always available, many times I want to know things like, “what is the version of the current default Python?
I recently integrated unit test code coverage analysis (using coverage) as a setuptools command extension into the DendroPy phylogenetic computing library, and thought that I would share how this was done. Providing the Command Extension The first step is to provide the command functionality in a class that derives from “setuptools.Command” in a separate module of the package, which, in my case, was called “coverage_analysis.py”, located in the “test/support” subdirectory of the DendroPy package
I added the following to my ~/.bashrc and I am loving it! ## Up Arrow: search and complete from previous history bind '"\eOA": history-search-backward' ## alternate, if the above does not work for you: #bind '"\e[A":history-search-backward' ## Down Arrow: search and complete from next history bind '"\eOB": history-search-forward' ## alternate, if the above does not work for you: #bind '"\e[B":history-search-forward' (see the comments below for explanation of the alternate codes) The first command rebinds the up arrow from “previous-history”, which unconditionally selects the immediately preceding command from your command history, with “history-search-backward”, which selects the previous command in your history that begins with the characters you have already typed in.
Vim continues to surprise me with its wonders. Sometimes (many times, in fact) things do not make sense, and I am perplexed as to the reasoning behind them. Then, one day, I grokked it. And from that day on, I can never imagine any other way of doing it. An example of this was my confusion over the apparent redundancy of two fundamental commands. In normal mode Vim, “s” (mnemonic: “substitute”) and “c” (mnemonic: “change”) are both ways to remove some existing text and then go into insert mode.
It is past 4 am, and the bug hunt is over. It was a weird one. One that I’ll remember. It led me on a wild exhausting chase through dark nooks and crannies of a horribly-written nightmare of a code base. What made it weird was that, with the same random number seed, I got different behavior depending on whether there were some (debugging-related) print statements in some parts of code.
The Great Controversy A standard dictum amongst experienced Vim users is not to use the arrow keys to move around your document. This dictum is often repeated again and again, in tones that range from the taken-for-granted to hysterical-zeal. The most common reason given for this is that using the arrow keys takes your hands away from the home row of your keyboard, and thus is wasteful both in terms of time and energy, whereas the standard Vim movement keys — h, j, k, and l — keep your hands on the home row, and therefore is far more efficient.
The Sorceror color scheme for Vim: