aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation')
-rw-r--r--Documentation/00-INDEX2
-rw-r--r--Documentation/BK-usage/00-INDEX51
-rw-r--r--Documentation/BK-usage/bk-kernel-howto.txt283
-rwxr-xr-xDocumentation/BK-usage/bk-make-sum34
-rwxr-xr-xDocumentation/BK-usage/bksend36
-rwxr-xr-xDocumentation/BK-usage/bz64wrap41
-rwxr-xr-xDocumentation/BK-usage/cpcset36
-rwxr-xr-xDocumentation/BK-usage/cset-to-linus49
-rwxr-xr-xDocumentation/BK-usage/csets-to-patches44
-rwxr-xr-xDocumentation/BK-usage/gcapatch8
-rwxr-xr-xDocumentation/BK-usage/unbz64wrap25
11 files changed, 0 insertions, 609 deletions
diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
index 72dc90f8f4a7..8de8a01a2474 100644
--- a/Documentation/00-INDEX
+++ b/Documentation/00-INDEX
@@ -12,8 +12,6 @@ Following translations are available on the WWW:
12 12
1300-INDEX 1300-INDEX
14 - this file. 14 - this file.
15BK-usage/
16 - directory with info on BitKeeper.
17BUG-HUNTING 15BUG-HUNTING
18 - brute force method of doing binary search of patches to find bug. 16 - brute force method of doing binary search of patches to find bug.
19Changes 17Changes
diff --git a/Documentation/BK-usage/00-INDEX b/Documentation/BK-usage/00-INDEX
deleted file mode 100644
index 82768784ea52..000000000000
--- a/Documentation/BK-usage/00-INDEX
+++ /dev/null
@@ -1,51 +0,0 @@
1bk-kernel-howto.txt: Description of kernel workflow under BitKeeper
2
3bk-make-sum: Create summary of changesets in one repository and not
4another, typically in preparation to be sent to an upstream maintainer.
5Typical usage:
6 cd my-updated-repo
7 bk-make-sum ~/repo/original-repo
8 mv /tmp/linus.txt ../original-repo.txt
9
10bksend: Create readable text output containing summary of changes, GNU
11patch of the changes, and BK metadata of changes (as needed for proper
12importing into BitKeeper by an upstream maintainer). This output is
13suitable for emailing BitKeeper changes. The recipient of this output
14may pipe it directly to 'bk receive'.
15
16bz64wrap: helper script. Uncompressed input is piped to this script,
17which compresses its input, and then outputs the uu-/base64-encoded
18version of the compressed input.
19
20cpcset: Copy changeset between unrelated repositories.
21Attempts to preserve changeset user, user address, description, in
22addition to the changeset (the patch) itself.
23Typical usage:
24 cd my-updated-repo
25 bk changes # looking for a changeset...
26 cpcset 1.1511 . ../another-repo
27
28csets-to-patches: Produces a delta of two BK repositories, in the form
29of individual files, each containing a single cset as a GNU patch.
30Output is several files, each with the filename "/tmp/rev-$REV.patch"
31Typical usage:
32 cd my-updated-repo
33 bk changes -L ~/repo/original-repo 2>&1 | \
34 perl csets-to-patches
35
36cset-to-linus: Produces a delta of two BK repositories, in the form of
37changeset descriptions, with 'diffstat' output created for each
38individual changset.
39Typical usage:
40 cd my-updated-repo
41 bk changes -L ~/repo/original-repo 2>&1 | \
42 perl cset-to-linus > summary.txt
43
44gcapatch: Generates patch containing changes in local repository.
45Typical usage:
46 cd my-updated-repo
47 gcapatch > foo.patch
48
49unbz64wrap: Reverse an encoded, compressed data stream created by
50bz64wrap into an uncompressed, typically text/plain output.
51
diff --git a/Documentation/BK-usage/bk-kernel-howto.txt b/Documentation/BK-usage/bk-kernel-howto.txt
deleted file mode 100644
index b7b9075d2910..000000000000
--- a/Documentation/BK-usage/bk-kernel-howto.txt
+++ /dev/null
@@ -1,283 +0,0 @@
1
2 Doing the BK Thing, Penguin-Style
3
4
5
6
7This set of notes is intended mainly for kernel developers, occasional
8or full-time, but sysadmins and power users may find parts of it useful
9as well. It assumes at least a basic familiarity with CVS, both at a
10user level (use on the cmd line) and at a higher level (client-server model).
11Due to the author's background, an operation may be described in terms
12of CVS, or in terms of how that operation differs from CVS.
13
14This is -not- intended to be BitKeeper documentation. Always run
15"bk help <command>" or in X "bk helptool <command>" for reference
16documentation.
17
18
19BitKeeper Concepts
20------------------
21
22In the true nature of the Internet itself, BitKeeper is a distributed
23system. When applied to revision control, this means doing away with
24client-server, and changing to a parent-child model... essentially
25peer-to-peer. On the developer's end, this also represents a
26fundamental disruption in the standard workflow of changes, commits,
27and merges. You will need to take a few minutes to think about
28how to best work under BitKeeper, and re-optimize things a bit.
29In some sense it is a bit radical, because it might described as
30tossing changes out into a maelstrom and having them magically
31land at the right destination... but I'm getting ahead of myself.
32
33Let's start with this progression:
34Each BitKeeper source tree on disk is a repository unto itself.
35Each repository has a parent (except the root/original, of course).
36Each repository contains a set of a changesets ("csets").
37Each cset is one or more changed files, bundled together.
38
39Each tree is a repository, so all changes are checked into the local
40tree. When a change is checked in, all modified files are grouped
41into a logical unit, the changeset. Internally, BK links these
42changesets in a tree, representing various converging and diverging
43lines of development. These changesets are the bread and butter of
44the BK system.
45
46After the concept of changesets, the next thing you need to get used
47to is having multiple copies of source trees lying around. This -really-
48takes some getting used to, for some people. Separate source trees
49are the means in BitKeeper by which you delineate parallel lines
50of development, both minor and major. What would be branches in
51CVS become separate source trees, or "clones" in BitKeeper [heh,
52or Star Wars] terminology.
53
54Clones and changesets are the tools from which most of the power of
55BitKeeper is derived. As mentioned earlier, each clone has a parent,
56the tree used as the source when the new clone was created. In a
57CVS-like setup, the parent would be a remote server on the Internet,
58and the child is your local clone of that tree.
59
60Once you have established a common baseline between two source trees --
61a common parent -- then you can merge changesets between those two
62trees with ease. Merging changes into a tree is called a "pull", and
63is analagous to 'cvs update'. A pull downloads all the changesets in
64the remote tree you do not have, and merges them. Sending changes in
65one tree to another tree is called a "push". Push sends all changes
66in the local tree the remote does not yet have, and merges them.
67
68From these concepts come some initial command examples:
69
701) bk clone -q http://linux.bkbits.net/linux-2.5 linus-2.5
71Download a 2.5 stock kernel tree, naming it "linus-2.5" in the local dir.
72The "-q" disables listing every single file as it is downloaded.
73
742) bk clone -ql linus-2.5 alpha-2.5
75Create a separate source tree for the Alpha AXP architecture.
76The "-l" uses hard links instead of copying data, since both trees are
77on the local disk. You can also replace the above with "bk lclone -q ..."
78
79You only clone a tree -once-. After cloning the tree lives a long time
80on disk, being updating by pushes and pulls.
81
823) cd alpha-2.5 ; bk pull http://gkernel.bkbits.net/alpha-2.5
83Download changes in "alpha-2.5" repository which are not present
84in the local repository, and merge them into the source tree.
85
864) bk -r co -q
87Because every tree is a repository, files must be checked out before
88they will be in their standard places in the source tree.
89
905) bk vi fs/inode.c # example change...
91 bk citool # checkin, using X tool
92 bk push bk://gkernel@bkbits.net/alpha-2.5 # upload change
93Typical example of a BK sequence that would replace the analagous CVS
94situation,
95 vi fs/inode.c
96 cvs commit
97
98As this is just supposed to be a quick BK intro, for more in-depth
99tutorials, live working demos, and docs, see http://www.bitkeeper.com/
100
101
102
103BK and Kernel Development Workflow
104----------------------------------
105Currently the latest 2.5 tree is available via "bk clone $URL"
106and "bk pull $URL" at http://linux.bkbits.net/linux-2.5
107This should change in a few weeks to a kernel.org URL.
108
109
110A big part of using BitKeeper is organizing the various trees you have
111on your local disk, and organizing the flow of changes among those
112trees, and remote trees. If one were to graph the relationships between
113a desired BK setup, you are likely to see a few-many-few graph, like
114this:
115
116 linux-2.5
117 |
118 merge-to-linus-2.5
119 / | |
120 / | |
121 vm-hacks bugfixes filesys personal-hacks
122 \ | | /
123 \ | | /
124 \ | | /
125 testing-and-validation
126
127Since a "bk push" sends all changes not in the target tree, and
128since a "bk pull" receives all changes not in the source tree, you want
129to make sure you are only pushing specific changes to the desired tree,
130not all changes from "peer parent" trees. For example, pushing a change
131from the testing-and-validation tree would probably be a bad idea,
132because it will push all changes from vm-hacks, bugfixes, filesys, and
133personal-hacks trees into the target tree.
134
135One would typically work on only one "theme" at a time, either
136vm-hacks or bugfixes or filesys, keeping those changes isolated in
137their own tree during development, and only merge the isolated with
138other changes when going upstream (to Linus or other maintainers) or
139downstream (to your "union" trees, like testing-and-validation above).
140
141It should be noted that some of this separation is not just recommended
142practice, it's actually [for now] -enforced- by BitKeeper. BitKeeper
143requires that changesets maintain a certain order, which is the reason
144that "bk push" sends all local changesets the remote doesn't have. This
145separation may look like a lot of wasted disk space at first, but it
146helps when two unrelated changes may "pollute" the same area of code, or
147don't follow the same pace of development, or any other of the standard
148reasons why one creates a development branch.
149
150Small development branches (clones) will appear and disappear:
151
152 -------- A --------- B --------- C --------- D -------
153 \ /
154 -----short-term devel branch-----
155
156While long-term branches will parallel a tree (or trees), with period
157merge points. In this first example, we pull from a tree (pulls,
158"\") periodically, such as what occurs when tracking changes in a
159vendor tree, never pushing changes back up the line:
160
161 -------- A --------- B --------- C --------- D -------
162 \ \ \
163 ----long-term devel branch-----------------
164
165And then a more common case in Linux kernel development, a long term
166branch with periodic merges back into the tree (pushes, "/"):
167
168 -------- A --------- B --------- C --------- D -------
169 \ \ / \
170 ----long-term devel branch-----------------
171
172
173
174
175
176Submitting Changes to Linus
177---------------------------
178There's a bit of an art, or style, of submitting changes to Linus.
179Since Linus's tree is now (you might say) fully integrated into the
180distributed BitKeeper system, there are several prerequisites to
181properly submitting a BitKeeper change. All these prereq's are just
182general cleanliness of BK usage, so as people become experts at BK, feel
183free to optimize this process further (assuming Linus agrees, of
184course).
185
186
187
1880) Make sure your tree was originally cloned from the linux-2.5 tree
189created by Linus. If your tree does not have this as its ancestor, it
190is impossible to reliably exchange changesets.
191
192
193
1941) Pay attention to your commit text. The commit message that
195accompanies each changeset you submit will live on forever in history,
196and is used by Linus to accurately summarize the changes in each
197pre-patch. Remember that there is no context, so
198 "fix for new scheduler changes"
199would be too vague, but
200 "fix mips64 arch for new scheduler switch_to(), TIF_xxx semantics"
201would be much better.
202
203You can and should use the command "bk comment -C<rev>" to update the
204commit text, and improve it after the fact. This is very useful for
205development: poor, quick descriptions during development, which get
206cleaned up using "bk comment" before issuing the "bk push" to submit the
207changes.
208
209
210
2112) Include an Internet-available URL for Linus to pull from, such as
212
213 Pull from: http://gkernel.bkbits.net/net-drivers-2.5
214
215
216
2173) Include a summary and "diffstat -p1" of each changeset that will be
218downloaded, when Linus issues a "bk pull". The author auto-generates
219these summaries using "bk changes -L <parent>", to obtain a listing
220of all the pending-to-send changesets, and their commit messages.
221
222It is important to show Linus what he will be downloading when he issues
223a "bk pull", to reduce the time required to sift the changes once they
224are downloaded to Linus's local machine.
225
226IMPORTANT NOTE: One of the features of BK is that your repository does
227not have to be up to date, in order for Linus to receive your changes.
228It is considered a courtesy to keep your repository fairly recent, to
229lessen any potential merge work Linus may need to do.
230
231
2324) Split up your changes. Each maintainer<->Linus situation is likely
233to be slightly different here, so take this just as general advice. The
234author splits up changes according to "themes" when merging with Linus.
235Simultaneous pushes from local development go to special trees which
236exist solely to house changes "queued" for Linus. Example of the trees:
237
238 net-drivers-2.5 -- on-going net driver maintenance
239 vm-2.5 -- VM-related changes
240 fs-2.5 -- filesystem-related changes
241
242Linus then has much more freedom for pulling changes. He could (for
243example) issue a "bk pull" on vm-2.5 and fs-2.5 trees, to merge their
244changes, but hold off net-drivers-2.5 because of a change that needs
245more discussion.
246
247Other maintainers may find that a single linus-pull-from tree is
248adequate for passing BK changesets to him.
249
250
251
252Frequently Answered Questions
253-----------------------------
2541) How do I change the e-mail address shown in the changelog?
255A. When you run "bk citool" or "bk commit", set environment
256 variables BK_USER and BK_HOST to the desired username
257 and host/domain name.
258
259
2602) How do I use tags / get a diff between two kernel versions?
261A. Pass the tags Linus uses to 'bk export'.
262
263ChangeSets are in a forward-progressing order, so it's pretty easy
264to get a snapshot starting and ending at any two points in time.
265Linus puts tags on each release and pre-release, so you could use
266these two examples:
267
268 bk export -tpatch -hdu -rv2.5.4,v2.5.5 | less
269 # creates patch-2.5.5 essentially
270 bk export -tpatch -du -rv2.5.5-pre1,v2.5.5 | less
271 # changes from pre1 to final
272
273A tag is just an alias for a specific changeset... and since changesets
274are ordered, a tag is thus a marker for a specific point in time (or
275specific state of the tree).
276
277
2783) Is there an easy way to generate One Big Patch versus mainline,
279 for my long-lived kernel branch?
280A. Yes. This requires BK 3.x, though.
281
282 bk export -tpatch -r`bk repogca bk://linux.bkbits.net/linux-2.5`,+
283
diff --git a/Documentation/BK-usage/bk-make-sum b/Documentation/BK-usage/bk-make-sum
deleted file mode 100755
index 58ca46a0fcc6..000000000000
--- a/Documentation/BK-usage/bk-make-sum
+++ /dev/null
@@ -1,34 +0,0 @@
1#!/bin/sh -e
2# DIR=$HOME/BK/axp-2.5
3# cd $DIR
4
5LINUS_REPO=$1
6DIRBASE=`basename $PWD`
7
8{
9cat <<EOT
10Please do a
11
12 bk pull bk://gkernel.bkbits.net/$DIRBASE
13
14This will update the following files:
15
16EOT
17
18bk export -tpatch -hdu -r`bk repogca $LINUS_REPO`,+ | diffstat -p1 2>/dev/null
19
20cat <<EOT
21
22through these ChangeSets:
23
24EOT
25
26bk changes -L -d'$unless(:MERGE:){ChangeSet|:CSETREV:\n}' $LINUS_REPO |
27bk -R prs -h -d'$unless(:MERGE:){<:P:@:HOST:> (:D: :I:)\n$each(:C:){ (:C:)\n}\n}' -
28
29} > /tmp/linus.txt
30
31cat <<EOT
32Mail text in /tmp/linus.txt; please check and send using your favourite
33mailer.
34EOT
diff --git a/Documentation/BK-usage/bksend b/Documentation/BK-usage/bksend
deleted file mode 100755
index 836ca943694f..000000000000
--- a/Documentation/BK-usage/bksend
+++ /dev/null
@@ -1,36 +0,0 @@
1#!/bin/sh
2# A script to format BK changeset output in a manner that is easy to read.
3# Andreas Dilger <adilger@turbolabs.com> 13/02/2002
4#
5# Add diffstat output after Changelog <adilger@turbolabs.com> 21/02/2002
6
7PROG=bksend
8
9usage() {
10 echo "usage: $PROG -r<rev>"
11 echo -e "\twhere <rev> is of the form '1.23', '1.23..', '1.23..1.27',"
12 echo -e "\tor '+' to indicate the most recent revision"
13
14 exit 1
15}
16
17case $1 in
18-r) REV=$2; shift ;;
19-r*) REV=`echo $1 | sed 's/^-r//'` ;;
20*) echo "$PROG: no revision given, you probably don't want that";;
21esac
22
23[ -z "$REV" ] && usage
24
25echo "You can import this changeset into BK by piping this whole message to:"
26echo "'| bk receive [path to repository]' or apply the patch as usual."
27
28SEP="\n===================================================================\n\n"
29echo -e $SEP
30env PAGER=/bin/cat bk changes -r$REV
31echo
32bk export -tpatch -du -h -r$REV | diffstat
33echo; echo
34bk export -tpatch -du -h -r$REV
35echo -e $SEP
36bk send -wgzip_uu -r$REV -
diff --git a/Documentation/BK-usage/bz64wrap b/Documentation/BK-usage/bz64wrap
deleted file mode 100755
index be780876849f..000000000000
--- a/Documentation/BK-usage/bz64wrap
+++ /dev/null
@@ -1,41 +0,0 @@
1#!/bin/sh
2
3# bz64wrap - the sending side of a bzip2 | base64 stream
4# Andreas Dilger <adilger@clusterfs.com> Jan 2002
5
6
7PATH=$PATH:/usr/bin:/usr/local/bin:/usr/freeware/bin
8
9# A program to generate base64 encoding on stdout
10BASE64_ENCODE="uuencode -m /dev/stdout"
11BASE64_BEGIN=
12BASE64_END=
13
14BZIP=NO
15BASE64=NO
16
17# Test if we have the bzip program installed
18bzip2 -c /dev/null > /dev/null 2>&1 && BZIP=YES
19
20# Test if uuencode can handle the -m (MIME) encoding option
21$BASE64_ENCODE < /dev/null > /dev/null 2>&1 && BASE64=YES
22
23if [ $BASE64 = NO ]; then
24 BASE64_ENCODE=mimencode
25 BASE64_BEGIN="begin-base64 644 -"
26 BASE64_END="===="
27
28 $BASE64_ENCODE < /dev/null > /dev/null 2>&1 && BASE64=YES
29fi
30
31if [ $BZIP = NO -o $BASE64 = NO ]; then
32 echo "$0: can't use bz64 encoding: bzip2=$BZIP, $BASE64_ENCODE=$BASE64"
33 exit 1
34fi
35
36# Sadly, mimencode does not appear to have good "begin" and "end" markers
37# like uuencode does, and it is picky about getting the right start/end of
38# the base64 stream, so we handle this internally.
39echo "$BASE64_BEGIN"
40bzip2 -9 | $BASE64_ENCODE
41echo "$BASE64_END"
diff --git a/Documentation/BK-usage/cpcset b/Documentation/BK-usage/cpcset
deleted file mode 100755
index b8faca97dab9..000000000000
--- a/Documentation/BK-usage/cpcset
+++ /dev/null
@@ -1,36 +0,0 @@
1#!/bin/sh
2#
3# Purpose: Copy changeset patch and description from one
4# repository to another, unrelated one.
5#
6# usage: cpcset [revision] [from-repository] [to-repository]
7#
8
9REV=$1
10FROM=$2
11TO=$3
12TMPF=/tmp/cpcset.$$
13
14rm -f $TMPF*
15
16CWD_SAVE=`pwd`
17cd $FROM
18bk changes -r$REV | \
19 grep -v '^ChangeSet' | \
20 sed -e 's/^ //g' > $TMPF.log
21
22USERHOST=`bk changes -r$REV | grep '^ChangeSet' | awk '{print $4}'`
23export BK_USER=`echo $USERHOST | awk '-F@' '{print $1}'`
24export BK_HOST=`echo $USERHOST | awk '-F@' '{print $2}'`
25
26bk export -tpatch -hdu -r$REV > $TMPF.patch && \
27cd $CWD_SAVE && \
28cd $TO && \
29bk import -tpatch -CFR -y"`cat $TMPF.log`" $TMPF.patch . && \
30bk commit -y"`cat $TMPF.log`"
31
32rm -f $TMPF*
33
34echo changeset $REV copied.
35echo ""
36
diff --git a/Documentation/BK-usage/cset-to-linus b/Documentation/BK-usage/cset-to-linus
deleted file mode 100755
index d28a96f8c618..000000000000
--- a/Documentation/BK-usage/cset-to-linus
+++ /dev/null
@@ -1,49 +0,0 @@
1#!/usr/bin/perl -w
2
3use strict;
4
5my ($lhs, $rev, $tmp, $rhs, $s);
6my @cset_text = ();
7my @pipe_text = ();
8my $have_cset = 0;
9
10while (<>) {
11 next if /^---/;
12
13 if (($lhs, $tmp, $rhs) = (/^(ChangeSet\@)([^,]+)(, .*)$/)) {
14 &cset_rev if ($have_cset);
15
16 $rev = $tmp;
17 $have_cset = 1;
18
19 push(@cset_text, $_);
20 }
21
22 elsif ($have_cset) {
23 push(@cset_text, $_);
24 }
25}
26&cset_rev if ($have_cset);
27exit(0);
28
29
30sub cset_rev {
31 my $empty_cset = 0;
32
33 open PIPE, "bk export -tpatch -hdu -r $rev | diffstat -p1 2>/dev/null |" or die;
34 while ($s = <PIPE>) {
35 $empty_cset = 1 if ($s =~ /0 files changed/);
36 push(@pipe_text, $s);
37 }
38 close(PIPE);
39
40 if (! $empty_cset) {
41 print @cset_text;
42 print @pipe_text;
43 print "\n\n";
44 }
45
46 @pipe_text = ();
47 @cset_text = ();
48}
49
diff --git a/Documentation/BK-usage/csets-to-patches b/Documentation/BK-usage/csets-to-patches
deleted file mode 100755
index e2b81c35883f..000000000000
--- a/Documentation/BK-usage/csets-to-patches
+++ /dev/null
@@ -1,44 +0,0 @@
1#!/usr/bin/perl -w
2
3use strict;
4
5my ($lhs, $rev, $tmp, $rhs, $s);
6my @cset_text = ();
7my @pipe_text = ();
8my $have_cset = 0;
9
10while (<>) {
11 next if /^---/;
12
13 if (($lhs, $tmp, $rhs) = (/^(ChangeSet\@)([^,]+)(, .*)$/)) {
14 &cset_rev if ($have_cset);
15
16 $rev = $tmp;
17 $have_cset = 1;
18
19 push(@cset_text, $_);
20 }
21
22 elsif ($have_cset) {
23 push(@cset_text, $_);
24 }
25}
26&cset_rev if ($have_cset);
27exit(0);
28
29
30sub cset_rev {
31 my $empty_cset = 0;
32
33 system("bk export -tpatch -du -r $rev > /tmp/rev-$rev.patch");
34
35 if (! $empty_cset) {
36 print @cset_text;
37 print @pipe_text;
38 print "\n\n";
39 }
40
41 @pipe_text = ();
42 @cset_text = ();
43}
44
diff --git a/Documentation/BK-usage/gcapatch b/Documentation/BK-usage/gcapatch
deleted file mode 100755
index aaeb17dc7c7f..000000000000
--- a/Documentation/BK-usage/gcapatch
+++ /dev/null
@@ -1,8 +0,0 @@
1#!/bin/sh
2#
3# Purpose: Generate GNU diff of local changes versus canonical top-of-tree
4#
5# Usage: gcapatch > foo.patch
6#
7
8bk export -tpatch -hdu -r`bk repogca bk://linux.bkbits.net/linux-2.5`,+
diff --git a/Documentation/BK-usage/unbz64wrap b/Documentation/BK-usage/unbz64wrap
deleted file mode 100755
index 4fc3e73e9a81..000000000000
--- a/Documentation/BK-usage/unbz64wrap
+++ /dev/null
@@ -1,25 +0,0 @@
1#!/bin/sh
2
3# unbz64wrap - the receiving side of a bzip2 | base64 stream
4# Andreas Dilger <adilger@clusterfs.com> Jan 2002
5
6# Sadly, mimencode does not appear to have good "begin" and "end" markers
7# like uuencode does, and it is picky about getting the right start/end of
8# the base64 stream, so we handle this explicitly here.
9
10PATH=$PATH:/usr/bin:/usr/local/bin:/usr/freeware/bin
11
12if mimencode -u < /dev/null > /dev/null 2>&1 ; then
13 SHOW=
14 while read LINE; do
15 case $LINE in
16 begin-base64*) SHOW=YES ;;
17 ====) SHOW= ;;
18 *) [ "$SHOW" ] && echo "$LINE" ;;
19 esac
20 done | mimencode -u | bunzip2
21 exit $?
22else
23 cat - | uudecode -o /dev/stdout | bunzip2
24 exit $?
25fi