git-whatchanged

•May 13, 2011 • Leave a Comment



SYNOPSIS
git-whatchanged <option>…

DESCRIPTION
Shows commit logs and diff output each commit introduces. The command
internally invokes git-rev-list piped to git-diff-tree, and takes
command line options for both of these commands.

This manual page describes only the most frequently used options.

OPTIONS
-p
Show textual diffs, instead of the git internal diff output format
that is useful only to tell the changed paths and their nature of
changes.

-<n>
Limit output to <n> commits.

<since>..<until>
Limit output to between the two named commits (bottom exclusive,
top inclusive).

-r
Show git internal diff output, but for the whole tree, not just the
top level.

-m
By default, differences for merge commits are not shown. With this
flag, show differences to that commit from all of its parents.

However, it is not very useful in general, although it is useful on
a file-by-file basis.

–pretty[=<format>]
Pretty-print the contents of the commit logs in a given format,
where <format> can be one of oneline, short, medium, full, fuller,
email, raw and format:<string>. When omitted, the format defaults
to medium.

Note: you can specify the default pretty format in the repository
configuration (see git-config(1)).

–abbrev-commit
Instead of showing the full 40-byte hexadecimal commit object name,
show only handful hexdigits prefix. Non default number of digits
can be specified with “–abbrev=<n>” (which also modifies diff
output, if it is displayed).

This should make “–pretty=oneline” a whole lot more readable for

limited your view of history: for example, if you are only interested
in changes related to a certain directory or file.

Here are some additional details for each format:

o oneline

<sha1> <title line>
This is designed to be as compact as possible.

o short

commit <sha1>
Author: <author>

<title line>

o medium

commit <sha1>
Author: <author>
Date: <author date>

<title line>

<full commit message>

o full

commit <sha1>
Author: <author>
Commit: <committer>

<title line>

<full commit message>

o fuller

commit <sha1>
Author: <author>
AuthorDate: <author date>
Commit: <committer>
CommitDate: <committer date>

<title line>

<full commit message>

o email

o format:

The format: format allows you to specify which information you want
to show. It works a little bit like printf format, with the notable
exception that you get a newline with %n instead of \n.

E.g, format:”The author of %h was %an, %ar%nThe title was >>%s<<%n”
would show something like this:

The author of fe6e0ee was Junio C Hamano, 23 hours ago
The title was >>t4119: test autocomputing -p<n> for traditional diff input.<<
The placeholders are:

o %H: commit hash

o %h: abbreviated commit hash

o %T: tree hash

o %t: abbreviated tree hash

o %P: parent hashes

o %p: abbreviated parent hashes

o %an: author name

o %aN: author name (respecting .mailmap)

o %ae: author email

o %ad: author date

o %aD: author date, RFC2822 style

o %ar: author date, relative

o %at: author date, UNIX timestamp

o %ai: author date, ISO 8601 format

o %cn: committer name

o %cN: committer name (respecting .mailmap)

o %ce: committer email

o %cd: committer date

o %cD: committer date, RFC2822 style

o %Cgreen: switch color to green

o %Cblue: switch color to blue

o %Creset: reset color

o %m: left, right or boundary mark

o %n: newline

o %x00: print a byte from a hex code

o tformat:

The tformat: format works exactly like format:, except that it
provides “terminator” semantics instead of “separator” semantics.
In other words, each commit has the message terminator character
(usually a newline) appended, rather than a separator placed
between entries. This means that the final entry of a single-line
format will be properly terminated with a new line, just as the
“oneline” format does. For example:

$ git log -2 –pretty=format:%h 4da45bef \
| perl -pe ‘$_ .= ” — NO NEWLINE\n” unless /\n/’
4da45be
7134973 — NO NEWLINE

$ git log -2 –pretty=tformat:%h 4da45bef \
| perl -pe ‘$_ .= ” — NO NEWLINE\n” unless /\n/’
4da45be
7134973

EXAMPLES
git-whatchanged -p v2.6.12.. include/scsi drivers/scsi
Show as patches the commits since version v2.6.12 that changed any
file in the include/scsi or drivers/scsi subdirectories

