ipick reads lines of text from the standard input or the optional filename and uses curses(3) to present them as a full-screen selection list. ipick provides numerous commands to select, navigate, scroll and search through this list. On quitting, ipick writes the selected lines to the standard output.
Typically you would use ipick as a final-filter to glue your neat, pre-stored pipelines and scripts together in a friendly way so that people other than Unix-o-philes can use them.
See MOTIVATION, towards the end, for a more detailed discussion.
Options can appear in any order so long as they precede the filename.
The -m, -M and -r options allow you to carefully control the actions and predict the results of a user. For example, if you use
then you can write the rest of the pipeline assuming that ipick will produce one and only one line of output.
ipick accepts numerous keyboard commands, perhaps the most important being ? which provides online help.
ipick is ecumenical regarding keybindings as it implements a reasonable set of emacs, vi and more keybindings concurrently! Additionally, ipick binds all of the commonly used commands to function keys as defined in the TERMINFO (or the corresponding termcap) definition file. This means that users can avoid learning the idiosyncratic nature of vi and emacs keystrokes.
The list of keyboard commands uses the following symbols:
Selection Commands
The ``line-range'' given to the ``s'', ``c'' and ``t'' commands may consist of any one of:
(e.g. 1 5 7-14 21-19)
You may shorten both ``visible'' and ``all'' to just ``v'' and ``a'' respectively. ipick ignores the case of these strings.
Positioning commands
Vertical scrolling
Horizontal scrolling
Searching
Miscellaneous
ipick has limited support for xterm's ``mouse tracking'' capability (the X11 ``normal tracking mode'' not the X10 compatibility mode).
To enable this facility in a particular xterm you have to send it a special escape sequence. To quote from xterm(1) , ``[mouse tracking] is enabled by specifying parameter 1000 to DECSET''. ipick does this automatically when it detects a terminal type of xterm. If your xterm clone uses a different name, you can use the -X option to tell ipick what it is.
When you enable this facility, your xterm will pass any mouse events to ipick in a form that ipick recognizes. In all cases, the down event defines the start of a range of lines and the up event defines the end of the range -- so dragging is useful.
Each mouse button has the following function:
Note that ipick ignores augmentation of mouse events with the Shift, Control and Meta keys.
The xterm facility is limited in that chording the mouse buttons seems to be undefined. Furthermore, the release (or mouse-up) doesn't specify the button. Accordingly ipick takes a conservative approach to mouse-events and tends to discard anything unexpected.
Exit codes.
If no input exists, or if the -T option causes ipick to consume all its input, then ipick terminates silently with an exit code of 1.
Each Newline terminated string in fixed-title-text (see the -t option) becomes a separate line on the fixed-title section of the screen.
ipick only reads lines from the standard input as needed (and after each keyboard command) rather than reading all input lines on starting. This is especially useful if the upstream process generates output lines slowly as ipick is able to display lines as soon as they become available - within the constraints of any buffering. It is also useful if the upstream process has the potential to generate an enormous number of lines of output prior to completion.
ipick processes binary files correctly, but it's hard to imagine that this capability is especially useful.
When constructing pipelines, be aware of the fact that many commands don't take multiple parameters. In these cases, use xargs -l1 if your system has it.
ipick is designed to process modest amounts of data. The data is held in memory and all functions are coded simplistically. If you ask ipick to handle large amounts of data, it does so sluggishly and consumes excessive system resources.
ipick takes a passive approach to ambiguous function key definitions -- later definitions override earlier definitions.
The search function does not handle regular expressions.
There is no .ipickrc file to add or override the default keybindings -- yet!
Because of the way in which ipick reads the standard input, using ipick with data from the keyboard does not work as you would want (In fact ipick should probably insist on a pipe or a file as input, just as more does). The workaround is to use the ``here document'' capability of the shell (the ``<<'' redirection).
ipick arbitrarily expands tab characters to 8-column tabstops.
The online help does not display properly if the screen is less than 80 columns wide.
Arguably ipick could use select() and look ahead for keyboard signal characters rather than rely on cbreak mode as this method would protect other processes in the same process group. However, this is less portable and messy.
Directions implied by movement and scrolling commands apply to the cursor, not the data.
It is the very essence of Unix to make useful commands with the generic construct:
or
The problem is FILTER. Getting it correct for the simplistic case is easy, making it perfect and bullet-proof is not. This is especially true if the pipeline is being developed for the user community.
Think about how you typically build a pipeline for the following requests:
Either you construct a nice obscure FILTER using some combination of grep(1) , awk(1) , perl(1) , or sed (1) -- usually after you've had a look at the generate_listing output a couple of times to make sure you don't zap the wrong thing! Alternatively you run the generate_listing program a couple of times until you've memorized the relevant identifier (such as pid, job number, queue id), then you run the do_something program and re-type the relevant identifier trying as best you can to avoid mis-typing and mis-remembering.
In other words, tedious and error-prone.
Of course, when the time comes to give your neat pipeline or script to the user community, how do you give it an easy to use, safe, bullet-proof interface? Do you knock up a quick shell wrapper with token prompts, perfunctory checking and an interface that's almost the same as your last shell wrapper?
If any of these situations sound familiar then ipick may well be your pipeline panacea! (Well, at least marginally useful.)
This is because ipick makes the user the final part of the FILTER in a safe, friendly manner, often obviating the need for shell wrappers and such.
The example of selecting and removing a set of print jobs is the easiest
way to demonstrate ipick. With the pipeline:
A few more examples to get you started. Normally you would define each of these as a function or alias in your shell. (Of course, I present these examples as ideas. They are not complete, bullet-proof functions.)
Pick source files to edit.
Actually, in its current form the above example
has a number of limitations, so a more complete solution to an interactive
tar is:
tar tvf ${1:-/dev/rmt8} | sed -e 's./$..' | ipick | \ cut -c42- | xargs -i -t tar xvf ${1:-/dev/rmt8} {}
Part of the login script to set the terminal type
#! /bin/sh...export TERMTERM=`ipick -m1 -M1 -r -a -T3 <<EOD | cut -f1 -d' ' Pick the terminal type that you are logged intovt100 The old grey terminals in the conference roomxterm The new fancy terminals in the bosses officesun One of the workstations in the sysadmin's office!EOD`...
Site conventions for predefined files
If you get really keen, you can have a site convention for all pre-defined ipick files, such as:
Then you can define a generic
function or script (let's call it ipickf) such as:
Copyright (c) 1992, Mark Delany <markd@werple.pub.uu.oz.au> All rights reserved.
Substantial man page improvements by DaviD W. Sanderson <dws@ssec.wisc.edu>
ipick may only be copied and used under the terms and conditions of the COPYRIGHT notice found in the source kit.