git-whatchanged –since=”2 weeks ago” — gitk
Show the changes during the last two weeks to the file gitk. The
“–” is necessary to avoid confusion with the branch named gitk

AUTHOR
Written by Linus Torvalds <torvalds@osdl.org[1]> and Junio C Hamano
<gitster@pobox.com[2]>

DOCUMENTATION
Documentation by David Greaves, Junio C Hamano and the git-list
<git@vger.kernel.org[3]>.

GIT

Git 1.5.6.5 09/24/2010 GIT-WHATCHANGED(1)

run-mailcap

•May 12, 2011 • Leave a Comment


SYNOPSIS
run-mailcap –action=ACTION [--debug] [MIME-TYPE:[ENCODING:]]FILE [...]

The see, edit, compose and print versions are just aliases that default
to the view, edit, compose, and print actions (respectively).

DESCRIPTION
run-mailcap (or any of its aliases) will use the given action to pro-
cess each mime-type/file in turn. Each file is specified as its mime-
type, its encoding (e.g. compression), and filename together, separated
by colons. If the mime-type is omitted, an attempt to determine the
type is made by trying to match the file’s extension with those in the
mime.types files. If the encoding is omitted, it will also be deter-
mined from the file’s extensions. Currently supported encodings are
gzip (.gz), bzip (.bz), bzip2 (.bz2), and compress (.Z). A filename of
“-” can be used to mean “standard input”, but then a mime-type must be
specified.

Both the user’s files (~/.mailcap; ~/.mime.types) and the system files
(/etc/mailcap; /etc/mime.types) are searched in turn for information.

EXAMPLES
see picture.jpg
print output.ps.gz
compose text/html:index.htm
extract-mail-attachment msg.txt | see image/tiff:gzip:-

OPTIONS
All options are in the form –<opt>=<value>.

–action=<action>
Performs the specified action on the files. Valid actions are
view, compose, composetyped, edit and print. If no action is
specified, the action will be determined by how the program was
called.

–debug=<value>
Turns on extra information to find out what is happening. Any
value other than zero (0) will turn on debugging output.

SEE ALSO
update-mime(8)

AUTHOR
run-mailcap (and its aliases) was written by Brian White
<bcwhite@pobox.com>.

COPYRIGHT
run-mailcap (and its aliases) is in the public domain (the only true
“free”).

yuvsplittoppm

•May 11, 2011 • Leave a Comment


SYNOPSIS
yuvsplittoppm basename width height [-ccir601]

DESCRIPTION
Reads three files, containing the YUV components, as input. These
files are basename.Y, basename.U, and basename.V. Produces a portable
pixmap on stdout.

Since the YUV files are raw files, the dimensions width and height must
be specified on the command line.

OPTIONS
-ccir601
Assumes that the YUV triplets are scaled into the smaller range
of the CCIR 601 (MPEG) standard. Else, the JFIF (JPEG) standard
is assumed.

SEE ALSO
ppmtoyuvsplit(1), yuvtoppm(1), ppm(5)

AUTHOR
Marcel Wijkstra <wijkstra@fwi.uva.nl>, based on ppmtoyuvsplit.

26 August 93 yuvsplittoppm(1)

ipcrm

•May 10, 2011 • Leave a Comment



SYNOPSIS
ipcrm [ -M key | -m id | -Q key | -q id | -S key | -s id ] …

deprecated usage

ipcrm [ shm | msg | sem ] id …

DESCRIPTION
ipcrm removes System V interprocess communication (IPC) objects and
associated data structures from the system. In order to delete such
objects, you must be superuser, or the creator or owner of the object.

System V IPC objects are of three types: shared memory, message queues,
and semaphores. Deletion of a message queue or semaphore object is
immediate (regardless of whether any process still holds an IPC identi-
fier for the object). A shared memory object is only removed after all
currently attached processes have detached (shmdt(2)) the object from
their virtual address space.

Two syntax styles are supported. The old Linux historical syntax spec-
ifies a three letter keyword indicating which class of object is to be
deleted, followed by one or more IPC identifiers for objects of this
type.

The SUS-compliant syntax allows the specification of zero or more
objects of all three types in a single command line, with objects spec-
ified either by key or by identifier. (See below.) Both keys and iden-
tifiers may be specified in decimal, hexadecimal (specified with an
initial ’0x’ or ’0X’), or octal (specified with an initial ’0′).

OPTIONS
-M shmkey
removes the shared memory segment created with shmkey after the
last detach is performed.

-m shmid
removes the shared memory segment identified by shmid after the
last detach is performed.

-Q msgkey
removes the message queue created with msgkey.

-q msgid
removes the message queue identified by msgid.

-S semkey
removes the semaphore created with semkey.

-s semid
removes the semaphore identified by semid.

AVAILABILITY
The ipcrm command is part of the util-linux-ng package and is available
from ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/.

ipcrm last change: 19 March 2002 IPCRM(1)

wc

•May 9, 2011 • Leave a Comment



SYNOPSIS
wc [OPTION]… [FILE]…
wc [OPTION]… –files0-from=F

DESCRIPTION
Print newline, word, and byte counts for each FILE, and a total line if
more than one FILE is specified. With no FILE, or when FILE is -, read
standard input.

-c, –bytes
print the byte counts

-m, –chars
print the character counts

-l, –lines
print the newline counts

–files0-from=F
read input from the files specified by NUL-terminated names in
file F

-L, –max-line-length
print the length of the longest line

-w, –words
print the word counts

–help display this help and exit

–version
output version information and exit

AUTHOR
Written by Paul Rubin and David MacKenzie.

REPORTING BUGS
Report bugs to <bug-coreutils@gnu.org>.

COPYRIGHT
Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU
GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

SEE ALSO
The full documentation for wc is maintained as a Texinfo manual. If
the info and wc programs are properly installed at your site, the com-
mand

info wc

mcookie

•May 8, 2011 • Leave a Comment



SYNOPSIS
mcookie [-v] [-f filename ]

DESCRIPTION
mcookie generates a 128-bit random hexadecimal number for use with the
X authority system. Typical usage:
xauth add :0 . `mcookie`

The “random” number generated is actually the output of the MD5 message
digest fed with various piece of random information: the current time,
the process id, the parent process id, the contents of an input file
(if -f is specified), and several bytes of information from the first
of the following devices which is present: /dev/random, /dev/urandom,
files in /proc, /dev/audio.

BUGS
The entropy in the generated 128-bit is probably quite small (and,
therefore, vulnerable to attack) unless a non-pseudorandom number gen-
erator is used (e.g., /dev/random under Linux).

It is assumed that none of the devices opened will block.

FILES
/dev/random
/dev/urandom
/dev/audio
/proc/stat
/proc/loadavg

SEE ALSO
X(1), xauth(1), md5sum(1)

AVAILABILITY
The mcookie command is part of the util-linux-ng package and is avail-
able from ftp://ftp.kernel.org/pub/linux/utils/util-linux-ng/.

25 September 1995 MCOOKIE(1)

grn

•May 7, 2011 • Leave a Comment



SYNOPSIS
grn [ -Cv ] [ -Tdev ] [ -Mdir ] [ -Fdir ] [ file... ]

It is possible to have whitespace between a command line option and its
parameter.

DESCRIPTION
grn is a preprocessor for including gremlin pictures in groff input.
grn writes to standard output, processing only input lines between two
that start with .GS and .GE. Those lines must contain grn commands
(see below). These commands request a gremlin file, and the picture in
that file is converted and placed in the troff input stream. The .GS
request may be followed by a C, L, or R to center, left, or right jus-
tify the whole gremlin picture (default justification is center). If
no file is mentioned, the standard input is read. At the end of the
picture, the position on the page is the bottom of the gremlin picture.
If the grn entry is ended with .GF instead of .GE, the position is left
at the top of the picture.

Please note that currently only the -me macro package has support for
.GS, .GE, and .GF.

The following command-line options are understood:

-Tdev Prepare output for printer dev. The default device is ps. See
groff(1) for acceptable devices.

-Mdir Prepend dir to the default search path for gremlin files. The
default path is (in that order) the current directory, the home
directory, /usr/lib/groff/site-tmac, /usr/share/groff/site-tmac,
and /usr/share/groff/1.18.1/tmac.

-Fdir Search dir for subdirectories devname (name is the name of the
device) for the DESC file before the default font directories
/usr/share/groff/site-font, /usr/share/groff/1.18.1/font, and
/usr/lib/font.

-C Recognize .GS and .GE (resp. .GF) even when followed by a char-
acter other than space or newline.

-v Print the version number.

GRN COMMANDS
Each input line between .GS and .GE may have one grn command. Commands
consist of one or two strings separated by white space, the first
string being the command and the second its operand. Commands may be
upper or lower case and abbreviated down to one character.

Commands that affect a picture’s environment (those listed before
default, see below) are only in effect for the current picture: The
environment is reinitialized to the defaults at the start of the next
picture. The commands are as follows:

l f
stipple f
Set the stipple font to troff’s stipple font f (name or number).
The command stipple may be abbreviated down as far as `st’ (to
avoid confusion with special). There is no default for stipples
(unless one is set by the default command), and it is invalid to
include a gremlin picture with polygons without specifying a
stipple font.

x N
scale N
Magnify the picture (in addition to any default magnification)
by N, a floating point number larger than zero. The command
scale may be abbreviated down to `sc’.

narrow N
medium N
thick N
Set the thickness of gremlin’s narrow (resp. medium and thick)
lines to N times 0.15pt (this value can be changed at compile
time). The default is 1.0 (resp. 3.0 and 5.0), which corre-
sponds to 0.15pt (resp. 0.45pt and 0.75pt). A thickness value
of zero selects the smallest available line thickness. Negative
values cause the line thickness to be proportional to the cur-
rent point size.

pointscale <off/on>
Scale text to match the picture. Gremlin text is usually
printed in the point size specified with the commands
1, 2, 3, or 4 regardless of any scaling factors in the picture.
Setting pointscale will cause the point sizes to scale with the
picture (within troff’s limitations, of course). An operand of
anything but off will turn text scaling on.

default
Reset the picture environment defaults to the settings in the
current picture. This is meant to be used as a global parameter
setting mechanism at the beginning of the troff input file, but
can be used at any time to reset the default settings.

width N
Forces the picture to be N inches wide. This overrides any
scaling factors present in the same picture. `width 0′ is
ignored.

height N
Forces picture to be N inches high, overriding other scaling
factors. If both `width’ and `height’ are specified the tighter
constraint will determine the scale of the picture. Height and
width commands are not saved with a default command. They will,
however, affect point size scaling if that option is set.

at the beginning of a line). Thus, it is possible to have equations
within a gremlin figure by including in the gremlin file eqn expres-
sions enclosed by previously defined delimiters (e.g. $$).

When using grn along with other preprocessors, it is best to run tbl
before grn, pic, and/or ideal to avoid overworking tbl. Eqn should
always be run last.

A picture is considered an entity, but that doesn’t stop troff from
trying to break it up if it falls off the end of a page. Placing the
picture between `keeps’ in -me macros will ensure proper placement.

grn uses troff’s number registers g1 through g9 and sets registers g1
and g2 to the width and height of the gremlin figure (in device units)
before entering the .GS request (this is for those who want to rewrite
these macros).

GREMLIN FILE FORMAT
There exist two distinct gremlin file formats, the original format from
the AED graphic terminal version, and the SUN or X11 version. An
extension to the SUN/X11 version allowing reference points with nega-
tive coordinates is not compatible with the AED version. As long as a
gremlin file does not contain negative coordinates, either format will
be read correctly by either version of gremlin or grn. The other dif-
ference to the SUN/X11 format is the use of names for picture objects
(e.g., POLYGON, CURVE) instead of numbers. Files representing the same
picture are shown in Table 1 in each format.

sungremlinfile gremlinfile
0 240.00 128.00 0 240.00 128.00
CENTCENT 2
240.00 128.00 240.00 128.00
185.00 120.00 185.00 120.00
240.00 120.00 240.00 120.00
296.00 120.00 296.00 120.00
* -1.00 -1.00
2 3 2 3
10 A Triangle 10 A Triangle
POLYGON 6
224.00 416.00 224.00 416.00
96.00 160.00 96.00 160.00
384.00 160.00 384.00 160.00
* -1.00 -1.00
5 1 5 1
0 0
-1 -1

Table 1. File examples

o The first line of each gremlin file contains either the string
o The rest of the file consists of zero or more element specifica-
tions. After the last element specification is a line contain-
ing the string “-1”.

o Lines longer than 127 characters are chopped to this limit.

ELEMENT SPECIFICATIONS
o The first line of each element contains a single decimal number
giving the type of the element (AED version) or its ASCII name
(SUN/X11 version). See Table 2.

gremlin File Format – Object Type Specification

AED Number SUN/X11 Name Description
0 BOTLEFT bottom-left-justified text
1 BOTRIGHT bottom-right-justified text
2 CENTCENT center-justified text
3 VECTOR vector
4 ARC arc
5 CURVE curve
6 POLYGON polygon
7 BSPLINE b-spline
8 BEZIER Bezier
10 TOPLEFT top-left-justified text
11 TOPCENT top-center-justified text
12 TOPRIGHT top-right-justified text
13 CENTLEFT left-center-justified text
14 CENTRIGHT right-center-justified text
15 BOTCENT bottom-center-justified text

Table 2.
Type Specifications in gremlin Files

o After the object type comes a variable number of lines, each
specifying a point used to display the element. Each line con-
tains an x-coordinate and a y-coordinate in floating point for-
mat, separated by spaces. The list of points is terminated by a
line containing the string “-1.0 -1.0” (AED version) or a sin-
gle asterisk, “*” (SUN/X11 version).

o After the points comes a line containing two decimal values,
giving the brush and size for the element. The brush determines
the style in which things are drawn. For vectors, arcs, and
curves there are six legal brush values:

1 – thin dotted lines
2 – thin dot-dashed lines
3 – thick solid lines
4 – thin dashed lines

is really just a starting font: The text string can contain for-
matting sequences like “\fI” or “\d” which may change the
font (as well as do many other things). For text, the size
field is a decimal value between 1 and 4. It selects the size
of the font in which the text will be drawn. For polygons, this
size field is interpreted as a stipple number to fill the poly-
gon with. The number is used to index into a stipple font at
print time.

o The last line of each element contains a decimal number and a
string of characters, separated by a single space. The number
is a count of the number of characters in the string. This
information is only used for text elements, and contains the
text string. There can be spaces inside the text. For arcs,
curves, and vectors, this line of the element contains the
string “0”.

NOTES ON COORDINATES
gremlin was designed for AEDs, and its coordinates reflect the AED
coordinate space. For vertical pictures, x-values range 116 to 511,
and y-values from 0 to 483. For horizontal pictures, x-values range
from 0 to 511 and y-values range from 0 to 367. Although you needn’t
absolutely stick to this range, you’ll get best results if you at least
stay in this vicinity. Also, point lists are terminated by a point of
(-1, -1), so you shouldn’t ever use negative coordinates. gremlin
writes out coordinates using format “%f1.2”; it’s probably a good
idea to use the same format if you want to modify the grn code.

NOTES ON SUN/X11 COORDINATES
There is no longer a restriction on the range of coordinates used to
create objects in the SUN/X11 version of gremlin. However, files with
negative coordinates will cause problems if displayed on the AED.

FILES
/usr/share/groff/1.18.1/font/devname/DESC
Device description file for device name.

SEE ALSO
gremlin(1), groff(1), pic(1), ideal(1)

HISTORY
David Slattengren and Barry Roitblat wrote the original Berkeley grn.

Daniel Senderowicz and Werner Lemberg modified it for groff.

Groff Version 1.18.1 05 March 2005 GRN(1)

 
Follow

Get every new post delivered to your Inbox.