Moved bin/ directory out of apps/.
git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@11909 a95241bf-73f2-0310-859d-f6bbb57e9c96
This commit is contained in:
Axel Dörfler
@@ -0,0 +1,65 @@
|
||||
Mon Dec 4 16:51:38 1995 Ulrich Drepper <drepper@myware>
|
||||
|
||||
* unshar.1, shar.1: Update for 4.2 by Jan Djarv.
|
||||
|
||||
Thu Nov 30 23:16:17 1995 Ulrich Drepper <drepper@myware>
|
||||
|
||||
* remsync.texi: According to D.E.Knuth and Karl Berry `nonzero' is
|
||||
preferable to `non-zero'.
|
||||
|
||||
Sat Nov 25 02:45:11 1995 Ulrich Drepper <drepper@myware>
|
||||
|
||||
* Makefile.in (version.texi): Also depend on ../configure.in.
|
||||
|
||||
* unshar.1, sharutils.texi:
|
||||
Correct double `in`. Reported by Nelson Beebe.
|
||||
|
||||
* remsync.texi: Correct double `the`. Reported by Nelson Beebe.
|
||||
|
||||
Sun Nov 5 13:33:39 1995 Ulrich Drepper <drepper@myware>
|
||||
|
||||
* Makefile.in (dist): Suppress error message when ln failed.
|
||||
|
||||
Sat Oct 28 01:50:37 1995 Ulrich Drepper <drepper@myware>
|
||||
|
||||
* sharutils.texi: Document -f option of unshar.
|
||||
|
||||
Tue Sep 26 14:25:20 1995 Ulrich Drepper <drepper@myware>
|
||||
|
||||
* uuencode.1: Typo.
|
||||
|
||||
* uuencode.1: Document P1003.2b/D11 changes.
|
||||
|
||||
Sun Sep 24 16:28:34 1995 Ulrich Drepper <drepper@myware>
|
||||
|
||||
* sharutils.texi: Add some comments about transmission checks.
|
||||
|
||||
Wed Sep 20 23:51:03 1995 Ulrich Drepper <drepper@myware>
|
||||
|
||||
* Makefile.in (transform):
|
||||
New variable. Gets its value from configure.
|
||||
(man1dir, man1ext, man5dir, man5ext): New variables for man page
|
||||
installation.
|
||||
(install-man): Correct some bugs.
|
||||
|
||||
* Makefile.in (MAN1PAGES, MAN5PAGES): Let configure set the values.
|
||||
(install-man, uninstall-man): The for $(MAN5PAGES) to be empty; some
|
||||
shells don't like empty for argument lists.
|
||||
|
||||
* unshar.1, shar.1: Changes for 4.1.6 by Jan Djarv.
|
||||
|
||||
Tue Aug 15 16:58:58 1995 Ulrich Drepper <drepper@myware>
|
||||
|
||||
* Makefile.in (dist): Remove `copying instead' message.
|
||||
|
||||
Thu Aug 10 22:34:12 1995 Ulrich Drepper <drepper@myware>
|
||||
|
||||
* Makefile.in (DISTFILES):
|
||||
Was two times sharutils.info and remsync.info. Change one of
|
||||
them to sharutils.texi and remsync.texi.
|
||||
Reported by Franc,ois Pinard.
|
||||
|
||||
Thu Aug 3 00:27:20 1995 Ulrich Drepper <drepper@myware>
|
||||
|
||||
* Makefile.in: Initial revision.
|
||||
|
||||
@@ -0,0 +1,156 @@
|
||||
# Generated automatically from Makefile.in by configure.
|
||||
# Makefile for GNU Shar utility package documentation.
|
||||
# Copyright (C) 1995 Free Software Foundation, Inc.
|
||||
#
|
||||
# This program is free software; you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation; either version 2, or (at your option)
|
||||
# any later version.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program; if not, write to the Free Software
|
||||
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
||||
|
||||
PACKAGE = sharutils
|
||||
VERSION = 4.2.1
|
||||
|
||||
SHELL = /bin/sh
|
||||
srcdir = .
|
||||
top_srcdir = ..
|
||||
|
||||
transform = s,x,x,
|
||||
INSTALL = /bin/install -c
|
||||
INSTALL_DATA = ${INSTALL} -m 644
|
||||
MAKEINFO = makeinfo
|
||||
TEXI2DVI = texi2dvi
|
||||
TOUCH = echo timestamp >
|
||||
|
||||
DISTFILES = ChangeLog Makefile.in mdate-sh sharutils.texi remsync.texi \
|
||||
shar.1 unshar.1 uuencode.1 uuencode.5 \
|
||||
texinfo.tex version.texi sharutils.info remsync.info stamp-vti
|
||||
MAN1PAGES = shar unshar uuencode uudecode
|
||||
MAN5PAGES = uuencode
|
||||
|
||||
prefix = /usr/local
|
||||
infodir = $(prefix)/info
|
||||
mandir = $(prefix)/man
|
||||
man1dir = $(mandir)/man1
|
||||
man1ext = .1
|
||||
man5dir = $(mandir)/man5
|
||||
man5ext = .5
|
||||
subdir = doc
|
||||
|
||||
.SUFFIXES:
|
||||
|
||||
default: all
|
||||
|
||||
all info check: sharutils.info remsync.info
|
||||
|
||||
sharutils.info: sharutils.texi version.texi
|
||||
cd $(srcdir) && $(MAKEINFO) sharutils.texi
|
||||
|
||||
remsync.info: remsync.texi version.texi
|
||||
cd $(srcdir) && $(MAKEINFO) remsync.texi
|
||||
|
||||
dvi: sharutils.dvi remsync.dvi
|
||||
|
||||
sharutils.dvi: sharutils.texi texinfo.tex version.texi
|
||||
$(TEXI2DVI) $(srcdir)/sharutils.texi
|
||||
|
||||
remsync.dvi: remsync.texi texinfo.tex
|
||||
$(TEXI2DVI) $(srcdir)/remsync.texi
|
||||
|
||||
version.texi: stamp-vti
|
||||
stamp-vti: sharutils.texi $(top_srcdir)/configure.in
|
||||
echo "@set EDITION $(VERSION)" > version.tmp
|
||||
echo "@set UPDATED `cd $(srcdir) \
|
||||
&& $(SHELL) mdate-sh sharutils.texi`" >> version.tmp
|
||||
echo "@set VERSION $(VERSION)" >> version.tmp
|
||||
if cmp -s version.tmp version.texi; then \
|
||||
rm -f version.tmp; \
|
||||
else \
|
||||
mv -f version.tmp version.texi; \
|
||||
fi
|
||||
$(TOUCH) $(srcdir)/stamp-vti
|
||||
|
||||
install install-exec install-data: all
|
||||
install: install-exec install-data
|
||||
install-exec:
|
||||
install-data:
|
||||
$(top_srcdir)/mkinstalldirs $(infodir)
|
||||
cd $(srcdir) && \
|
||||
for file in sharutils.info* remsync.info*; do \
|
||||
$(INSTALL_DATA) $$file $(infodir)/$$file; \
|
||||
done
|
||||
|
||||
uninstall:
|
||||
rm -f $(infodir)/sharutils.info* $(infodir)/remsync.info*
|
||||
|
||||
|
||||
# man page installation is kept separate from install. Better think
|
||||
# GNU and switch to Info. The following is for irreductible fellows.
|
||||
|
||||
install-man:
|
||||
$(top_srcdir)/mkinstalldirs $(man1dir)
|
||||
test -z "$(MAN5PAGES)" || $(top_srcdir)/mkinstalldirs $(man5dir)
|
||||
for name in $(MAN1PAGES); do \
|
||||
if test $$name = uudecode; then \
|
||||
rm -f $(man1dir)/`echo uudecode | sed '$(transform)'`$(man1ext); \
|
||||
man1base=`echo $(man1dir) | sed 's@.*/\(.*\)@&1@'`; \
|
||||
echo ".so $$man1base/uuencode$(man1ext)" \
|
||||
> $(man1dir)/`echo uudecode | sed '$(transform)'`$(man1ext); \
|
||||
else \
|
||||
$(INSTALL_DATA) $(srcdir)/$$name.1 \
|
||||
$(man1dir)/`echo $$name | sed '$(transform)'`$(man1ext); \
|
||||
fi; \
|
||||
done
|
||||
test -z "$(MAN5PAGES)" || \
|
||||
for name in $(MAN5PAGES); do \
|
||||
$(INSTALL_DATA) $(srcdir)/$$name.5 \
|
||||
$(man5dir)/`echo $$name | sed '$(transform)'`$(man5ext); \
|
||||
done
|
||||
|
||||
uninstall-man:
|
||||
for name in $(MAN1PAGES); do \
|
||||
rm -f $(man1dir)/`echo $$name | sed '$(transform)'`$(man1ext); \
|
||||
done
|
||||
test -z "$(MAN5PAGES)" || \
|
||||
for name in $(MAN5PAGES); do \
|
||||
rm -f $(man5dir)/`echo $$name | sed '$(transform)'`$(man5ext); \
|
||||
done
|
||||
|
||||
|
||||
TAGS ID:
|
||||
|
||||
mostlyclean:
|
||||
rm -f *.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.log *.pg *.toc *.tp *.vr
|
||||
rm -f *.tmp
|
||||
|
||||
clean: mostlyclean
|
||||
|
||||
distclean: clean
|
||||
rm -f Makefile
|
||||
|
||||
maintainer-clean: distclean
|
||||
@echo "This command is intended only for maintainers to use;"
|
||||
@echo "rebuilding the deleted files may require special tools."
|
||||
rm -f stamp-vti version.texi sharutils.info* remsync.info*
|
||||
|
||||
distdir = ../$(PACKAGE)-$(VERSION)/$(subdir)
|
||||
dist: Makefile $(DISTFILES)
|
||||
for file in $(DISTFILES); do \
|
||||
ln $(srcdir)/$$file $(distdir) 2> /dev/null \
|
||||
|| cp -p $(srcdir)/$$file $(distdir); \
|
||||
done
|
||||
|
||||
Makefile: Makefile.in ../config.status
|
||||
cd .. && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= ./config.status
|
||||
|
||||
# Tell versions [3.59,3.63) of GNU make not to export all variables.
|
||||
# Otherwise a system limit (for SysV at least) may be exceeded.
|
||||
.NOEXPORT:
|
||||
@@ -0,0 +1,156 @@
|
||||
# Makefile for GNU Shar utility package documentation.
|
||||
# Copyright (C) 1995 Free Software Foundation, Inc.
|
||||
#
|
||||
# This program is free software; you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation; either version 2, or (at your option)
|
||||
# any later version.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program; if not, write to the Free Software
|
||||
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
||||
|
||||
PACKAGE = @PACKAGE@
|
||||
VERSION = @VERSION@
|
||||
|
||||
SHELL = /bin/sh
|
||||
srcdir = @srcdir@
|
||||
top_srcdir = @top_srcdir@
|
||||
VPATH = @srcdir@
|
||||
|
||||
transform = @program_transform_name@
|
||||
INSTALL = @INSTALL@
|
||||
INSTALL_DATA = @INSTALL_DATA@
|
||||
MAKEINFO = makeinfo
|
||||
TEXI2DVI = texi2dvi
|
||||
TOUCH = echo timestamp >
|
||||
|
||||
DISTFILES = ChangeLog Makefile.in mdate-sh sharutils.texi remsync.texi \
|
||||
shar.1 unshar.1 uuencode.1 uuencode.5 \
|
||||
texinfo.tex version.texi sharutils.info remsync.info stamp-vti
|
||||
MAN1PAGES = @MAN1PAGES@
|
||||
MAN5PAGES = @MAN5PAGES@
|
||||
|
||||
prefix = @prefix@
|
||||
infodir = $(prefix)/info
|
||||
mandir = $(prefix)/man
|
||||
man1dir = $(mandir)/man1
|
||||
man1ext = .1
|
||||
man5dir = $(mandir)/man5
|
||||
man5ext = .5
|
||||
subdir = doc
|
||||
|
||||
.SUFFIXES:
|
||||
|
||||
default: all
|
||||
|
||||
all info check: sharutils.info remsync.info
|
||||
|
||||
sharutils.info: sharutils.texi version.texi
|
||||
cd $(srcdir) && $(MAKEINFO) sharutils.texi
|
||||
|
||||
remsync.info: remsync.texi version.texi
|
||||
cd $(srcdir) && $(MAKEINFO) remsync.texi
|
||||
|
||||
dvi: sharutils.dvi remsync.dvi
|
||||
|
||||
sharutils.dvi: sharutils.texi texinfo.tex version.texi
|
||||
$(TEXI2DVI) $(srcdir)/sharutils.texi
|
||||
|
||||
remsync.dvi: remsync.texi texinfo.tex
|
||||
$(TEXI2DVI) $(srcdir)/remsync.texi
|
||||
|
||||
version.texi: stamp-vti
|
||||
stamp-vti: sharutils.texi $(top_srcdir)/configure.in
|
||||
echo "@set EDITION $(VERSION)" > version.tmp
|
||||
echo "@set UPDATED `cd $(srcdir) \
|
||||
&& $(SHELL) mdate-sh sharutils.texi`" >> version.tmp
|
||||
echo "@set VERSION $(VERSION)" >> version.tmp
|
||||
if cmp -s version.tmp version.texi; then \
|
||||
rm -f version.tmp; \
|
||||
else \
|
||||
mv -f version.tmp version.texi; \
|
||||
fi
|
||||
$(TOUCH) $(srcdir)/stamp-vti
|
||||
|
||||
install install-exec install-data: all
|
||||
install: install-exec install-data
|
||||
install-exec:
|
||||
install-data:
|
||||
$(top_srcdir)/mkinstalldirs $(infodir)
|
||||
cd $(srcdir) && \
|
||||
for file in sharutils.info* remsync.info*; do \
|
||||
$(INSTALL_DATA) $$file $(infodir)/$$file; \
|
||||
done
|
||||
|
||||
uninstall:
|
||||
rm -f $(infodir)/sharutils.info* $(infodir)/remsync.info*
|
||||
|
||||
|
||||
# man page installation is kept separate from install. Better think
|
||||
# GNU and switch to Info. The following is for irreductible fellows.
|
||||
|
||||
install-man:
|
||||
$(top_srcdir)/mkinstalldirs $(man1dir)
|
||||
test -z "$(MAN5PAGES)" || $(top_srcdir)/mkinstalldirs $(man5dir)
|
||||
for name in $(MAN1PAGES); do \
|
||||
if test $$name = uudecode; then \
|
||||
rm -f $(man1dir)/`echo uudecode | sed '$(transform)'`$(man1ext); \
|
||||
man1base=`echo $(man1dir) | sed 's@.*/\(.*\)@&1@'`; \
|
||||
echo ".so $$man1base/uuencode$(man1ext)" \
|
||||
> $(man1dir)/`echo uudecode | sed '$(transform)'`$(man1ext); \
|
||||
else \
|
||||
$(INSTALL_DATA) $(srcdir)/$$name.1 \
|
||||
$(man1dir)/`echo $$name | sed '$(transform)'`$(man1ext); \
|
||||
fi; \
|
||||
done
|
||||
test -z "$(MAN5PAGES)" || \
|
||||
for name in $(MAN5PAGES); do \
|
||||
$(INSTALL_DATA) $(srcdir)/$$name.5 \
|
||||
$(man5dir)/`echo $$name | sed '$(transform)'`$(man5ext); \
|
||||
done
|
||||
|
||||
uninstall-man:
|
||||
for name in $(MAN1PAGES); do \
|
||||
rm -f $(man1dir)/`echo $$name | sed '$(transform)'`$(man1ext); \
|
||||
done
|
||||
test -z "$(MAN5PAGES)" || \
|
||||
for name in $(MAN5PAGES); do \
|
||||
rm -f $(man5dir)/`echo $$name | sed '$(transform)'`$(man5ext); \
|
||||
done
|
||||
|
||||
|
||||
TAGS ID:
|
||||
|
||||
mostlyclean:
|
||||
rm -f *.aux *.cp *.cps *.dvi *.fn *.fns *.ky *.log *.pg *.toc *.tp *.vr
|
||||
rm -f *.tmp
|
||||
|
||||
clean: mostlyclean
|
||||
|
||||
distclean: clean
|
||||
rm -f Makefile
|
||||
|
||||
maintainer-clean: distclean
|
||||
@echo "This command is intended only for maintainers to use;"
|
||||
@echo "rebuilding the deleted files may require special tools."
|
||||
rm -f stamp-vti version.texi sharutils.info* remsync.info*
|
||||
|
||||
distdir = ../$(PACKAGE)-$(VERSION)/$(subdir)
|
||||
dist: Makefile $(DISTFILES)
|
||||
for file in $(DISTFILES); do \
|
||||
ln $(srcdir)/$$file $(distdir) 2> /dev/null \
|
||||
|| cp -p $(srcdir)/$$file $(distdir); \
|
||||
done
|
||||
|
||||
Makefile: Makefile.in ../config.status
|
||||
cd .. && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= ./config.status
|
||||
|
||||
# Tell versions [3.59,3.63) of GNU make not to export all variables.
|
||||
# Otherwise a system limit (for SysV at least) may be exceeded.
|
||||
.NOEXPORT:
|
||||
Executable
+92
@@ -0,0 +1,92 @@
|
||||
#!/bin/sh
|
||||
# mdate-sh - get modification time of a file and pretty-print it
|
||||
# Copyright (C) 1995 Software Foundation, Inc.
|
||||
# Written by Ulrich Drepper <[email protected]>, June 1995
|
||||
#
|
||||
# This program is free software; you can redistribute it and/or modify
|
||||
# it under the terms of the GNU General Public License as published by
|
||||
# the Free Software Foundation; either version 2, or (at your option)
|
||||
# any later version.
|
||||
#
|
||||
# This program is distributed in the hope that it will be useful,
|
||||
# but WITHOUT ANY WARRANTY; without even the implied warranty of
|
||||
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
||||
# GNU General Public License for more details.
|
||||
#
|
||||
# You should have received a copy of the GNU General Public License
|
||||
# along with this program; if not, write to the Free Software
|
||||
# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
|
||||
|
||||
# Prevent date giving response in another language.
|
||||
LANG=C
|
||||
export LANG
|
||||
LC_ALL=C
|
||||
export LC_ALL
|
||||
LC_TIME=C
|
||||
export LC_TIME
|
||||
|
||||
# Get the extended ls output of the file.
|
||||
if ls -L /dev/null 1>/dev/null 2>&1; then
|
||||
set - `ls -L -l $1`
|
||||
else
|
||||
set - `ls -l $1`
|
||||
fi
|
||||
# The month is at least the fourth argument.
|
||||
# (3 shifts here, the next inside the loop)
|
||||
shift
|
||||
shift
|
||||
shift
|
||||
|
||||
# Find the month. Next argument is day, followed by the year or time.
|
||||
month=
|
||||
until test $month
|
||||
do
|
||||
shift
|
||||
case $1 in
|
||||
Jan) month=January; nummonth=1;;
|
||||
Feb) month=February; nummonth=2;;
|
||||
Mar) month=March; nummonth=3;;
|
||||
Apr) month=April; nummonth=4;;
|
||||
May) month=May; nummonth=5;;
|
||||
Jun) month=June; nummonth=6;;
|
||||
Jul) month=July; nummonth=7;;
|
||||
Aug) month=August; nummonth=8;;
|
||||
Sep) month=September; nummonth=9;;
|
||||
Oct) month=October; nummonth=10;;
|
||||
Nov) month=November; nummonth=11;;
|
||||
Dec) month=December; nummonth=12;;
|
||||
esac
|
||||
done
|
||||
|
||||
day=$2
|
||||
|
||||
# Here we have to deal with the problem that the ls output gives either
|
||||
# the time of day or the year.
|
||||
case $3 in
|
||||
*:*) set `date`; year=$7
|
||||
case $2 in
|
||||
Jan) nummonthtod=1;;
|
||||
Feb) nummonthtod=2;;
|
||||
Mar) nummonthtod=3;;
|
||||
Apr) nummonthtod=4;;
|
||||
May) nummonthtod=5;;
|
||||
Jun) nummonthtod=6;;
|
||||
Jul) nummonthtod=7;;
|
||||
Aug) nummonthtod=8;;
|
||||
Sep) nummonthtod=9;;
|
||||
Oct) nummonthtod=10;;
|
||||
Nov) nummonthtod=11;;
|
||||
Dec) nummonthtod=12;;
|
||||
esac
|
||||
# For the first six month of the year the time notation can also
|
||||
# be used for file modified in the last year.
|
||||
if (expr $nummonth \> $nummonthtod) > /dev/null;
|
||||
then
|
||||
year=`expr year - 1`
|
||||
fi
|
||||
;;
|
||||
*) year=$3;;
|
||||
esac
|
||||
|
||||
# The result.
|
||||
echo $day $month $year
|
||||
@@ -0,0 +1,709 @@
|
||||
This is Info file remsync.info, produced by Makeinfo-1.63 from the
|
||||
input file remsync.texi.
|
||||
|
||||
This file documents the `remsync' command and friends, which have
|
||||
the purpose of synchronizing remote directory trees using email.
|
||||
|
||||
Copyright (C) 1994 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of this
|
||||
manual provided the copyright notice and this permission notice are
|
||||
preserved on all copies.
|
||||
|
||||
Permission is granted to copy and distribute modified versions of
|
||||
this manual under the conditions for verbatim copying, provided that
|
||||
the entire resulting derived work is distributed under the terms of a
|
||||
permission notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this
|
||||
manual into another language, under the above conditions for modified
|
||||
versions, except that this permission notice may be stated in a
|
||||
translation approved by the Foundation.
|
||||
|
||||
|
||||
File: remsync.info, Node: Top, Next: Overview, Prev: (dir), Up: (dir)
|
||||
|
||||
`remsync'
|
||||
*********
|
||||
|
||||
`remsync' allows for remote synchronization of directory trees,
|
||||
using electronic mail.
|
||||
|
||||
The current `remsync' release is 1.3. This is an alpha state
|
||||
product, and this documentation is still sketchy.
|
||||
|
||||
* Menu:
|
||||
|
||||
* Overview:: Overview of `remsync' and friends
|
||||
* Remsync:: Specifications of program `remsync'
|
||||
* Services:: Specifications of other service programs
|
||||
* Formats:: Related file formats
|
||||
* Miscellaneous::
|
||||
|
||||
-- The Detailed Node Listing --
|
||||
|
||||
Overview of `remsync' and friends
|
||||
|
||||
* Internals:: How `remsync' works
|
||||
* Quick start:: Quick start at using `remsync'
|
||||
|
||||
Quick start at using `remsync'
|
||||
|
||||
* Invoking remsync:: The `remsync' command and arguments
|
||||
|
||||
Specifications of program `remsync'
|
||||
|
||||
* Invoking remsync:: The `remsync' command and arguments
|
||||
* Conveniences:: Automatic mechanisms in the `remsync' program
|
||||
* Commands:: Commands for `remsync'
|
||||
|
||||
The `remsync' command and arguments
|
||||
|
||||
* Conveniences:: Automatic mechanisms in the `remsync' program
|
||||
* Commands:: Commands for `remsync'
|
||||
|
||||
Specifications of other service programs
|
||||
|
||||
* Invoking mailshar:: The `mailshar' command and arguments
|
||||
* Invoking mail-files:: The `mail-files' command and arguments
|
||||
* Invoking find-mailer:: The `find-mailer' command and arguments
|
||||
|
||||
Related file formats
|
||||
|
||||
* Xremsync:: Format of the `.remsync' file
|
||||
* Package:: Format of transiting packages
|
||||
|
||||
Various considerations
|
||||
|
||||
* News:: Using News distribution instead?
|
||||
* Previous:: Documentation for obsolete scripts
|
||||
|
||||
Documentation for obsolete scripts
|
||||
|
||||
* mailsync:: mailsync
|
||||
* resync:: resync
|
||||
|
||||
|
||||
File: remsync.info, Node: Overview, Next: Remsync, Prev: Top, Up: Top
|
||||
|
||||
Overview of `remsync' and friends
|
||||
*********************************
|
||||
|
||||
The `remsync' program allows for transmitting, over email, selected
|
||||
parts of directories for trying to maintain up-to-date files over many
|
||||
sites. It sends out and processes incoming specially packaged files
|
||||
using `shar', `tar', `gzip' and electronic mail programs.
|
||||
|
||||
There is no *master* site, each site has an equal opportunity to
|
||||
modify files, and modified files are propagated. Among many other
|
||||
commands, the `broadcast' command sends an update package from the
|
||||
current site to all others, the `process' command is used to apply
|
||||
update packages locally after reception from remote sites.
|
||||
|
||||
The unit of transmission is whole files. For now, whenever a module
|
||||
is modified, it is silently synchronized only if it has been modified at
|
||||
only one place. The merging has to be done at the site where the
|
||||
discrepancy is observed, from where it is propagated again.
|
||||
|
||||
* Menu:
|
||||
|
||||
* Internals:: How `remsync' works
|
||||
* Quick start:: Quick start at using `remsync'
|
||||
|
||||
|
||||
File: remsync.info, Node: Internals, Next: Quick start, Prev: Overview, Up: Overview
|
||||
|
||||
How `remsync' works
|
||||
===================
|
||||
|
||||
How does `remsync' keep track of what is in sync, and what isn't?
|
||||
*Note Xremsync::, for a the documentation on the `.remsync' file
|
||||
format. I understand that a mere description of the format does not
|
||||
replace an explanation, but in the meantime, you might guess from the
|
||||
format how the program works.
|
||||
|
||||
All files are summarized by a checksum, computed by the `sum'
|
||||
program. There are a few variants of `sum' computing checksums in
|
||||
incompatible ways, under the control of options. `remsync' attempts to
|
||||
retrieve on each site a compatible way to do it, and complains if it
|
||||
cannot.
|
||||
|
||||
`remsync' does not compare dates or sizes. Experience shown that the
|
||||
best version of a file is not necessarily the one with the latest
|
||||
timestamp. The best version for a site is the current version on this
|
||||
site, as decided by its maintainer there, and this is this version that
|
||||
will be propagated.
|
||||
|
||||
Each site has an idea of the checksum of a file for all other sites.
|
||||
These checksums are not necessarily identical, for sites do not
|
||||
necessarily propagate to all others, and the propagation network maybe
|
||||
incomplete or asymmetrical in various ways.
|
||||
|
||||
Propagation is never done unattended. The user on a site has to call
|
||||
`remsync broadcast' to issue synchronization packages for other sites.
|
||||
If this is never done, the local modifications will never leave the
|
||||
site. The user also has to call `remsync process' to apply received
|
||||
synchronization packages. Applying a package does not automatically
|
||||
broadcast it further (maybe this could change?).
|
||||
|
||||
If a site A propagates some files to sites B and D, but not C, site
|
||||
B is informed that site D also received these files, and site D is
|
||||
informed that site B also received these files, so they will not
|
||||
propagate again the same files to one another. However, both site B
|
||||
and D are susceptible to propagate further the same files to site C.
|
||||
|
||||
It may happen that a site refuses to update a file, or modifies a
|
||||
file after having been received, or merges versions, or whatever. So,
|
||||
sites may have a wrong opinion of the file contents on other sites.
|
||||
These differences level down after a few exchanges, and it is very
|
||||
unlikely that a file would not be propagated when it should have.
|
||||
|
||||
This scheme works only when the various people handling the various
|
||||
files have confidence in one each other. If site B modifies a file
|
||||
after having received it from site A, the file will eventually be
|
||||
propagated back to site A. If the original file stayed undisturbed on
|
||||
site A, that is, if `remsync' proves that site B correctly knew the
|
||||
checksum of the original file, then the file will be replaced on site A
|
||||
without any user confirmation. So, the user on site A has to trust the
|
||||
changes made by the user on site B.
|
||||
|
||||
If the original file on site A had been modified after having been
|
||||
sent in a synchronization package, than it is the responsibility of the
|
||||
user on site A to correctly merge the local modifications with the
|
||||
modifications observed in the file as received from site B. This
|
||||
responsibility is real, since the merged file will later be propagated
|
||||
to the other sites in an authoritative way.
|
||||
|
||||
|
||||
File: remsync.info, Node: Quick start, Prev: Internals, Up: Overview
|
||||
|
||||
Quick start at using `remsync'
|
||||
==============================
|
||||
|
||||
|
||||
File: remsync.info, Node: Remsync, Next: Services, Prev: Overview, Up: Top
|
||||
|
||||
Specifications of program `remsync'
|
||||
***********************************
|
||||
|
||||
* Menu:
|
||||
|
||||
* Invoking remsync:: The `remsync' command and arguments
|
||||
* Conveniences:: Automatic mechanisms in the `remsync' program
|
||||
* Commands:: Commands for `remsync'
|
||||
|
||||
|
||||
File: remsync.info, Node: Invoking remsync, Next: Conveniences, Prev: Remsync, Up: Remsync
|
||||
|
||||
The `remsync' command and arguments
|
||||
===================================
|
||||
|
||||
At the shell prompt, calling the command `remsync' without any
|
||||
parameters initiates an interactive dialog, in which the user types
|
||||
commands and receives feedback from the program.
|
||||
|
||||
The command `remsync', given at the shell prompt, may have
|
||||
arguments, in which case these arguments taken together form one
|
||||
`remsync' interactive command. However, `--help' and `--version'
|
||||
options are interpreted especially, with their usual effect in GNU.
|
||||
Once this command has been executed, no more commands are taken from
|
||||
the user and `remsync' terminates execution. This allows for using
|
||||
`remsync' in some kind of batch mode. It is unwise to redirect
|
||||
`remsync' standard input, because user interactions might often be
|
||||
needed in ways difficult to predict in advance.
|
||||
|
||||
The two most common usages of `remsync' are the commands:
|
||||
|
||||
remsync b
|
||||
remsync p
|
||||
|
||||
The first example executes the `broadcast' command, which sends
|
||||
synchronization packages to all connected remote sites for the current
|
||||
local directory tree.
|
||||
|
||||
The second example executes the `process' command, which studies and
|
||||
complies with a synchronisation package saved in the current directory
|
||||
(not necessarily into the synchronized directory tree), under the usual
|
||||
file name `remsync.tar.gz'.
|
||||
|
||||
* Menu:
|
||||
|
||||
* Conveniences:: Automatic mechanisms in the `remsync' program
|
||||
* Commands:: Commands for `remsync'
|
||||
|
||||
|
||||
File: remsync.info, Node: Conveniences, Next: Commands, Prev: Invoking remsync, Up: Remsync
|
||||
|
||||
Automatic mechanisms in the `remsync' program
|
||||
=============================================
|
||||
|
||||
The following points apply to many of the `remsync' commands. We
|
||||
describe them here once and for all.
|
||||
|
||||
* The file `.remsync' describes the various properties for the
|
||||
current synchronization. It is kept right in the top directory of
|
||||
a synchronized directory tree. Some commands may be executed
|
||||
without any need for this file. The program waits as far as
|
||||
possible before reading it.
|
||||
|
||||
* If the `.remsync' file is not found when required, and only then,
|
||||
the user is interactively asked to fill a questionnaire about it.
|
||||
|
||||
* If the `.remsync' file has been logically modified after having
|
||||
been read, or if it just has been created, the program will save
|
||||
it back on disk. But it will do so only before reading another
|
||||
`.remsync' file, or just before exit. A preexisting `.remsync'
|
||||
will be renamed to `.remsync.bak' before it is rewritten, when
|
||||
this is done, any previous `.remsync.bak' file is discarded.
|
||||
|
||||
* Many commands refer to previously entered information by repeating
|
||||
this information. For example, one can refer to a particular
|
||||
`scan' statement by entering the wildcard to be scanned by this
|
||||
statement. An alternative method of specifying a statement
|
||||
consists in using the decimal number which appears between square
|
||||
brackets in the result of a `list' command.
|
||||
|
||||
* Whenever a site list must be given, it is a space separated list of
|
||||
remote sites. If the list is preceeded by a bang (!), the list is
|
||||
complemented, that is, the sites that will be operated upon are all
|
||||
those *not* appearing in the list. As a special case, if the site
|
||||
list is completely empty, then all sites are selected.
|
||||
|
||||
|
||||
File: remsync.info, Node: Commands, Prev: Conveniences, Up: Remsync
|
||||
|
||||
Commands for `remsync'
|
||||
======================
|
||||
|
||||
Program commands to `remsync' may be given interactively by the user
|
||||
sitten at a terminal. They can come from the arguments of the
|
||||
`remsync' call at the shell level. Internally, the `process' command
|
||||
might obey many sub-commands found in a received synchronization
|
||||
package.
|
||||
|
||||
Program commands are given one per line. Lines beginning with a
|
||||
sharp (#) and white lines are ignored, they are meant to increase
|
||||
clarity or to introduce user comments. With only a few exceptions,
|
||||
commands are introduced by a keyword and often contains other keywords.
|
||||
In all cases, the keywords specific to `remsync' may be abbreviated to
|
||||
their first letter. When there are many keywords in succession, the
|
||||
space separating them may be omitted. So the following commands are
|
||||
all equivalent:
|
||||
|
||||
list remote
|
||||
l remote
|
||||
list r
|
||||
l r
|
||||
listremote
|
||||
lr
|
||||
|
||||
while the following are not legal:
|
||||
|
||||
l rem
|
||||
lisremote
|
||||
|
||||
Below, for clarity, keywords are written in full and separated by
|
||||
spaces. Commands often accept parameters, which are then separated by
|
||||
spaces. All available commands are given in the table. The first few
|
||||
commands do not pre-require the file `.remsync'. The last three
|
||||
commands are almost never used interactively, but rather automatically
|
||||
triggered while `process''ing received synchronization packages.
|
||||
|
||||
`?'
|
||||
Display a quick help summary of available commands.
|
||||
|
||||
`!' [ SHELL-COMMAND ]
|
||||
If SHELL-COMMAND has been given, execute it right now as a shell
|
||||
command. When not given, rather start an interactive shell.
|
||||
Exiting from the shell will return to this program. The started
|
||||
shell is taken from the `SHELL' environment variable if set, else
|
||||
`sh' is used.
|
||||
|
||||
`quit'
|
||||
Leave the program normally and return to the shell.
|
||||
|
||||
`abort'
|
||||
Leave the program with a nonzero exit status and return to the
|
||||
shell. No attempt is made to save a logically modified `.remsync'
|
||||
file.
|
||||
|
||||
`visit' DIRECTORY
|
||||
Select another synchronized directory tree for any subsequent
|
||||
operation. DIRECTORY is the top directory of the synchronized
|
||||
directory tree.
|
||||
|
||||
`process' [ FILE ]
|
||||
`list' [ TYPE ]
|
||||
List all known statements about some information TYPE. Allowable
|
||||
keywords for TYPE are `local', `remote', `scan', `ignore' and
|
||||
`files'. The keyword `files' asks for all empty statements (see
|
||||
later). If TYPE is omitted, then list all known statements for
|
||||
all types, except those given by `files'.
|
||||
|
||||
[ `create' ] TYPE VALUE
|
||||
Create a new statement introducing a VALUE for a given TYPE.
|
||||
Allowable keywords for TYPE are `remote', `scan' and `ignore'.
|
||||
The `create' keyword may be omitted.
|
||||
|
||||
For `create' `ignore', when the pattern is preceeded by a bang
|
||||
(!), the condition is reversed. That is, only those files which
|
||||
do match the pattern will be kept for synchronization.
|
||||
|
||||
`delete' TYPE VALUE
|
||||
Delete an existing statement supporting some VALUE for a given
|
||||
TYPE. Allowable keywords for TYPE are `remote', `scan' and
|
||||
`ignore'.
|
||||
|
||||
`email' REMOTE VALUE
|
||||
Modify the electronic mail address associated with some REMOTE
|
||||
site, giving it a new VALUE. The special `local' keyword for
|
||||
REMOTE may be used to modify the local electronic mail address.
|
||||
|
||||
`home' REMOTE VALUE
|
||||
Modify the top directory of the synchronized directory tree
|
||||
associated with some REMOTE site, giving it a new VALUE. The
|
||||
special `local' keyword for REMOTE may be used to modify the local
|
||||
top directory.
|
||||
|
||||
`broadcast' SITE_LIST
|
||||
Send by electronic mail an update package to all sites from
|
||||
SITE_LIST, containing for each site all and only those files which
|
||||
are known to be different between the remote site and here.
|
||||
|
||||
`version' VERSION
|
||||
This command is not meant for interactive use. It establishes the
|
||||
`remsync' version needed to process the incoming commands.
|
||||
|
||||
`from' SITE_LIST
|
||||
This command is not really meant for interactive use. The first
|
||||
site from the SITE_LIST is the remote site which originated the
|
||||
synchronization package. All the others are all the sites,
|
||||
including here, which were meant to be synchronized by the
|
||||
`broadcast' command that was issued at the originating remote site.
|
||||
|
||||
`sum' FILE CHECKSUM
|
||||
This command is not really meant for interactive use. It declares
|
||||
the CHECKSUM value of a particular FILE at the originating remote
|
||||
site. Also, if at least one `sum' command is received, then it is
|
||||
guaranteed that the originating remote site sent one `sum' command
|
||||
for each and every file to be synchronized, so any found local
|
||||
file which was not subject of any `sum' command does not exist
|
||||
remotely.
|
||||
|
||||
`if' FILE CHECKSUM PACKAGED
|
||||
This command is not really meant for interactive use. It directs
|
||||
the `remsync' program to check if a local FILE has a given
|
||||
CHECKSUM. If the checksum agrees, then the local file will be
|
||||
replaced by the PACKAGED file, as found in the received
|
||||
synchronization invoice.
|
||||
|
||||
|
||||
File: remsync.info, Node: Services, Next: Formats, Prev: Remsync, Up: Top
|
||||
|
||||
Specifications of other service programs
|
||||
****************************************
|
||||
|
||||
* Menu:
|
||||
|
||||
* Invoking mailshar:: The `mailshar' command and arguments
|
||||
* Invoking mail-files:: The `mail-files' command and arguments
|
||||
* Invoking find-mailer:: The `find-mailer' command and arguments
|
||||
|
||||
|
||||
File: remsync.info, Node: Invoking mailshar, Next: Invoking mail-files, Prev: Services, Up: Services
|
||||
|
||||
The `mailshar' command and arguments
|
||||
====================================
|
||||
|
||||
|
||||
File: remsync.info, Node: Invoking mail-files, Next: Invoking find-mailer, Prev: Invoking mailshar, Up: Services
|
||||
|
||||
The `mail-files' command and arguments
|
||||
======================================
|
||||
|
||||
|
||||
File: remsync.info, Node: Invoking find-mailer, Prev: Invoking mail-files, Up: Services
|
||||
|
||||
The `find-mailer' command and arguments
|
||||
=======================================
|
||||
|
||||
|
||||
File: remsync.info, Node: Formats, Next: Miscellaneous, Prev: Services, Up: Top
|
||||
|
||||
Related file formats
|
||||
********************
|
||||
|
||||
* Menu:
|
||||
|
||||
* Xremsync:: Format of the `.remsync' file
|
||||
* Package:: Format of transiting packages
|
||||
|
||||
|
||||
File: remsync.info, Node: Xremsync, Next: Package, Prev: Formats, Up: Formats
|
||||
|
||||
Format of the `.remsync' file
|
||||
=============================
|
||||
|
||||
The `.remsync' file saves all the information a site needs for
|
||||
properly synchronizing a directory tree with remote sites. Even if it
|
||||
is meant to be editable using any ASCII editor, it has a very precise
|
||||
format and one should be very careful while modifying it. The
|
||||
`.remsync' file is better handled through the `remsync' program and
|
||||
commands.
|
||||
|
||||
The `.remsync' file is made up of statements, one per line. Each
|
||||
line begins with a statement keyword followed by a single TAB, then by
|
||||
one or more parameters. The keyword may be omitted, in this case, the
|
||||
keyword is said to be *empty*, and the line begins immediately with the
|
||||
TAB. After the TAB, if there are two parameters or more, they should
|
||||
all be separated with a single space. There should not be any space
|
||||
between the last parameter and the end of line (unless there are
|
||||
explicit empty parameters).
|
||||
|
||||
The following table gives the possible keywords. Their order of
|
||||
presentation in the table is also the order of appearance in the
|
||||
`.remsync' file.
|
||||
|
||||
`remsync'
|
||||
This statement identifies the `.remsync' format. The only
|
||||
parameter states the file format version.
|
||||
|
||||
`local'
|
||||
This statement should appear exactly once, and has exactly two
|
||||
parameters. The first parameter gives the electronic mail address
|
||||
the other sites should use for sending synchronization packages
|
||||
here. The second parameter gives the name of the local directory
|
||||
tree to synchronize, in absolute notation.
|
||||
|
||||
`remote'
|
||||
This statement may appear zero, one or more times. Each occurrence
|
||||
connects the synchronized directory tree to another tree on a
|
||||
remote site. The first parameter gives one electronic mail
|
||||
address where to send remote synchronization packages. The second
|
||||
parameter gives the name of the corresponding directory tree for
|
||||
this remote electronic mail address, in absolute notation.
|
||||
|
||||
`scan'
|
||||
This statement may appear zero, one or more times. When it does
|
||||
not appear at all, the whole local directory tree will always be
|
||||
scanned, searching for files to synchronize. When the statement
|
||||
appears at least once, the whole local directory tree will not be
|
||||
scanned, but only those files or directories appearing in one of
|
||||
these statements. Each `scan' statement has exactly one
|
||||
parameter, giving one file or directory to be studied. These are
|
||||
usually given relative to top directory of the local
|
||||
synchronization directory tree. Shell wildcards are acceptable.
|
||||
|
||||
`ignore'
|
||||
This statement may appear zero, one or more times. Each
|
||||
occurrence has one parameter giving a regular expression,
|
||||
according to Perl syntax for regular expressions. These REGEXPs
|
||||
are applied against each file resulting from the scan. If any of
|
||||
the `ignore' expression matches one of resulting file, the file is
|
||||
discarded and is not subject to remote synchronization.
|
||||
|
||||
After all the statements beginning by the previous keywords, the
|
||||
`.remsync' file usually contains many statements having the empty
|
||||
keyword. The empty keyword statement may appear zero, one or more
|
||||
times. Each occurrence list one file being remotely synchronized. The
|
||||
first parameter gives an explicit file name, usually given relative to
|
||||
the top directory of the local synchronized directory tree. Shell
|
||||
wildcards are *not* acceptable.
|
||||
|
||||
Besides the file name parameter, there are supplementary parameters
|
||||
to each empty keyword statement, each corresponding to one remote
|
||||
statement in the `.remsync' file. The second parameter corresponds to
|
||||
the first remote, the third parameter corresponds to the second remote,
|
||||
etc. If there are more remote statements than supplementary parameters,
|
||||
missing parameters are considered to be empty.
|
||||
|
||||
Each supplementary parameter usually gives the last known checksum
|
||||
value for this particular file, as computed on its corresponding
|
||||
*remote* site. The parameter contains a dash `-' while the remote
|
||||
checksum is unknown. The checksum value for the *local* copy of the
|
||||
file is never kept anywhere in the `.remsync' file. The special value
|
||||
`666' indicates a checksum from hell, used when the remote file is
|
||||
known to exist, but for which contradictory information has been
|
||||
received from various sources.
|
||||
|
||||
|
||||
File: remsync.info, Node: Package, Prev: Xremsync, Up: Formats
|
||||
|
||||
Format of transiting packages
|
||||
=============================
|
||||
|
||||
|
||||
File: remsync.info, Node: Miscellaneous, Prev: Formats, Up: Top
|
||||
|
||||
Various considerations
|
||||
**********************
|
||||
|
||||
* Menu:
|
||||
|
||||
* News:: Using News distribution instead?
|
||||
* Previous:: Documentation for obsolete scripts
|
||||
|
||||
|
||||
File: remsync.info, Node: News, Next: Previous, Prev: Miscellaneous, Up: Miscellaneous
|
||||
|
||||
Using News distribution instead?
|
||||
================================
|
||||
|
||||
One correspondent thinks that perhaps the news distribution mechanism
|
||||
could be pressed into service for this job. I could have started from
|
||||
C-news, say, instead of from scratch, and have progressively bent
|
||||
C-news to behave like I wanted.
|
||||
|
||||
My feeling is that the route was shorter as I did it, from scratch,
|
||||
that it would have been from C-news. Of course, I could have removed
|
||||
the heavy administrative details of C-news: the history and `expire',
|
||||
the daemons, the `cron' entries, etc., then added the interactive
|
||||
features and specialized behaviors, but all this clean up would
|
||||
certainly have took energies. Right now, non counting the subsidiary
|
||||
scripts and shar/unshar sources, the heart of the result is a single
|
||||
(1200 lines) script written in Perl, which I find fairly more smaller
|
||||
and maintainable than a patched C-news distribution would have been.
|
||||
|
||||
|
||||
File: remsync.info, Node: Previous, Prev: News, Up: Miscellaneous
|
||||
|
||||
Documentation for obsolete scripts
|
||||
==================================
|
||||
|
||||
This is merely a place holder for previous documentation, waiting
|
||||
that I clean it up. You have no interest in reading further down.
|
||||
|
||||
* Menu:
|
||||
|
||||
* mailsync:: mailsync
|
||||
* resync:: resync
|
||||
|
||||
|
||||
File: remsync.info, Node: mailsync, Next: resync, Prev: Previous, Up: Previous
|
||||
|
||||
mailsync
|
||||
--------
|
||||
|
||||
Usage: mailsync [ OPTION ] ... [ EMAIL_ADDRESS ] [ DIRECTORY ]
|
||||
or: mailsync [ OPTION ] ... SYNC_DIRECTORY
|
||||
|
||||
Option -i simply sends a `ihave' package, with no bulk files.
|
||||
Option -n inhibits any destructive operation and mailing.
|
||||
|
||||
In the first form of the call, find a synchronisation directory in
|
||||
DIRECTORY aimed towards some EMAIL_ADDRESS, then proceed with this
|
||||
synchronisation directory. EMAIL_ADDRESS may be the name of a file
|
||||
containing a distribution list. If EMAIL_ADDRESS is not specified, all
|
||||
the synchronisation directories at the top level in DIRECTORY are
|
||||
processed in turn. If DIRECTORY is not specified, the current
|
||||
directory is used.
|
||||
|
||||
In the second form of the call, proceed only with the given
|
||||
synchronisation directory SYNC_DIRECTORY.
|
||||
|
||||
For proceeding with a synchronisation directory, whatever the form of
|
||||
the call was, this script reads the `ident' files it contains to set
|
||||
the local user and directory and the remote user and directory. Then,
|
||||
selected files under the local directory which are modified in regard
|
||||
to the corresponding files in the remote directory are turned into a
|
||||
synchronisation package which is mailed to the remote user.
|
||||
|
||||
The list of selected files or directories to synchronize from the
|
||||
local directory are given in the `list' file in the synchronisation
|
||||
directory. If this `list' file is missing, all files under the local
|
||||
directory are synchronized.
|
||||
|
||||
What I usually do is to `cd' at the top of the directory tree to be
|
||||
synchronized, then to type `mailsync' without parameters. This will
|
||||
automatically prepare as many synchronisation packages as there are
|
||||
mirror systems, then email multipart shars to each of them. Note that
|
||||
the synchronisation package is not identical for each mirror system,
|
||||
because they do not usually have the same state of synchronisation.
|
||||
|
||||
`mailsync' will refuse to work if anything needs to be hand cleaned
|
||||
from a previous execution of `mailsync' or `resync'. Check for some
|
||||
remaining `_syncbulk' or `_synctemp' directory, or for a `_syncrm'
|
||||
script.
|
||||
|
||||
TODO:
|
||||
- interrogate the user if `ident' file missing.
|
||||
- automatically construct the local user address.
|
||||
- create the synchronisation directory on the fly.
|
||||
- avoid duplicating work as far as possible for multiple sends.
|
||||
- have a quicker mode, depending on stamps, not on checksums.
|
||||
- never send core, executables, backups, `.nsf*', `*/_synctemp/*', etc.
|
||||
|
||||
|
||||
File: remsync.info, Node: resync, Prev: mailsync, Up: Previous
|
||||
|
||||
resync
|
||||
------
|
||||
|
||||
Usage: resync [ OPTION ]... TAR_FILE
|
||||
or: resync [ OPTION ]... UNTARED_DIRECTORY
|
||||
|
||||
Given a tar file produced by mailsync at some remote end and already
|
||||
reconstructed on this end using unshar, or a directory containing the
|
||||
already untared invoice, apply the synchronization package locally.
|
||||
|
||||
Option -n inhibits destroying or creating files, but does everything
|
||||
else. It will in particular create a synchronization directory if
|
||||
necessary, produce the `_syncbulk' directory and the `_syncrm' script.
|
||||
|
||||
The synchronization directory for the package is automatically
|
||||
retrieved or, if not found, created and initialized. `resync' keeps
|
||||
telling you what it is doing.
|
||||
|
||||
There are a few cases when a resync should not complete without
|
||||
manual intervention. The common case is that several sites update the
|
||||
very same files differently since they were last resync'ed, and then
|
||||
mailsync to each other. The prerequisite checksum will then fail, and
|
||||
the files are then kept into the `_syncbulk' tree, which has a shape
|
||||
similar to the directory tree in which the files where supposed to go.
|
||||
For GNU Emacs users, a very handy package, called emerge, written by
|
||||
Dale Worley <[email protected]>, helps reconciling two files
|
||||
interactiveley. The `_syncbulk' tree should be explicitely deleted
|
||||
after the hand synchronisation.
|
||||
|
||||
Another case of human intervention is when files are deleted at the
|
||||
mailsync'ing site. By choice, all deletions on the receiving side are
|
||||
accumulated in a `_syncrm' script, which is not executed automatically.
|
||||
Explicitely executed, `_syncrm' will remove any file in the receiving
|
||||
tree which does not exist anymore on the sender system. I often edit
|
||||
`_syncrm' before executing it, to remove the unwanted deletions (beware
|
||||
the double negation :-). The script removes itself.
|
||||
|
||||
All the temporary files, while resynchronizing, are held in
|
||||
`_synctemp', which is deleted afterwards; if something goes wrong, this
|
||||
directory should also be cleaned out by hand. `resync' will refuse to
|
||||
work if anything remains to be hand cleaned.
|
||||
|
||||
TODO:
|
||||
- interrogates the user if missing receiving directory in `ident'.
|
||||
- allow `remote.sum' to be empty or non-existent.
|
||||
|
||||
|
||||
|
||||
Tag Table:
|
||||
Node: Top942
|
||||
Node: Overview2742
|
||||
Node: Internals3868
|
||||
Node: Quick start7142
|
||||
Node: Remsync7280
|
||||
Node: Invoking remsync7622
|
||||
Node: Conveniences9180
|
||||
Node: Commands11084
|
||||
Node: Services16240
|
||||
Node: Invoking mailshar16605
|
||||
Node: Invoking mail-files16788
|
||||
Node: Invoking find-mailer16987
|
||||
Node: Formats17162
|
||||
Node: Xremsync17410
|
||||
Node: Package21832
|
||||
Node: Miscellaneous21962
|
||||
Node: News22205
|
||||
Node: Previous23229
|
||||
Node: mailsync23583
|
||||
Node: resync26135
|
||||
|
||||
End Tag Table
|
||||
@@ -0,0 +1,722 @@
|
||||
\input texinfo @c -*-texinfo-*-
|
||||
@c %**start of header
|
||||
@setfilename remsync.info
|
||||
@settitle @code{remsync} reference manual
|
||||
@finalout
|
||||
@setchapternewpage odd
|
||||
@c %**end of header
|
||||
|
||||
@ifinfo
|
||||
This file documents the @code{remsync} command and friends, which have
|
||||
the purpose of synchronizing remote directory trees using email.
|
||||
|
||||
Copyright (C) 1994 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of
|
||||
this manual provided the copyright notice and this permission notice
|
||||
are preserved on all copies.
|
||||
|
||||
@ignore
|
||||
Permission is granted to process this file through TeX and print the
|
||||
results, provided the printed document carries copying permission
|
||||
notice identical to this one except for the removal of this paragraph
|
||||
(this paragraph not being relevant to the printed manual).
|
||||
|
||||
@end ignore
|
||||
Permission is granted to copy and distribute modified versions of this
|
||||
manual under the conditions for verbatim copying, provided that the entire
|
||||
resulting derived work is distributed under the terms of a permission
|
||||
notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this manual
|
||||
into another language, under the above conditions for modified versions,
|
||||
except that this permission notice may be stated in a translation approved
|
||||
by the Foundation.
|
||||
@end ifinfo
|
||||
|
||||
@titlepage
|
||||
@title remsync, version 1.3
|
||||
@subtitle A remote synchronization utility
|
||||
@subtitle Edition 1.3, June 1994
|
||||
@author by @value{Francois} Pinard
|
||||
|
||||
@page
|
||||
@vskip 0pt plus 1filll
|
||||
Copyright @copyright{} 1994 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of
|
||||
this manual provided the copyright notice and this permission notice
|
||||
are preserved on all copies.
|
||||
|
||||
Permission is granted to copy and distribute modified versions of this
|
||||
manual under the conditions for verbatim copying, provided that the entire
|
||||
resulting derived work is distributed under the terms of a permission
|
||||
notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this manual
|
||||
into another language, under the above conditions for modified versions,
|
||||
except that this permission notice may be stated in a translation approved
|
||||
by the Foundation.
|
||||
@end titlepage
|
||||
|
||||
@ifinfo
|
||||
@node Top, Overview, (dir), (dir)
|
||||
@top @code{remsync}
|
||||
|
||||
@code{remsync} allows for remote synchronization of directory trees,
|
||||
using electronic mail.
|
||||
|
||||
The current @code{remsync} release is 1.3. This is an alpha state
|
||||
product, and this documentation is still sketchy.
|
||||
|
||||
@menu
|
||||
* Overview:: Overview of @code{remsync} and friends
|
||||
* Remsync:: Specifications of program @code{remsync}
|
||||
* Services:: Specifications of other service programs
|
||||
* Formats:: Related file formats
|
||||
* Miscellaneous::
|
||||
|
||||
--- The Detailed Node Listing ---
|
||||
|
||||
Overview of @code{remsync} and friends
|
||||
|
||||
* Internals:: How @code{remsync} works
|
||||
* Quick start:: Quick start at using @code{remsync}
|
||||
|
||||
Quick start at using @code{remsync}
|
||||
|
||||
* Invoking remsync:: The @code{remsync} command and arguments
|
||||
|
||||
Specifications of program @code{remsync}
|
||||
|
||||
* Invoking remsync:: The @code{remsync} command and arguments
|
||||
* Conveniences:: Automatic mechanisms in the @code{remsync} program
|
||||
* Commands:: Commands for @code{remsync}
|
||||
|
||||
The @code{remsync} command and arguments
|
||||
|
||||
* Conveniences:: Automatic mechanisms in the @code{remsync} program
|
||||
* Commands:: Commands for @code{remsync}
|
||||
|
||||
Specifications of other service programs
|
||||
|
||||
* Invoking mailshar:: The @code{mailshar} command and arguments
|
||||
* Invoking mail-files:: The @code{mail-files} command and arguments
|
||||
* Invoking find-mailer:: The @code{find-mailer} command and arguments
|
||||
|
||||
Related file formats
|
||||
|
||||
* Xremsync:: Format of the @file{.remsync} file
|
||||
* Package:: Format of transiting packages
|
||||
|
||||
Various considerations
|
||||
|
||||
* News:: Using News distribution instead?
|
||||
* Previous:: Documentation for obsolete scripts
|
||||
|
||||
Documentation for obsolete scripts
|
||||
|
||||
* mailsync:: mailsync
|
||||
* resync:: resync
|
||||
@end menu
|
||||
|
||||
@end ifinfo
|
||||
|
||||
@node Overview, Remsync, Top, Top
|
||||
@chapter Overview of @code{remsync} and friends
|
||||
|
||||
The @code{remsync} program allows for transmitting, over email, selected
|
||||
parts of directories for trying to maintain up-to-date files over many
|
||||
sites. It sends out and processes incoming specially packaged files
|
||||
using @code{shar}, @code{tar}, @code{gzip} and electronic mail programs.
|
||||
|
||||
There is no @emph{master} site, each site has an equal opportunity to
|
||||
modify files, and modified files are propagated. Among many other
|
||||
commands, the @code{broadcast} command sends an update package from the
|
||||
current site to all others, the @code{process} command is used to apply
|
||||
update packages locally after reception from remote sites.
|
||||
|
||||
The unit of transmission is whole files. For now, whenever a module is
|
||||
modified, it is silently synchronized only if it has been modified at
|
||||
only one place. The merging has to be done at the site where the
|
||||
discrepancy is observed, from where it is propagated again.
|
||||
|
||||
@menu
|
||||
* Internals:: How @code{remsync} works
|
||||
* Quick start:: Quick start at using @code{remsync}
|
||||
@end menu
|
||||
|
||||
@node Internals, Quick start, Overview, Overview
|
||||
@section How @code{remsync} works
|
||||
|
||||
How does @code{remsync} keep track of what is in sync, and what isn't?
|
||||
@xref{Xremsync}, for a the documentation on the @file{.remsync} file
|
||||
format. I understand that a mere description of the format does not
|
||||
replace an explanation, but in the meantime, you might guess from the
|
||||
format how the program works.
|
||||
|
||||
All files are summarized by a checksum, computed by the @code{sum} program.
|
||||
There are a few variants of @code{sum} computing checksums in incompatible
|
||||
ways, under the control of options. @code{remsync} attempts to retrieve on
|
||||
each site a compatible way to do it, and complains if it cannot.
|
||||
|
||||
@code{remsync} does not compare dates or sizes. Experience shown that the
|
||||
best version of a file is not necessarily the one with the latest
|
||||
timestamp. The best version for a site is the current version on this
|
||||
site, as decided by its maintainer there, and this is this version
|
||||
that will be propagated.
|
||||
|
||||
Each site has an idea of the checksum of a file for all other sites.
|
||||
These checksums are not necessarily identical, for sites do not
|
||||
necessarily propagate to all others, and the propagation network maybe
|
||||
incomplete or asymmetrical in various ways.
|
||||
|
||||
Propagation is never done unattended. The user on a site has to call
|
||||
@code{remsync broadcast} to issue synchronization packages for other sites.
|
||||
If this is never done, the local modifications will never leave the
|
||||
site. The user also has to call @code{remsync process} to apply received
|
||||
synchronization packages. Applying a package does not automatically
|
||||
broadcast it further (maybe this could change?).
|
||||
|
||||
If a site @var{A} propagates some files to sites @var{B} and @var{D},
|
||||
but not @var{C}, site @var{B} is informed that site @var{D} also
|
||||
received these files, and site @var{D} is informed that site @var{B}
|
||||
also received these files, so they will not propagate again the same
|
||||
files to one another. However, both site @var{B} and @var{D} are
|
||||
susceptible to propagate further the same files to site @var{C}.
|
||||
|
||||
It may happen that a site refuses to update a file, or modifies a file
|
||||
after having been received, or merges versions, or whatever. So,
|
||||
sites may have a wrong opinion of the file contents on other sites.
|
||||
These differences level down after a few exchanges, and it is very
|
||||
unlikely that a file would not be propagated when it should have.
|
||||
|
||||
This scheme works only when the various people handling the various
|
||||
files have confidence in one each other. If site @var{B} modifies a
|
||||
file after having received it from site @var{A}, the file will
|
||||
eventually be propagated back to site @var{A}. If the original file
|
||||
stayed undisturbed on site @var{A}, that is, if @code{remsync} proves
|
||||
that site @var{B} correctly knew the checksum of the original file, then
|
||||
the file will be replaced on site @var{A} without any user confirmation.
|
||||
So, the user on site A has to trust the changes made by the user on site
|
||||
@var{B}.
|
||||
|
||||
If the original file on site @var{A} had been modified after having been
|
||||
sent in a synchronization package, than it is the responsibility of the
|
||||
user on site @var{A} to correctly merge the local modifications with the
|
||||
modifications observed in the file as received from site @var{B}. This
|
||||
responsibility is real, since the merged file will later be propagated
|
||||
to the other sites in an authoritative way.
|
||||
|
||||
@node Quick start, , Internals, Overview
|
||||
@section Quick start at using @code{remsync}
|
||||
|
||||
@node Remsync, Services, Overview, Top
|
||||
@chapter Specifications of program @code{remsync}
|
||||
|
||||
@menu
|
||||
* Invoking remsync:: The @code{remsync} command and arguments
|
||||
* Conveniences:: Automatic mechanisms in the @code{remsync} program
|
||||
* Commands:: Commands for @code{remsync}
|
||||
@end menu
|
||||
|
||||
@node Invoking remsync, Conveniences, Remsync, Remsync
|
||||
@section The @code{remsync} command and arguments
|
||||
|
||||
At the shell prompt, calling the command @code{remsync} without any
|
||||
parameters initiates an interactive dialog, in which the user types
|
||||
commands and receives feedback from the program.
|
||||
|
||||
The command @code{remsync}, given at the shell prompt, may have
|
||||
arguments, in which case these arguments taken together form one
|
||||
@code{remsync} interactive command. However, @samp{--help} and
|
||||
@samp{--version} options are interpreted especially, with their usual
|
||||
effect in GNU. Once this command has been executed, no more commands
|
||||
are taken from the user and @code{remsync} terminates execution.
|
||||
This allows for using @code{remsync} in some kind of batch mode.
|
||||
It is unwise to redirect @code{remsync} standard input, because
|
||||
user interactions might often be needed in ways difficult to predict
|
||||
in advance.
|
||||
|
||||
The two most common usages of @code{remsync} are the commands:
|
||||
|
||||
@example
|
||||
remsync b
|
||||
remsync p
|
||||
@end example
|
||||
|
||||
The first example executes the @code{broadcast} command, which sends
|
||||
synchronization packages to all connected remote sites for the current
|
||||
local directory tree.
|
||||
|
||||
The second example executes the @code{process} command, which studies
|
||||
and complies with a synchronisation package saved in the current
|
||||
directory (not necessarily into the synchronized directory tree), under
|
||||
the usual file name @file{remsync.tar.gz}.
|
||||
|
||||
@menu
|
||||
* Conveniences:: Automatic mechanisms in the @code{remsync} program
|
||||
* Commands:: Commands for @code{remsync}
|
||||
@end menu
|
||||
|
||||
@node Conveniences, Commands, Invoking remsync, Remsync
|
||||
@section Automatic mechanisms in the @code{remsync} program
|
||||
|
||||
The following points apply to many of the @code{remsync} commands.
|
||||
We describe them here once and for all.
|
||||
|
||||
@itemize @bullet
|
||||
|
||||
@item
|
||||
The file @file{.remsync} describes the various properties for the
|
||||
current synchronization. It is kept right in the top directory of a
|
||||
synchronized directory tree. Some commands may be executed without any
|
||||
need for this file. The program waits as far as possible before reading
|
||||
it.
|
||||
|
||||
@item
|
||||
If the @file{.remsync} file is not found when required, and only then,
|
||||
the user is interactively asked to fill a questionnaire about it.
|
||||
|
||||
@item
|
||||
If the @file{.remsync} file has been logically modified after having
|
||||
been read, or if it just has been created, the program will save it back
|
||||
on disk. But it will do so only before reading another @file{.remsync}
|
||||
file, or just before exit. A preexisting @file{.remsync} will be
|
||||
renamed to @file{.remsync.bak} before it is rewritten, when this is
|
||||
done, any previous @file{.remsync.bak} file is discarded.
|
||||
|
||||
@item
|
||||
Many commands refer to previously entered information by repeating this
|
||||
information. For example, one can refer to a particular @code{scan}
|
||||
statement by entering the wildcard to be scanned by this statement.
|
||||
An alternative method of specifying a statement consists in using the
|
||||
decimal number which appears between square brackets in the result
|
||||
of a @code{list} command.
|
||||
|
||||
@item
|
||||
Whenever a site list must be given, it is a space separated list of
|
||||
remote sites. If the list is preceeded by a bang (@key{!}), the list is
|
||||
complemented, that is, the sites that will be operated upon are all
|
||||
those @emph{not} appearing in the list. As a special case, if the site
|
||||
list is completely empty, then all sites are selected.
|
||||
|
||||
@end itemize
|
||||
|
||||
@node Commands, , Conveniences, Remsync
|
||||
@section Commands for @code{remsync}
|
||||
|
||||
Program commands to @code{remsync} may be given interactively by the
|
||||
user sitten at a terminal. They can come from the arguments of the
|
||||
@code{remsync} call at the shell level. Internally, the @code{process}
|
||||
command might obey many sub-commands found in a received synchronization
|
||||
package.
|
||||
|
||||
Program commands are given one per line. Lines beginning with a sharp
|
||||
(@key{#}) and white lines are ignored, they are meant to increase
|
||||
clarity or to introduce user comments. With only a few exceptions,
|
||||
commands are introduced by a keyword and often contains other keywords.
|
||||
In all cases, the keywords specific to @code{remsync} may be abbreviated
|
||||
to their first letter. When there are many keywords in succession, the
|
||||
space separating them may be omitted. So the following commands are
|
||||
all equivalent:
|
||||
|
||||
@example
|
||||
list remote
|
||||
l remote
|
||||
list r
|
||||
l r
|
||||
listremote
|
||||
lr
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
while the following are not legal:
|
||||
|
||||
@example
|
||||
l rem
|
||||
lisremote
|
||||
@end example
|
||||
|
||||
Below, for clarity, keywords are written in full and separated by
|
||||
spaces. Commands often accept parameters, which are then separated by
|
||||
spaces. All available commands are given in the table. The first few
|
||||
commands do not pre-require the file @file{.remsync}. The last three
|
||||
commands are almost never used interactively, but rather automatically
|
||||
triggered while @code{process}'ing received synchronization packages.
|
||||
|
||||
@table @asis
|
||||
|
||||
@item @code{?}
|
||||
|
||||
Display a quick help summary of available commands.
|
||||
|
||||
@item @code{!} [ @var{shell-command} ]
|
||||
|
||||
If @var{shell-command} has been given, execute it right now as a shell
|
||||
command. When not given, rather start an interactive shell. Exiting
|
||||
from the shell will return to this program. The started shell is taken
|
||||
from the @code{SHELL} environment variable if set, else @code{sh} is
|
||||
used.
|
||||
|
||||
@item @code{quit}
|
||||
|
||||
Leave the program normally and return to the shell.
|
||||
|
||||
@item @code{abort}
|
||||
|
||||
Leave the program with a nonzero exit status and return to the shell.
|
||||
No attempt is made to save a logically modified @file{.remsync} file.
|
||||
|
||||
@item @code{visit} @var{directory}
|
||||
|
||||
Select another synchronized directory tree for any subsequent operation.
|
||||
@var{directory} is the top directory of the synchronized directory tree.
|
||||
|
||||
@item @code{process} [ @var{file} ]
|
||||
|
||||
@item @code{list} [ @var{type} ]
|
||||
|
||||
List all known statements about some information @var{type}. Allowable
|
||||
keywords for @var{type} are @code{local}, @code{remote}, @code{scan},
|
||||
@code{ignore} and @code{files}. The keyword @code{files} asks for all
|
||||
empty statements (see later). If @var{type} is omitted, then list all
|
||||
known statements for all types, except those given by @code{files}.
|
||||
|
||||
@item [ @code{create} ] @var{type} @var{value}
|
||||
|
||||
Create a new statement introducing a @var{value} for a given @var{type}.
|
||||
Allowable keywords for @var{type} are @code{remote}, @code{scan} and
|
||||
@code{ignore}. The @code{create} keyword may be omitted.
|
||||
|
||||
For @code{create} @code{ignore}, when the pattern is preceeded by a bang
|
||||
(@key{!}), the condition is reversed. That is, only those files which
|
||||
do match the pattern will be kept for synchronization.
|
||||
|
||||
@item @code{delete} @var{type} @var{value}
|
||||
|
||||
Delete an existing statement supporting some @var{value} for a given
|
||||
@var{type}. Allowable keywords for @var{type} are @code{remote},
|
||||
@code{scan} and @code{ignore}.
|
||||
|
||||
@item @code{email} @var{remote} @var{value}
|
||||
|
||||
Modify the electronic mail address associated with some @var{remote}
|
||||
site, giving it a new @var{value}. The special @code{local} keyword for
|
||||
@var{remote} may be used to modify the local electronic mail address.
|
||||
|
||||
@item @code{home} @var{remote} @var{value}
|
||||
|
||||
Modify the top directory of the synchronized directory tree associated
|
||||
with some @var{remote} site, giving it a new @var{value}. The special
|
||||
@code{local} keyword for @var{remote} may be used to modify the local
|
||||
top directory.
|
||||
|
||||
@item @code{broadcast} @var{site_list}
|
||||
|
||||
Send by electronic mail an update package to all sites from
|
||||
@var{site_list}, containing for each site all and only those files which
|
||||
are known to be different between the remote site and here.
|
||||
|
||||
@item @code{version} @var{version}
|
||||
|
||||
This command is not meant for interactive use. It establishes the
|
||||
@code{remsync} version needed to process the incoming commands.
|
||||
|
||||
@item @code{from} @var{site_list}
|
||||
|
||||
This command is not really meant for interactive use. The first site
|
||||
from the @var{site_list} is the remote site which originated the
|
||||
synchronization package. All the others are all the sites, including
|
||||
here, which were meant to be synchronized by the @code{broadcast}
|
||||
command that was issued at the originating remote site.
|
||||
|
||||
@item @code{sum} @var{file} @var{checksum}
|
||||
|
||||
This command is not really meant for interactive use. It declares the
|
||||
@var{checksum} value of a particular @var{file} at the originating
|
||||
remote site. Also, if at least one @code{sum} command is received, then
|
||||
it is guaranteed that the originating remote site sent one @code{sum}
|
||||
command for each and every file to be synchronized, so any found local
|
||||
file which was not subject of any @code{sum} command does not exist
|
||||
remotely.
|
||||
|
||||
@item @code{if} @var{file} @var{checksum} @var{packaged}
|
||||
|
||||
This command is not really meant for interactive use. It directs the
|
||||
@code{remsync} program to check if a local @var{file} has a given
|
||||
@var{checksum}. If the checksum agrees, then the local file will be
|
||||
replaced by the @var{packaged} file, as found in the received
|
||||
synchronization invoice.
|
||||
|
||||
@end table
|
||||
|
||||
@node Services, Formats, Remsync, Top
|
||||
@chapter Specifications of other service programs
|
||||
|
||||
@menu
|
||||
* Invoking mailshar:: The @code{mailshar} command and arguments
|
||||
* Invoking mail-files:: The @code{mail-files} command and arguments
|
||||
* Invoking find-mailer:: The @code{find-mailer} command and arguments
|
||||
@end menu
|
||||
|
||||
@node Invoking mailshar, Invoking mail-files, Services, Services
|
||||
@section The @code{mailshar} command and arguments
|
||||
|
||||
@node Invoking mail-files, Invoking find-mailer, Invoking mailshar, Services
|
||||
@section The @code{mail-files} command and arguments
|
||||
|
||||
@node Invoking find-mailer, , Invoking mail-files, Services
|
||||
@section The @code{find-mailer} command and arguments
|
||||
|
||||
@node Formats, Miscellaneous, Services, Top
|
||||
@chapter Related file formats
|
||||
|
||||
@menu
|
||||
* Xremsync:: Format of the @file{.remsync} file
|
||||
* Package:: Format of transiting packages
|
||||
@end menu
|
||||
|
||||
@node Xremsync, Package, Formats, Formats
|
||||
@section Format of the @file{.remsync} file
|
||||
|
||||
The @file{.remsync} file saves all the information a site needs for
|
||||
properly synchronizing a directory tree with remote sites. Even if it
|
||||
is meant to be editable using any ASCII editor, it has a very precise
|
||||
format and one should be very careful while modifying it. The
|
||||
@file{.remsync} file is better handled through the @code{remsync}
|
||||
program and commands.
|
||||
|
||||
The @file{.remsync} file is made up of statements, one per line. Each
|
||||
line begins with a statement keyword followed by a single @key{TAB},
|
||||
then by one or more parameters. The keyword may be omitted, in this
|
||||
case, the keyword is said to be @emph{empty}, and the line begins
|
||||
immediately with the @key{TAB}. After the @key{TAB}, if there are two
|
||||
parameters or more, they should all be separated with a single space.
|
||||
There should not be any space between the last parameter and the end of
|
||||
line (unless there are explicit empty parameters).
|
||||
|
||||
The following table gives the possible keywords. Their order of
|
||||
presentation in the table is also the order of appearance in the
|
||||
@file{.remsync} file.
|
||||
|
||||
@table @code
|
||||
|
||||
@item remsync
|
||||
This statement identifies the @file{.remsync} format. The only
|
||||
parameter states the file format version.
|
||||
|
||||
@item local
|
||||
This statement should appear exactly once, and has exactly two
|
||||
parameters. The first parameter gives the electronic mail address the
|
||||
other sites should use for sending synchronization packages here. The
|
||||
second parameter gives the name of the local directory tree to
|
||||
synchronize, in absolute notation.
|
||||
|
||||
@item remote
|
||||
This statement may appear zero, one or more times. Each occurrence
|
||||
connects the synchronized directory tree to another tree on a remote
|
||||
site. The first parameter gives one electronic mail address where to
|
||||
send remote synchronization packages. The second parameter gives the
|
||||
name of the corresponding directory tree for this remote electronic mail
|
||||
address, in absolute notation.
|
||||
|
||||
@item scan
|
||||
This statement may appear zero, one or more times. When it does not
|
||||
appear at all, the whole local directory tree will always be scanned,
|
||||
searching for files to synchronize. When the statement appears at least
|
||||
once, the whole local directory tree will not be scanned, but only those
|
||||
files or directories appearing in one of these statements. Each
|
||||
@code{scan} statement has exactly one parameter, giving one file or
|
||||
directory to be studied. These are usually given relative to top
|
||||
directory of the local synchronization directory tree. Shell wildcards
|
||||
are acceptable.
|
||||
|
||||
@item ignore
|
||||
This statement may appear zero, one or more times. Each occurrence has
|
||||
one parameter giving a regular expression, according to Perl syntax for
|
||||
regular expressions. These @var{regexp}s are applied against each file
|
||||
resulting from the scan. If any of the @code{ignore} expression matches
|
||||
one of resulting file, the file is discarded and is not subject to
|
||||
remote synchronization.
|
||||
|
||||
@end table
|
||||
|
||||
After all the statements beginning by the previous keywords, the
|
||||
@file{.remsync} file usually contains many statements having the empty
|
||||
keyword. The empty keyword statement may appear zero, one or more
|
||||
times. Each occurrence list one file being remotely synchronized. The
|
||||
first parameter gives an explicit file name, usually given relative to
|
||||
the top directory of the local synchronized directory tree. Shell
|
||||
wildcards are @emph{not} acceptable.
|
||||
|
||||
Besides the file name parameter, there are supplementary parameters to
|
||||
each empty keyword statement, each corresponding to one remote statement
|
||||
in the @file{.remsync} file. The second parameter corresponds to the
|
||||
first remote, the third parameter corresponds to the second remote, etc.
|
||||
If there are more remote statements than supplementary parameters,
|
||||
missing parameters are considered to be empty.
|
||||
|
||||
Each supplementary parameter usually gives the last known checksum
|
||||
value for this particular file, as computed on its corresponding
|
||||
@emph{remote} site. The parameter contains a dash @kbd{-} while the
|
||||
remote checksum is unknown. The checksum value for the @emph{local}
|
||||
copy of the file is never kept anywhere in the @file{.remsync} file.
|
||||
The special value @samp{666} indicates a checksum from hell, used
|
||||
when the remote file is known to exist, but for which contradictory
|
||||
information has been received from various sources.
|
||||
|
||||
@node Package, , Xremsync, Formats
|
||||
@section Format of transiting packages
|
||||
|
||||
@node Miscellaneous, , Formats, Top
|
||||
@chapter Various considerations
|
||||
|
||||
@menu
|
||||
* News:: Using News distribution instead?
|
||||
* Previous:: Documentation for obsolete scripts
|
||||
@end menu
|
||||
|
||||
@node News, Previous, Miscellaneous, Miscellaneous
|
||||
@section Using News distribution instead?
|
||||
|
||||
One correspondent thinks that perhaps the news distribution mechanism
|
||||
could be pressed into service for this job. I could have started
|
||||
from C-news, say, instead of from scratch, and have progressively
|
||||
bent C-news to behave like I wanted.
|
||||
|
||||
My feeling is that the route was shorter as I did it, from scratch,
|
||||
that it would have been from C-news. Of course, I could have
|
||||
removed the heavy administrative details of C-news: the history and
|
||||
@code{expire}, the daemons, the @code{cron} entries, etc., then added
|
||||
the interactive features and specialized behaviors, but all this clean
|
||||
up would certainly have took energies. Right now, non counting the
|
||||
subsidiary scripts and shar/unshar sources, the heart of the result
|
||||
is a single (1200 lines) script written in Perl, which I find fairly
|
||||
more smaller and maintainable than a patched C-news distribution
|
||||
would have been.
|
||||
|
||||
@node Previous, , News, Miscellaneous
|
||||
@section Documentation for obsolete scripts
|
||||
|
||||
This is merely a place holder for previous documentation, waiting that I
|
||||
clean it up. You have no interest in reading further down.
|
||||
|
||||
@menu
|
||||
* mailsync:: mailsync
|
||||
* resync:: resync
|
||||
@end menu
|
||||
|
||||
@node mailsync, resync, Previous, Previous
|
||||
@subsection mailsync
|
||||
|
||||
@example
|
||||
Usage: mailsync [ OPTION ] ... [ EMAIL_ADDRESS ] [ DIRECTORY ]
|
||||
or: mailsync [ OPTION ] ... SYNC_DIRECTORY
|
||||
@end example
|
||||
|
||||
Option -i simply sends a @code{ihave} package, with no bulk files.
|
||||
Option -n inhibits any destructive operation and mailing.
|
||||
|
||||
In the first form of the call, find a synchronisation directory in
|
||||
DIRECTORY aimed towards some EMAIL_ADDRESS, then proceed with this
|
||||
synchronisation directory. EMAIL_ADDRESS may be the name of a file
|
||||
containing a distribution list. If EMAIL_ADDRESS is not specified,
|
||||
all the synchronisation directories at the top level in DIRECTORY are
|
||||
processed in turn. If DIRECTORY is not specified, the current
|
||||
directory is used.
|
||||
|
||||
In the second form of the call, proceed only with the given
|
||||
synchronisation directory SYNC_DIRECTORY.
|
||||
|
||||
For proceeding with a synchronisation directory, whatever the form of
|
||||
the call was, this script reads the @code{ident} files it contains to set
|
||||
the local user and directory and the remote user and directory. Then,
|
||||
selected files under the local directory which are modified in regard
|
||||
to the corresponding files in the remote directory are turned into a
|
||||
synchronisation package which is mailed to the remote user.
|
||||
|
||||
The list of selected files or directories to synchronize from the
|
||||
local directory are given in the @code{list} file in the synchronisation
|
||||
directory. If this @code{list} file is missing, all files under the
|
||||
local directory are synchronized.
|
||||
|
||||
What I usually do is to @code{cd} at the top of the directory tree to be
|
||||
synchronized, then to type @code{mailsync} without parameters. This will
|
||||
automatically prepare as many synchronisation packages as there are
|
||||
mirror systems, then email multipart shars to each of them. Note that
|
||||
the synchronisation package is not identical for each mirror system,
|
||||
because they do not usually have the same state of synchronisation.
|
||||
|
||||
@code{mailsync} will refuse to work if anything needs to be hand cleaned
|
||||
from a previous execution of @code{mailsync} or @code{resync}. Check
|
||||
for some remaining @file{_syncbulk} or @file{_synctemp} directory, or
|
||||
for a @file{_syncrm} script.
|
||||
|
||||
@example
|
||||
TODO:
|
||||
- interrogate the user if @file{ident} file missing.
|
||||
- automatically construct the local user address.
|
||||
- create the synchronisation directory on the fly.
|
||||
- avoid duplicating work as far as possible for multiple sends.
|
||||
- have a quicker mode, depending on stamps, not on checksums.
|
||||
- never send core, executables, backups, @file{.nsf*}, @file{*/_synctemp/*}, etc.
|
||||
@end example
|
||||
|
||||
@node resync, , mailsync, Previous
|
||||
@subsection resync
|
||||
|
||||
@example
|
||||
Usage: resync [ OPTION ]... TAR_FILE
|
||||
or: resync [ OPTION ]... UNTARED_DIRECTORY
|
||||
@end example
|
||||
|
||||
Given a tar file produced by mailsync at some remote end and already
|
||||
reconstructed on this end using unshar, or a directory containing the
|
||||
already untared invoice, apply the synchronization package locally.
|
||||
|
||||
Option -n inhibits destroying or creating files, but does everything
|
||||
else. It will in particular create a synchronization directory if
|
||||
necessary, produce the @file{_syncbulk} directory and the @file{_syncrm}
|
||||
script.
|
||||
|
||||
The synchronization directory for the package is automatically
|
||||
retrieved or, if not found, created and initialized. @code{resync} keeps
|
||||
telling you what it is doing.
|
||||
|
||||
There are a few cases when a resync should not complete without manual
|
||||
intervention. The common case is that several sites update the very
|
||||
same files differently since they were last resync'ed, and then
|
||||
mailsync to each other. The prerequisite checksum will then fail, and
|
||||
the files are then kept into the @file{_syncbulk} tree, which has a shape
|
||||
similar to the directory tree in which the files where supposed to go.
|
||||
For GNU Emacs users, a very handy package, called emerge, written by
|
||||
Dale Worley <drw@@kutta.mit.edu>, helps reconciling two files
|
||||
interactiveley. The @file{_syncbulk} tree should be explicitely deleted
|
||||
after the hand synchronisation.
|
||||
|
||||
Another case of human intervention is when files are deleted at the
|
||||
mailsync'ing site. By choice, all deletions on the receiving side are
|
||||
accumulated in a @file{_syncrm} script, which is not executed automatically.
|
||||
Explicitely executed, @file{_syncrm} will remove any file in the receiving
|
||||
tree which does not exist anymore on the sender system. I often edit
|
||||
@file{_syncrm} before executing it, to remove the unwanted deletions (beware
|
||||
the double negation :-). The script removes itself.
|
||||
|
||||
All the temporary files, while resynchronizing, are held in @file{_synctemp},
|
||||
which is deleted afterwards; if something goes wrong, this directory
|
||||
should also be cleaned out by hand. @code{resync} will refuse to work if
|
||||
anything remains to be hand cleaned.
|
||||
|
||||
@display
|
||||
TODO:
|
||||
- interrogates the user if missing receiving directory in @file{ident}.
|
||||
- allow @file{remote.sum} to be empty or non-existent.
|
||||
@end display
|
||||
|
||||
@contents
|
||||
@bye
|
||||
|
||||
@c Local Variables:
|
||||
@c texinfo-column-for-description: 24
|
||||
@c End:
|
||||
@@ -0,0 +1,243 @@
|
||||
.TH SHAR 1 "September 10, 1995"
|
||||
.SH NAME
|
||||
shar \- create shell archives
|
||||
.SH SYNOPSIS
|
||||
.nf
|
||||
shar [ options ] file ...
|
||||
shar \-S [ options ]
|
||||
.fi
|
||||
.SH DESCRIPTION
|
||||
Shar
|
||||
creates "shell archives" (or shar files) which are in text format
|
||||
and can be mailed. These files may be unpacked later by executing them
|
||||
with /bin/sh. The resulting archive is sent to standard out unless the
|
||||
\f2\-o\f1 option is given. A wide range of features provide extensive
|
||||
flexibility in manufacturing shars and in specifying shar "smartness".
|
||||
Archives may be "vanilla" or comprehensive.
|
||||
.SH OPTIONS
|
||||
.PP
|
||||
Options have a one letter version starting with \- or a long version starting
|
||||
with \-\-. The exception is \f2\-\-help\f1, \f2\-\-version\f1,
|
||||
\f2\-\-no-i18n\f1 and \f2\-\-print-text-domain-dir\f1 which does not
|
||||
have short versions.
|
||||
Mandatory arguments to long options are mandatory for short options too.
|
||||
Options can be given in any order. Some options depend on each other:
|
||||
.nf
|
||||
The \f2\-o\f1 option is required if the \f2\-l\f1 or \f2\-L\f1 option is used.
|
||||
The \f2\-n\f1 option is required if the \f2\-a\f1 option is used.
|
||||
See \f2\-V\f1 below.
|
||||
.fi
|
||||
.SS "Giving feedback:"
|
||||
.IP "\f2\-\-help\f1"
|
||||
Print a help summary on standard output, then immediately exits.
|
||||
.IP "\f2\-\-version\f1"
|
||||
Print the version number of the program on standard output,
|
||||
then immediately exits.
|
||||
.IP "\f2\-q\f1 \f2\-\-quiet\f1 \f2\-\-silent\f1"
|
||||
Do not output verbose messages locally when producing the archive.
|
||||
.SS "Selecting files:"
|
||||
.IP "\f2\-p\f1 \f2\-\-intermix-type\f1"
|
||||
Allow positional parameter options. The options \f2\-B\f1, \f2\-T\f1,
|
||||
\f2-z\f1 and \f2\-Z\f1 may be embedded, and files to the right of the
|
||||
option will be processed in the specified mode.
|
||||
.IP "\f2\-S\f1 \f2\-\-stdin-file-list\f1"
|
||||
Read list of files to be packed from the standard input rather
|
||||
than from the command line. Input must be in a form similar to
|
||||
that generated by the find command, one filename per line. This
|
||||
switch is especially useful when the command line will not hold
|
||||
the list of files to be packed. For example:
|
||||
.nf
|
||||
|
||||
find . \-type f \-print | sort | shar \-S \-Z \-L50 \-o /tmp/big
|
||||
|
||||
.fi
|
||||
If \f2\-p\f1 is specified on the command line, then the options
|
||||
\f2\-B\f1, \f2\-T\f1, \f2\-z\f1 and \f2\-Z\f1 may be
|
||||
included in the standard input (on a line separate from filenames).
|
||||
The maximum number of lines of standard input, file names and
|
||||
options, may not exceed 1024.
|
||||
.SS "Splitting output:"
|
||||
.IP "\f2\-o\f1 XXX \f2\-\-output-prefix=\f1XXX"
|
||||
Save the archive to files XXX.01 thru XXX.nn instead of sending it to
|
||||
standard out.
|
||||
Must be used when the \f2\-l\f1 or the \f2\-L\f1 switches are used.
|
||||
.IP "\f2\-l\f1 XX \f2\-\-whole-size-limit=\f1XX"
|
||||
Limit the output file size to XXk bytes but don't split input files.
|
||||
.IP "\f2\-L\f1 XX \f2\-\-split-size-limit=\f1XX"
|
||||
Limit output file size to XXk bytes and split files if necessary. The archive
|
||||
parts created with this option must be unpacked in correct order.
|
||||
.SS "Controlling the shar headers:"
|
||||
.IP "\f2\-n\f1 name \f2\-\-archive-name=\f1name"
|
||||
Name of archive to be included in the header of the shar files.
|
||||
See the \f2\-a\f1 switch.
|
||||
.IP "\f2\-s\f1 who@where \f2\-\-submitter=\f1who@where"
|
||||
Override automatically determined submitter name.
|
||||
.IP "\f2\-a\f1 \f2\-\-net-headers\f1"
|
||||
Allows automatic generation of headers:
|
||||
.nf
|
||||
Submitted-by: who@where
|
||||
Archive-name: <name>/part##
|
||||
.fi
|
||||
The <name> must be given with the \f2\-n\f1 switch.
|
||||
If name includes a '/' "/part" isn't used. Thus:
|
||||
.RS 10m
|
||||
.nf
|
||||
.ta 30n
|
||||
\-n xyzzy produces:
|
||||
xyzzy/part01
|
||||
xyzzy/part02
|
||||
|
||||
\-n xyzzy/patch produces:
|
||||
xyzzy/patch01
|
||||
xyzzy/patch02
|
||||
|
||||
\-n xyzzy/patch01. produces:
|
||||
xyzzy/patch01.01
|
||||
xyzzy/patch01.02
|
||||
.RE
|
||||
.fi
|
||||
.IP ""
|
||||
The who@where can be
|
||||
explicitly stated with the \f2\-s\f1 switch if the default isn't appropriate.
|
||||
Who@where is essentially built as `whoami`@`uname`.
|
||||
.IP "\f2\-c\f1 \f2\-\-cut-mark\f1"
|
||||
Start the shar with a cut line. A line saying 'Cut here' is placed at the
|
||||
start of each output file.
|
||||
.SS "Selecting how files are stocked:"
|
||||
.IP "\f2\-M\f1 \f2\-\-mixed-uuencode\f1"
|
||||
Mixed mode. Determine if the files are text or binary and archive
|
||||
correctly (default). Files found to be binary are uudecoded prior to packing
|
||||
(USE OF UUENCODE IS NOT APPRECIATED BY MANY ON THE NET).
|
||||
.IP "\f2\-T\f1 \f2\-\-text-files\f1"
|
||||
Treat all files as text.
|
||||
.IP "\f2\-B\f1 \f2\-\-uuencode\f1"
|
||||
Treat all files as binary, use uuencode prior to packing. This increases the
|
||||
size of the archive. The recipient must have uudecode in order to unpack.
|
||||
(USE OF UUENCODE IS NOT APPRECIATED BY MANY ON THE NET).
|
||||
.IP "\f2\-z\f1 \f2\-\-gzip\f1"
|
||||
Gzip and uuencode all files prior to packing. The recipient must have
|
||||
uudecode and gzip in order to unpack
|
||||
(USE OF UUENCODE AND GZIP IS NOT APPRECIATED BY MANY ON THE NET).
|
||||
.IP "\f2\-g\f1 LEVEL \f2\-\-level-for-gzip=\f1LEVEL"
|
||||
When doing compression, use '\-LEVEL' as a parameter to gzip. Default is 9.
|
||||
The \f2\-g\f1 option turns on the \f2\-z\f1 option by default.
|
||||
.IP "\f2\-Z\f1 \f2\-\-compress\f1"
|
||||
Compress and uuencode all files prior to packing. The recipient must have
|
||||
uudecode and compress in order to unpack
|
||||
(USE OF UUENCODE AND COMPRESS IS NOT APPRECIATED BY MANY ON THE NET).
|
||||
Option \f2\-C\f1 is synonymous to \f2\-Z\f1, but is being deprecated.
|
||||
.IP "\f2\-b\f1 BITS \f2\-\-bits-per-code=\f1BITS"
|
||||
When doing compression, use '\-bBITS' as a parameter to compress.
|
||||
The \f2\-B\f1 option turns on the \f2\-Z\f1 option by default. Default value
|
||||
is 12.
|
||||
.SS "Protecting against transmission errors:"
|
||||
.IP "\f2\-w\f1 \f2\-\-no-character-count\f1"
|
||||
Do NOT check each file with 'wc \-c' after unpack. The default is to check.
|
||||
.IP "\f2\-D\f1 \f2\-\-no-md5-digest\f1"
|
||||
Do NOT use 'md5sum' digest to verify the unpacked files. The default is to
|
||||
check.
|
||||
.IP "\f2\-F\f1 \f2\-\-force-prefix\f1"
|
||||
Forces the prefix character (normally 'X' unless the parameter to the \f2\-d\f1
|
||||
option starts with 'X') to be prepended to every line even if
|
||||
not required. This option may slightly increase the size of the archive,
|
||||
especially if \f2\-B\f1 or \f2\-Z\f1 is used.
|
||||
.IP "\f2\-d\f1 XXX \f2\-\-here-delimiter=\f1XXX"
|
||||
Use XXX to delimit the files in the shar instead of SHAR_EOF.
|
||||
This is for those who want to personalize their shar files.
|
||||
.SS "Producing different kinds of shars:"
|
||||
.IP "\f2\-V\f1 \f2\-\-vanilla-operation\f1"
|
||||
Produce "vanilla" shars which rely only upon the existence of sed and
|
||||
echo in the unsharing environment. In addition, "if test" must also
|
||||
be supported unless the \f2\-x\f1 option is used. The \f2\-V\f1 silently
|
||||
disables options offensive to the "network cop" (or "brown shirt"),
|
||||
but does warn you if it is specified with \f2\-B\f1, \f2-z\f1,
|
||||
\f2\-Z\f1, \f2\-p\f1 or \f2\-M\f1 (any of which does or might
|
||||
require uudecode, gzip or compress in the unsharing environment).
|
||||
.IP "\f2\-P\f1 \f2\-\-no-piping\f1"
|
||||
Use temporary files instead of pipes in the shar file.
|
||||
.IP "\f2\-x\f1 \f2\-\-no-check-existing\f1"
|
||||
Overwrite existing files without checking.
|
||||
If neither \f2\-x\f1 nor \f2\-X\f1 is specified, the unpack will
|
||||
check for and not overwrite existing files when unpacking the archive.
|
||||
If \f2\-c\f1 is passed as a parameter to the script when unpacking:
|
||||
|
||||
.RS 10m
|
||||
sh archive -c
|
||||
.RE
|
||||
.IP ""
|
||||
then existing files will be overwritten unconditionally.
|
||||
.IP "\f2\-X\f1 \f2\-\-query-user\f1"
|
||||
When unpacking, interactively ask the user if files should be overwritten.
|
||||
(DO NOT USE FOR SHARS SUBMITTED TO THE NET).
|
||||
.IP "\f2\-m\f1 \f2\-\-no-timestamp\f1"
|
||||
Avoid generating 'touch' commands to restore the file modification
|
||||
dates when unpacking files from the archive.
|
||||
.IP "\f2\-Q\f1 \f2\-\-quiet-unshar\f1"
|
||||
Verbose OFF. Disables the inclusion of comments to be output when the archive
|
||||
is unpacked.
|
||||
.IP "\f2\-f\f1 \f2\-\-basename\f1"
|
||||
Restore by filename only, rather than path. This option causes only file
|
||||
names to be used, which is useful when building a shar from several
|
||||
directories, or another directory. Note that if a directory name is passed
|
||||
to shar, the substructure of that directory will be restored whether \f2\-f\f1
|
||||
is specified or not.
|
||||
.SS "Internationalization:"
|
||||
.IP "\f2\-\-no-i18n\f1"
|
||||
Do not produce internationalized shell archives, use default english messages.
|
||||
By default, shar produces archives that will try to output messages in
|
||||
the unpackers preferred language (as determined by the LANG/LC_MESSAGES
|
||||
environmental variables) when they are unpacked.
|
||||
If no message file for the unpackers language is found at unpack time,
|
||||
messages will be in english.
|
||||
.IP "\f2\-\-print-text-domain-dir\f1"
|
||||
Prints the directory shar looks in to find messages files for different
|
||||
languages, then immediately exits.
|
||||
.SH EXAMPLES
|
||||
.nf
|
||||
.ta 37n
|
||||
shar *.c > cprog.shar # all C prog sources
|
||||
shar \-Q *.[ch] > cprog.shar # non-verbose, .c and .h files
|
||||
shar \-B \-l28 \-oarc.sh *.arc # all binary .arc files, into
|
||||
# files arc.sh.01 thru arc.sh.NN
|
||||
shar \-f /lcl/src/u*.c > u.sh # use only the filenames
|
||||
.ta
|
||||
.fi
|
||||
.SH WARNINGS
|
||||
.PP
|
||||
No chmod or touch is ever generated for directories created when unpacking.
|
||||
Thus, if a directory is given to shar, the protection and
|
||||
modification dates of corresponding unpacked directory
|
||||
may not match those of the original.
|
||||
.PP
|
||||
If a directory is passed to shar, it may be scanned more than once. Therefore,
|
||||
one should be careful not change the directory while shar is running.
|
||||
.PP
|
||||
Be careful that the output file(s) are not included in the inputs or shar
|
||||
may loop until the disk fills up. Be particularly careful when a directory
|
||||
is passed to shar that the output files are not in that directory
|
||||
(or a subdirectory of that directory).
|
||||
.PP
|
||||
Use of the \f2\-B\f1, \f2\-z\f1 or \f2\-Z\f1, and especially
|
||||
\f2\-M\f1, may slow the archive process considerably, depending on
|
||||
the number of files.
|
||||
.PP
|
||||
Use of \f2\-X\f1 produces shars which \f2WILL\f1 cause problems
|
||||
with many unshar procedures. Use this feature only for archives
|
||||
to be passed among agreeable parties. Certainly, \f2\-X\f1 is NOT
|
||||
for shell archives which are to be submitted to Usenet. Usage of
|
||||
\f2\-B\f1, \f2\-z\f1 or \f2\-Z\f1 in net shars will cause you to
|
||||
be flamed off the earth. Not using \f2\-m\f1 or not using \f2\-F\f1
|
||||
may also get you occasional complaints.
|
||||
.SH SEE ALSO
|
||||
.PP
|
||||
unshar(1)
|
||||
.SH DIAGNOSTICS
|
||||
.PP
|
||||
Error messages for illegal or incompatible options,
|
||||
for non-regular, missing or inaccessible files or for (unlikely)
|
||||
memory allocation failure.
|
||||
.SH AUTHORS
|
||||
The shar and unshar programs is the collective work of many authors.
|
||||
Many people contributed by reporting problems, suggesting
|
||||
various improvements or submitting actual code. A list of
|
||||
these people is in the THANKS file in the sharutils distribution.
|
||||
@@ -0,0 +1,578 @@
|
||||
This is Info file sharutils.info, produced by Makeinfo-1.63 from the
|
||||
input file sharutils.texi.
|
||||
|
||||
START-INFO-DIR-ENTRY
|
||||
* Shar utilities: (sharutils). GNU shar utilities.
|
||||
* mail-files: (sharutils)mail-files invocation. Send files to remote site.
|
||||
* mailshar: (sharutils)mailshar invocation. Make and send a shell archive.
|
||||
* remsync: (sharutils)remsync invocation. Synchronize remote files.
|
||||
* shar: (sharutils)shar invocation. Make a shell archive.
|
||||
* unshar: (sharutils)unshar invocation. Explode a shell archive.
|
||||
* uudecode: (sharutils)uudecode invocation. Restore file from 7-bits.
|
||||
* uuencode: (sharutils)uuencode invocation. Force binary file to 7-bits.
|
||||
END-INFO-DIR-ENTRY
|
||||
|
||||
This file documents the GNU set of shar utilities.
|
||||
|
||||
Copyright (C) 1994 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of this
|
||||
manual provided the copyright notice and this permission notice are
|
||||
preserved on all copies.
|
||||
|
||||
Permission is granted to copy and distribute modified versions of
|
||||
this manual under the conditions for verbatim copying, provided that
|
||||
the entire resulting derived work is distributed under the terms of a
|
||||
permission notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this
|
||||
manual into another language, under the above conditions for modified
|
||||
versions, except that this permission notice may be stated in a
|
||||
translation approved by the Foundation.
|
||||
|
||||
|
||||
File: sharutils.info, Node: Top, Next: Introduction, Prev: (dir), Up: (dir)
|
||||
|
||||
GNU `shar' utilities
|
||||
********************
|
||||
|
||||
GNU `shar' makes so-called shell archives out of many files,
|
||||
preparing them for transmission by electronic mail services. GNU
|
||||
`unshar' helps unpacking shell archives after reception. This is
|
||||
release 4.1.9.
|
||||
|
||||
* Menu:
|
||||
|
||||
* Introduction:: Introduction to both programs
|
||||
* shar invocation:: Invoking the `shar' program
|
||||
* unshar invocation:: Invoking the `unshar' program
|
||||
* Miscellaneous:: Miscellaneous considerations
|
||||
|
||||
-- The Detailed Node Listing --
|
||||
|
||||
Creating shell archives
|
||||
|
||||
* Selecting:: Selecting files
|
||||
* Splitting:: Splitting output
|
||||
* Headers:: Controlling the shar headers
|
||||
* Stocking:: Selecting how files are stocked
|
||||
* Transmission:: Protecting against transmission
|
||||
* Kinds:: Producing different kinds of shar
|
||||
|
||||
|
||||
File: sharutils.info, Node: Introduction, Next: shar invocation, Prev: Top, Up: Top
|
||||
|
||||
Introduction to both programs
|
||||
*****************************
|
||||
|
||||
GNU `shar' makes so-called shell archives out of many files,
|
||||
preparing them for transmission by electronic mail services. A "shell
|
||||
archive" is a collection of files that can be unpacked by `/bin/sh'. A
|
||||
wide range of features provide extensive flexibility in manufacturing
|
||||
shars and in specifying shar *smartness*. For example, `shar' may
|
||||
compress files, uuencode binary files, split long files and construct
|
||||
multi-part mailings, ensure correct unsharing order, and provide
|
||||
simplistic checksums. *Note shar invocation::.
|
||||
|
||||
GNU `unshar' scans a set of mail messages looking for the start of
|
||||
shell archives. It will automatically strip off the mail headers and
|
||||
other introductory text. The archive bodies are then unpacked by a
|
||||
copy of the shell. `unshar' may also process files containing
|
||||
concatenated shell archives. *Note unshar invocation::.
|
||||
|
||||
GNU `shar' has a long history. All along this long road, numerous
|
||||
users contributed various improvements. The file `THANKS', from the
|
||||
GNU `shar' distribution, contain all names still having valid email
|
||||
addresses, as far as we know.
|
||||
|
||||
Please help me getting the history straight, for the following
|
||||
information is approximative. James Gosling wrote the public domain
|
||||
`shar 1.x'. William Davidsen rewrote it as `shar 2.x'. Warren Tucker
|
||||
brought modifications and called it `shar 3.x'. Richard Gumpertz
|
||||
maintained it until 1990. Franc,ois Pinard, from the public domain
|
||||
`shar 3.49', made `GNU shar 4.x', in 1994. Some modules and other code
|
||||
sections were freely borrowed from other GNU distributions, bringing
|
||||
this `shar' under the terms of the GNU General Public License.
|
||||
|
||||
Your feedback helps us to make a better and more portable product.
|
||||
Mail suggestions and bug reports (including documentation errors) for
|
||||
these programs to `[email protected]'.
|
||||
|
||||
|
||||
File: sharutils.info, Node: shar invocation, Next: unshar invocation, Prev: Introduction, Up: Top
|
||||
|
||||
Invoking the `shar' program
|
||||
***************************
|
||||
|
||||
The format of the `shar' command is one of:
|
||||
|
||||
shar [ OPTION ] ... FILE ...
|
||||
shar -S [ OPTION ] ...
|
||||
|
||||
In the first form, the file list is given as command arguments. In
|
||||
the second form, the file list is read from standard input. The
|
||||
resulting archive is sent to standard output unless the `-o' option is
|
||||
given.
|
||||
|
||||
Options can be given in any order. Some options depend on each
|
||||
other: the `-o' option is required if the `-l' or `-L' option is used.
|
||||
The `-n' option is required if the `-a' option is used. Also see `-V'
|
||||
below.
|
||||
|
||||
Some options are special purpose:
|
||||
|
||||
`--help'
|
||||
Print a help summary on standard output, then immediately exits.
|
||||
|
||||
`--version'
|
||||
Print the version number of the program on standard output, then
|
||||
immediately exits.
|
||||
|
||||
`-q'
|
||||
`--quiet'
|
||||
Verbose *off* at `shar' time. Messages are usually issued on
|
||||
standard error to let the user follow the progress, while making
|
||||
the archives. This option inhibits these messages.
|
||||
|
||||
* Menu:
|
||||
|
||||
* Selecting:: Selecting files
|
||||
* Splitting:: Splitting output
|
||||
* Headers:: Controlling the shar headers
|
||||
* Stocking:: Selecting how files are stocked
|
||||
* Transmission:: Protecting against transmission
|
||||
* Kinds:: Producing different kinds of shar
|
||||
|
||||
|
||||
File: sharutils.info, Node: Selecting, Next: Splitting, Prev: shar invocation, Up: shar invocation
|
||||
|
||||
Selecting files
|
||||
===============
|
||||
|
||||
`-p'
|
||||
`--intermix-type'
|
||||
Allow positional parameter options. The options `-M', `-B', `-T',
|
||||
`-z' and `-Z' may be embedded, and files to the right of the
|
||||
option will be processed in the specified mode. Without the `-p'
|
||||
option, embedded options would be interpreted as file names.
|
||||
*Note Stocking:: for more information on these options.
|
||||
|
||||
`-S'
|
||||
`--stdin-file-list'
|
||||
Read list of files to be packed from the standard input rather
|
||||
than from the command line. Input must be one file name per line.
|
||||
This switch is especially useful when the command line will not
|
||||
hold the list of files to be packed. For example:
|
||||
|
||||
find . -type f -print | shar -S -o /tmp/big.shar
|
||||
|
||||
If `-p' is specified on the command line, then the options `-M',
|
||||
`-B', `-T', `-z' and `-Z' may be included in the standard input
|
||||
(on a line separate from file names). The maximum number of lines
|
||||
of standard input, file names and options, may not exceed 1024.
|
||||
|
||||
|
||||
File: sharutils.info, Node: Splitting, Next: Headers, Prev: Selecting, Up: shar invocation
|
||||
|
||||
Splitting output
|
||||
================
|
||||
|
||||
`-o PREFIX'
|
||||
`--output-prefix=PREFIX'
|
||||
Save the archive to files `PREFIX.01' through `PREFIX.NNN' instead
|
||||
of standard output. This option *must* be used when the `-l' or
|
||||
the `-L' switches are used.
|
||||
|
||||
When PREFIX contains any `%' character, PREFIX is then interpreted
|
||||
as a `sprintf' format, which should be able to display a single
|
||||
decimal number. When PREFIX does not contain such a `%'
|
||||
character, the string `.%02d' is internally appended.
|
||||
|
||||
`-l SIZE'
|
||||
`--whole-size-limit=SIZE'
|
||||
Limit the output file size to SIZE times 1024 bytes but don't
|
||||
split input files. This allows the recipient of the shell archives
|
||||
to unpack them in any order.
|
||||
|
||||
`-L SIZE'
|
||||
`--split-size-limit=SIZE'
|
||||
Limit output file size to SIZE times 1024 bytes and split files if
|
||||
necessary. The archives created with this option must be unpacked
|
||||
in the correct order. If the recipient of the shell archives
|
||||
wants to put all of them in a single folder, she shall save them
|
||||
in the correct order for `unshar', used with option `-e', to
|
||||
unpack them all at once. *Note unshar invocation::.
|
||||
|
||||
For people used to saving all the shell archives into a single mail
|
||||
folder, care must be taken to save them in the appropriate order.
|
||||
For those having the appropriate tools (like Masanobu Umeda's
|
||||
`rmailsort' package for GNU Emacs), shell archives can be saved in
|
||||
any order, then sorted by increasing date (or send time) before
|
||||
massive unpacking.
|
||||
|
||||
|
||||
File: sharutils.info, Node: Headers, Next: Stocking, Prev: Splitting, Up: shar invocation
|
||||
|
||||
Controlling the shar headers
|
||||
============================
|
||||
|
||||
`-n NAME'
|
||||
`--archive-name=NAME'
|
||||
Name of archive to be included in the header of the shar files.
|
||||
Also see the `-a' switch further down.
|
||||
|
||||
`-s ADDRESS'
|
||||
`--submitter=ADDRESS'
|
||||
The `-s' option allows for overriding the email address for the
|
||||
submitter, for when the default is not appropriate. The
|
||||
automatically determined address looks like `USERNAME@HOSTNAME'.
|
||||
|
||||
`-a'
|
||||
`--net-headers'
|
||||
Allows automatic generation of headers:
|
||||
|
||||
Submitted-by: ADDRESS
|
||||
Archive-name: NAME/partNN
|
||||
|
||||
The NAME must be given with the `-n' switch. If name includes a
|
||||
`/', then `/part' isn't used. Thus `-n xyzzy' produces:
|
||||
xyzzy/part01
|
||||
xyzzy/part02
|
||||
|
||||
while `-n xyzzy/patch' produces:
|
||||
xyzzy/patch01
|
||||
xyzzy/patch02
|
||||
|
||||
and `-n xyzzy/patch01.' produces:
|
||||
xyzzy/patch01.01
|
||||
xyzzy/patch01.02
|
||||
|
||||
`-c'
|
||||
`--cut-mark'
|
||||
Start the shar with a cut line. A line saying `Cut here' is
|
||||
placed at the start of each output file.
|
||||
|
||||
|
||||
File: sharutils.info, Node: Stocking, Next: Transmission, Prev: Headers, Up: shar invocation
|
||||
|
||||
Selecting how files are stocked
|
||||
===============================
|
||||
|
||||
`-T'
|
||||
`--text-files'
|
||||
Treat all files as text, regardless of their contents.
|
||||
|
||||
`-B'
|
||||
`--uuencode'
|
||||
Treat all files as binary, use `uuencode' prior to packing. This
|
||||
increases the size of the archive. The recipient must have
|
||||
`uudecode' in order to unpack.
|
||||
|
||||
Use of `uuencode' is not appreciated by many on the net, because
|
||||
people like to readily see, by mere inspection of a shell archive,
|
||||
what it is about.
|
||||
|
||||
`-M'
|
||||
`--mixed-uuencode'
|
||||
Mixed mode. Automatically determine if the files are text or
|
||||
binary and archive correctly. Files found to be binary are
|
||||
uuencoded prior to packing. This option is selected by default.
|
||||
|
||||
For a file is considered to be a text file, instead of a binary
|
||||
file, all the following should be true simultaneously:
|
||||
1. The file does not contain any ASCII control character besides
|
||||
BS (backspace), HT (horizontal tab), LF (new line) or FF
|
||||
(form feed).
|
||||
|
||||
2. The file does not contains a DEL (delete).
|
||||
|
||||
3. The file contains no character with its eighth-bit set.
|
||||
|
||||
4. The file, unless totally empty, terminates with a LF
|
||||
(newline).
|
||||
|
||||
5. No line in the file contains more than 200 characters. For
|
||||
counting purpose, lines are separated by a LF (newline).
|
||||
|
||||
`-z'
|
||||
`--gzip'
|
||||
Use `gzip' and `uuencode' on all files prior to packing. The
|
||||
recipient must have `uudecode' and `gzip' (used with `-d') in
|
||||
order to unpack.
|
||||
|
||||
Usage of `-z' in net shars will cause you to be flamed off the
|
||||
earth.
|
||||
|
||||
`-g LEVEL'
|
||||
`--level-for-gzip=LEVEL'
|
||||
When doing compression, use `-LEVEL' as a parameter to `gzip'.
|
||||
The `-g' option turns on the `-z' option by default. The default
|
||||
value is 9, that is, maximum compression.
|
||||
|
||||
`-Z'
|
||||
`--compress'
|
||||
Use `compress' and `uuencode' on all files prior to packing. The
|
||||
recipient must have `uudecode' and `compress' (used with `-d') in
|
||||
order to unpack. Option `-C' is a synonymous for `-Z', but is
|
||||
deprecated.
|
||||
|
||||
Usage of `-Z' in net shars will cause you to be flamed off the
|
||||
earth.
|
||||
|
||||
`-b BITS'
|
||||
`--bits-per-code=BITS'
|
||||
When doing compression, use `-bX' as a parameter to `compress'.
|
||||
The `-B' option turns on the `-Z' option by default. The default
|
||||
value is 12, foreseeing the memory limitations of some `compress'
|
||||
programs on smallish systems, at `unshar' time.
|
||||
|
||||
|
||||
File: sharutils.info, Node: Transmission, Next: Kinds, Prev: Stocking, Up: shar invocation
|
||||
|
||||
Protecting against transmission errors
|
||||
======================================
|
||||
|
||||
Transmission of shell archives is not always free of errors. So one
|
||||
should make consistency checks on the receiving site. A very simple
|
||||
(and unreliable) method is running the UNIX `wc' tool on the output
|
||||
file. This can report the number of characters in the file.
|
||||
|
||||
As one can guess this does not catch all errors. Especially
|
||||
changing of a character value does not change the computed check sum.
|
||||
To achieve this goal better method were invented and standardized. One
|
||||
very strong is MD5 (MD = message digests). This is standardized in RFC
|
||||
1321. The produced shell scripts do not force the `md5sum' program to
|
||||
be installed on the system. This is necessary because it is not yet
|
||||
part of every UNIX. The program is however not necessary for producing
|
||||
the shell archive.
|
||||
|
||||
`-w'
|
||||
`--no-character-count'
|
||||
Do *not* check with `wc -c' after unpack. The default is to check.
|
||||
|
||||
`-D'
|
||||
`--no-md5-digest'
|
||||
Do *not* check with `md5sum' after unpack. The default is to
|
||||
check.
|
||||
|
||||
`-F'
|
||||
`--force-prefix'
|
||||
Prepend the prefix character to every line even if not required.
|
||||
This option may slightly increase the size of the archive,
|
||||
especially if `-B' or `-Z' is used. Normally, the prefix character
|
||||
is `X'. If the parameter to the `-d' option starts with `X', then
|
||||
the prefix character becomes `Y'.
|
||||
|
||||
`-d STRING'
|
||||
`--here-delimiter=STRING'
|
||||
Use STRING to delimit the files in the shar instead of `SHAR_EOF'.
|
||||
This is for those who want to personalize their shar files.
|
||||
|
||||
|
||||
File: sharutils.info, Node: Kinds, Prev: Transmission, Up: shar invocation
|
||||
|
||||
Producing different kinds of shars
|
||||
==================================
|
||||
|
||||
`-V'
|
||||
`--vanilla-operation'
|
||||
This option produces "vanilla" shars which rely only upon the
|
||||
existence of `echo', `test' and `sed' in the unpacking environment.
|
||||
|
||||
The `-V' disables options offensive to the "network cop" (or
|
||||
"brown shirt"). It also changes the default from mixed mode `-M'
|
||||
to text mode `-T'. Warnings are produced if option `-B', `-z',
|
||||
`-Z', `-p' or `-M' is specified (any of which does or might
|
||||
require `uudecode', `gzip' or `compress' in the unpacking
|
||||
environment).
|
||||
|
||||
`-P'
|
||||
`--no-piping'
|
||||
In the shar file, use a temporary file to hold the file to
|
||||
`uudecode', instead of using pipes. This option is mandatory when
|
||||
you know the unpacking `uudecode' is unwilling to merely read its
|
||||
standard input. Richard Marks wrote what is certainly the most
|
||||
(in)famous of these, for MSDOS :-).
|
||||
|
||||
(Here is a side note from the maintainer. Why isnt't this option
|
||||
the default? In the past history of `shar', it was decided that
|
||||
piping was better, surely because it is less demanding on disk
|
||||
space, and people seem to be happy with this. Besides, I think
|
||||
that the `uudecode' from Richard Marks, on MSDOS, is wrong in
|
||||
refusing to handle `stdin'. So far that I remember, he has the
|
||||
strong opinion that a program without any parameters should give
|
||||
its `--help' output. Besides that, should I say, his `uuencode'
|
||||
and `uudecode' programs are full-featured, one of the most
|
||||
complete set I ever saw. But Richard will not release his
|
||||
sources, he wants to stay in control.)
|
||||
|
||||
`-x'
|
||||
`--no-check-existing'
|
||||
Overwrite existing files without checking. If neither `-x' nor
|
||||
`-X' is specified, when unpacking itself, the shell archive will
|
||||
check for and not overwrite existing files (unless `-c' is passed
|
||||
as a parameter to the script when unpacking).
|
||||
|
||||
`-X'
|
||||
`--query-user'
|
||||
Interactively overwrite existing files.
|
||||
|
||||
Use of `-X' produces shars which *will* cause problems with some
|
||||
`unshar'-style procedures, particularily when used together with
|
||||
vanilla mode (`-V'). Use this feature mainly for archives to be
|
||||
passed among agreeable parties. Certainly, `-X' is *not* for
|
||||
shell archives which are to be submitted to Usenet or other public
|
||||
networks.
|
||||
|
||||
The problem is that `unshar' programs or procedures often feed
|
||||
`/bin/sh' from its standard input, thus putting `/bin/sh' and the
|
||||
shell archive script in competition for input lines. As an
|
||||
attempt to alleviate this problem, `shar' will try to detect if
|
||||
`/dev/tty' exists at the receiving site and will use it to read
|
||||
user replies. But this does not work in all cases, it may happen
|
||||
that the receiving user will have to avoid using `unshar' programs
|
||||
or procedures, and call `/bin/sh' directly. In vanilla mode,
|
||||
using `/dev/tty' is not even attempted.
|
||||
|
||||
`-m'
|
||||
`--no-timestamp'
|
||||
Avoid generating `touch' commands to restore the file modification
|
||||
dates when unpacking files from the archive.
|
||||
|
||||
When the timestamp relationship is not preserved, some files like
|
||||
`configure' or `*.info' may be uselessly remade after unpacking.
|
||||
This is why, when this option is not used, a special effort is
|
||||
made to restore timestamps,
|
||||
|
||||
`-Q'
|
||||
`--quiet-unshar'
|
||||
Verbose *off* at `unshar' time. Disables the inclusion of
|
||||
comments to be output when the archive is unpacked.
|
||||
|
||||
`-f'
|
||||
`--basename'
|
||||
Use only the last file name component of each input file name,
|
||||
ignoring any prefix directories. This is sometimes useful when
|
||||
building a shar from several directories, or another directory.
|
||||
If a directory name is passed to `shar', the substructure of that
|
||||
directory will be restored whether `-f' is specified or not.
|
||||
|
||||
|
||||
File: sharutils.info, Node: unshar invocation, Next: Miscellaneous, Prev: shar invocation, Up: Top
|
||||
|
||||
Invoking the `unshar' program
|
||||
*****************************
|
||||
|
||||
The format of the `unshar' command is:
|
||||
|
||||
unshar [ OPTION ] ... [ FILE ... ]
|
||||
|
||||
Each FILE is processed in turn, as a shell archive or a collection
|
||||
of shell archives. If no files are given, then standard input is
|
||||
processed instead.
|
||||
|
||||
Options:
|
||||
|
||||
`--version'
|
||||
Print the version number of the program on standard output, then
|
||||
immediately exits.
|
||||
|
||||
`--help'
|
||||
Print an help summary on standard output, then immediately exits.
|
||||
|
||||
`-d DIRECTORY'
|
||||
`--directory=DIRECTORY'
|
||||
Change directory to DIRECTORY before unpacking any files.
|
||||
|
||||
`-c'
|
||||
`--overwrite'
|
||||
`-f'
|
||||
`--force'
|
||||
Passed as an option to the shar file. Many shell archive scripts
|
||||
(including those produced by `shar' 3.40 and newer) accepts a `-c'
|
||||
argument to indicate that existing files should be overwritten.
|
||||
|
||||
The option `-f' is provided for a more unique interface. Many
|
||||
programs (such as `cp' and `mv') use this option to trigger the
|
||||
very same action.
|
||||
|
||||
`-e'
|
||||
`--exit-0'
|
||||
This option exists mainly for people who collect many shell
|
||||
archives into a single mail folder. With this option, `unshar'
|
||||
isolates each different shell archive from the others which have
|
||||
been put in the same file, unpacking each in turn, from the
|
||||
beginning of the file towards its end. Its proper operation
|
||||
relies on the fact that many shar files are terminated by a
|
||||
`exit 0' at the beginning of a line.
|
||||
|
||||
Option `-e' is internally equivalent to `-E "exit 0"'.
|
||||
|
||||
`-E STRING'
|
||||
`--split-at=STRING'
|
||||
This option works like `-e', but it allows you to specify the
|
||||
string that separates archives if `exit 0' isn't appropriate.
|
||||
|
||||
For example, noticing that most `.signatures' have a `--' on a
|
||||
line right before them, one can sometimes use `--split-at=--' for
|
||||
splitting shell archives which lack the `exit 0' line at end. The
|
||||
signature will then be skipped altogether with the headers of the
|
||||
following message.
|
||||
|
||||
|
||||
File: sharutils.info, Node: Miscellaneous, Prev: unshar invocation, Up: Top
|
||||
|
||||
Miscellaneous considerations
|
||||
****************************
|
||||
|
||||
Here is a place-holder for many considerations which do not fit
|
||||
elsewhere, while not worth a section for themselves.
|
||||
|
||||
Be careful that the output file(s) are not included in the inputs or
|
||||
`shar' may loop until the disk fills up. Be particularly careful when
|
||||
a directory is passed to `shar' that the output files are not in that
|
||||
directory (or a subdirectory of that directory).
|
||||
|
||||
When a directory is passed to `shar', it may be scanned more than
|
||||
once, to conserve memory. Therefore, one should be careful to not
|
||||
change the directory contents while `shar' is running.
|
||||
|
||||
No attempt is made to restore the protection and modification dates
|
||||
for directories, even if this is done by default for files. Thus, if a
|
||||
directory is given to `shar', the protection and modification dates of
|
||||
corresponding unpacked directory may not match those of the original.
|
||||
|
||||
Use of the `-M' or `-B' options will slow down the archive process.
|
||||
Use of the `-z' or `-Z' options may slow the archive process
|
||||
considerably.
|
||||
|
||||
Let us conclude by a showing a few examples of `shar' usage:
|
||||
|
||||
shar *.c > cprog.shar
|
||||
shar -Q *.[ch] > cprog.shar
|
||||
shar -B -l28 -oarc.sh. *.arc
|
||||
shar -f /lcl/src/u*.c > u.sh
|
||||
|
||||
The first shows how to make a shell archive out of all C program
|
||||
sources. The second produces a shell archive with all `.c' and `.h'
|
||||
files, which unpacks silently. The third gives a shell archive of all
|
||||
uuencoded `.arc' files, into files `arc.sh.01' through to `arc.sh.NNN'.
|
||||
The last example gives a shell archive which will use only the file
|
||||
names at unpack time.
|
||||
|
||||
|
||||
|
||||
Tag Table:
|
||||
Node: Top1489
|
||||
Node: Introduction2494
|
||||
Node: shar invocation4478
|
||||
Node: Selecting5980
|
||||
Node: Splitting7111
|
||||
Node: Headers8750
|
||||
Node: Stocking9915
|
||||
Node: Transmission12494
|
||||
Node: Kinds14174
|
||||
Node: unshar invocation18124
|
||||
Node: Miscellaneous20237
|
||||
|
||||
End Tag Table
|
||||
@@ -0,0 +1,657 @@
|
||||
\input texinfo
|
||||
@c %**start of header
|
||||
@setfilename sharutils.info
|
||||
@settitle GNU @code{shar} utilities
|
||||
@finalout
|
||||
@c %**end of header
|
||||
|
||||
@include version.texi
|
||||
|
||||
@ifinfo
|
||||
@set Francois Franc,ois
|
||||
@end ifinfo
|
||||
@tex
|
||||
@set Francois Fran\noexpand\ptexc cois
|
||||
@end tex
|
||||
|
||||
@ifinfo
|
||||
@format
|
||||
START-INFO-DIR-ENTRY
|
||||
* Shar utilities: (sharutils). GNU shar utilities.
|
||||
* mail-files: (sharutils)mail-files invocation. Send files to remote site.
|
||||
* mailshar: (sharutils)mailshar invocation. Make and send a shell archive.
|
||||
* remsync: (sharutils)remsync invocation. Synchronize remote files.
|
||||
* shar: (sharutils)shar invocation. Make a shell archive.
|
||||
* unshar: (sharutils)unshar invocation. Explode a shell archive.
|
||||
* uudecode: (sharutils)uudecode invocation. Restore file from 7-bits.
|
||||
* uuencode: (sharutils)uuencode invocation. Force binary file to 7-bits.
|
||||
END-INFO-DIR-ENTRY
|
||||
@end format
|
||||
@end ifinfo
|
||||
|
||||
@ifinfo
|
||||
This file documents the GNU set of shar utilities.
|
||||
|
||||
Copyright (C) 1994 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of
|
||||
this manual provided the copyright notice and this permission notice
|
||||
are preserved on all copies.
|
||||
|
||||
@ignore
|
||||
Permission is granted to process this file through TeX and print the
|
||||
results, provided the printed document carries copying permission
|
||||
notice identical to this one except for the removal of this paragraph
|
||||
(this paragraph not being relevant to the printed manual).
|
||||
|
||||
@end ignore
|
||||
Permission is granted to copy and distribute modified versions of this
|
||||
manual under the conditions for verbatim copying, provided that the entire
|
||||
resulting derived work is distributed under the terms of a permission
|
||||
notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this manual
|
||||
into another language, under the above conditions for modified versions,
|
||||
except that this permission notice may be stated in a translation approved
|
||||
by the Foundation.
|
||||
@end ifinfo
|
||||
|
||||
@titlepage
|
||||
@title GNU sharutils, version @value{VERSION}
|
||||
@subtitle A set of shell archiver utilities
|
||||
@subtitle Edition @value{EDITION}, @value{UPDATED}
|
||||
@author Jan Dj@"arv
|
||||
@author @value{Francois} Pinard
|
||||
|
||||
@page
|
||||
@vskip 0pt plus 1filll
|
||||
Copyright @copyright{} 1994 Free Software Foundation, Inc.
|
||||
|
||||
Permission is granted to make and distribute verbatim copies of
|
||||
this manual provided the copyright notice and this permission notice
|
||||
are preserved on all copies.
|
||||
|
||||
Permission is granted to copy and distribute modified versions of this
|
||||
manual under the conditions for verbatim copying, provided that the entire
|
||||
resulting derived work is distributed under the terms of a permission
|
||||
notice identical to this one.
|
||||
|
||||
Permission is granted to copy and distribute translations of this manual
|
||||
into another language, under the above conditions for modified versions,
|
||||
except that this permission notice may be stated in a translation approved
|
||||
by the Foundation.
|
||||
@end titlepage
|
||||
|
||||
@ifinfo
|
||||
@node Top, Introduction, (dir), (dir)
|
||||
@top GNU @code{shar} utilities
|
||||
|
||||
@c @item @b{@code{sharutils}} @value{hfillkludge} (UtilD, SrcCD (??))
|
||||
@c
|
||||
GNU @code{shar} makes so-called shell archives out of many files,
|
||||
preparing them for transmission by electronic mail services.
|
||||
GNU @code{unshar} helps unpacking shell archives after reception.
|
||||
This is release @value{VERSION}.
|
||||
|
||||
@menu
|
||||
* Introduction:: Introduction to both programs
|
||||
* shar invocation:: Invoking the @code{shar} program
|
||||
* unshar invocation:: Invoking the @code{unshar} program
|
||||
* Miscellaneous:: Miscellaneous considerations
|
||||
|
||||
--- The Detailed Node Listing ---
|
||||
|
||||
Creating shell archives
|
||||
|
||||
* Selecting:: Selecting files
|
||||
* Splitting:: Splitting output
|
||||
* Headers:: Controlling the shar headers
|
||||
* Stocking:: Selecting how files are stocked
|
||||
* Transmission:: Protecting against transmission
|
||||
* Kinds:: Producing different kinds of shar
|
||||
@end menu
|
||||
|
||||
@end ifinfo
|
||||
|
||||
@node Introduction, shar invocation, Top, Top
|
||||
@chapter Introduction to both programs
|
||||
|
||||
GNU @code{shar} makes so-called shell archives out of many files,
|
||||
preparing them for transmission by electronic mail services.
|
||||
A @dfn{shell archive} is a collection of files that can be unpacked by
|
||||
@code{/bin/sh}. A wide range of features provide extensive flexibility
|
||||
in manufacturing shars and in specifying shar @emph{smartness}. For
|
||||
example, @code{shar} may compress files, uuencode binary files, split
|
||||
long files and construct multi-part mailings, ensure correct unsharing
|
||||
order, and provide simplistic checksums. @xref{shar invocation}.
|
||||
|
||||
GNU @code{unshar} scans a set of mail messages looking for the start
|
||||
of shell archives. It will automatically strip off the mail headers
|
||||
and other introductory text. The archive bodies are then unpacked by
|
||||
a copy of the shell. @code{unshar} may also process files containing
|
||||
concatenated shell archives. @xref{unshar invocation}.
|
||||
|
||||
GNU @code{shar} has a long history. All along this long road, numerous
|
||||
users contributed various improvements. The file @file{THANKS}, from
|
||||
the GNU @code{shar} distribution, contain all names still having
|
||||
valid email addresses, as far as we know.
|
||||
|
||||
Please help me getting the history straight, for the following
|
||||
information is approximative. James Gosling wrote the public domain
|
||||
@code{shar 1.x}. William Davidsen rewrote it as @code{shar 2.x}.
|
||||
Warren Tucker brought modifications and called it @code{shar 3.x}.
|
||||
Richard Gumpertz maintained it until 1990. @value{Francois} Pinard,
|
||||
from the public domain @code{shar 3.49}, made @code{GNU shar 4.x},
|
||||
in 1994. Some modules and other code sections were freely borrowed
|
||||
from other GNU distributions, bringing this @code{shar} under the
|
||||
terms of the GNU General Public License.
|
||||
|
||||
Your feedback helps us to make a better and more portable product.
|
||||
Mail suggestions and bug reports (including documentation errors)
|
||||
for these programs to @file{bug-gnu-utils@@prep.ai.mit.edu}.
|
||||
|
||||
@node shar invocation, unshar invocation, Introduction, Top
|
||||
@chapter Invoking the @code{shar} program
|
||||
@pindex shar
|
||||
|
||||
The format of the @code{shar} command is one of:
|
||||
|
||||
@example
|
||||
shar [ @var{option} ] @dots{} @var{file} @dots{}
|
||||
shar -S [ @var{option} ] @dots{}
|
||||
@end example
|
||||
|
||||
In the first form, the file list is given as command arguments. In the
|
||||
second form, the file list is read from standard input. The resulting
|
||||
archive is sent to standard output unless the @code{-o} option is given.
|
||||
|
||||
Options can be given in any order. Some options depend on each other:
|
||||
the @code{-o} option is required if the @code{-l} or @code{-L} option
|
||||
is used. The @code{-n} option is required if the @code{-a} option
|
||||
is used. Also see @code{-V} below.
|
||||
|
||||
Some options are special purpose:
|
||||
|
||||
@table @code
|
||||
|
||||
@item --help
|
||||
Print a help summary on standard output, then immediately exits.
|
||||
|
||||
@item --version
|
||||
Print the version number of the program on standard output, then
|
||||
immediately exits.
|
||||
|
||||
@item -q
|
||||
@itemx --quiet
|
||||
Verbose @emph{off} at @code{shar} time. Messages are usually issued
|
||||
on standard error to let the user follow the progress, while making
|
||||
the archives. This option inhibits these messages.
|
||||
|
||||
@end table
|
||||
|
||||
@menu
|
||||
* Selecting:: Selecting files
|
||||
* Splitting:: Splitting output
|
||||
* Headers:: Controlling the shar headers
|
||||
* Stocking:: Selecting how files are stocked
|
||||
* Transmission:: Protecting against transmission
|
||||
* Kinds:: Producing different kinds of shar
|
||||
@end menu
|
||||
|
||||
@node Selecting, Splitting, shar invocation, shar invocation
|
||||
@section Selecting files
|
||||
|
||||
@table @code
|
||||
|
||||
@item -p
|
||||
@itemx --intermix-type
|
||||
Allow positional parameter options. The options @code{-M}, @code{-B},
|
||||
@code{-T}, @code{-z} and @code{-Z} may be embedded, and files to
|
||||
the right of the option will be processed in the specified mode.
|
||||
Without the @code{-p} option, embedded options would be interpreted
|
||||
as file names. @xref{Stocking} for more information on these options.
|
||||
|
||||
@item -S
|
||||
@itemx --stdin-file-list
|
||||
Read list of files to be packed from the standard input rather
|
||||
than from the command line. Input must be one file name per line.
|
||||
This switch is especially useful when the command line will not hold
|
||||
the list of files to be packed. For example:
|
||||
|
||||
@example
|
||||
find . -type f -print | shar -S -o /tmp/big.shar
|
||||
@end example
|
||||
|
||||
If @code{-p} is specified on the command line, then the options
|
||||
@code{-M}, @code{-B}, @code{-T}, @code{-z} and @code{-Z} may be
|
||||
included in the standard input (on a line separate from file names).
|
||||
The maximum number of lines of standard input, file names and options,
|
||||
may not exceed 1024.
|
||||
|
||||
@end table
|
||||
|
||||
@node Splitting, Headers, Selecting, shar invocation
|
||||
@section Splitting output
|
||||
|
||||
@table @code
|
||||
|
||||
@item -o @var{@var{prefix}}
|
||||
@itemx --output-prefix=@var{prefix}
|
||||
Save the archive to files @file{@var{prefix}.01} through
|
||||
@file{@var{prefix}.@var{nnn}} instead of standard output. This option
|
||||
@emph{must} be used when the @code{-l} or the @code{-L} switches
|
||||
are used.
|
||||
|
||||
When @var{prefix} contains any @samp{%} character, @var{prefix} is then
|
||||
interpreted as a @code{sprintf} format, which should be able to display
|
||||
a single decimal number. When @var{prefix} does not contain such a
|
||||
@samp{%} character, the string @samp{.%02d} is internally appended.
|
||||
|
||||
@item -l @var{size}
|
||||
@itemx --whole-size-limit=@var{size}
|
||||
Limit the output file size to @var{size} times 1024 bytes but don't
|
||||
split input files. This allows the recipient of the shell archives
|
||||
to unpack them in any order.
|
||||
|
||||
@item -L @var{size}
|
||||
@itemx --split-size-limit=@var{size}
|
||||
Limit output file size to @var{size} times 1024 bytes and split files
|
||||
if necessary. The archives created with this option must be unpacked
|
||||
in the correct order. If the recipient of the shell archives wants to
|
||||
put all of them in a single folder, she shall save them in the correct
|
||||
order for @code{unshar}, used with option @code{-e}, to unpack them
|
||||
all at once. @xref{unshar invocation}.
|
||||
|
||||
For people used to saving all the shell archives into a single mail
|
||||
folder, care must be taken to save them in the appropriate order.
|
||||
For those having the appropriate tools (like Masanobu Umeda's
|
||||
@code{rmailsort} package for GNU Emacs), shell archives can be saved
|
||||
in any order, then sorted by increasing date (or send time) before
|
||||
massive unpacking.
|
||||
|
||||
@end table
|
||||
|
||||
@node Headers, Stocking, Splitting, shar invocation
|
||||
@section Controlling the shar headers
|
||||
|
||||
@table @code
|
||||
|
||||
@item -n @var{name}
|
||||
@itemx --archive-name=@var{name}
|
||||
Name of archive to be included in the header of the shar files.
|
||||
Also see the @code{-a} switch further down.
|
||||
|
||||
@item -s @var{address}
|
||||
@itemx --submitter=@var{address}
|
||||
The @code{-s} option allows for overriding the email address for the
|
||||
submitter, for when the default is not appropriate. The automatically
|
||||
determined address looks like @file{@var{username}@@@var{hostname}}.
|
||||
|
||||
@item -a
|
||||
@itemx --net-headers
|
||||
Allows automatic generation of headers:
|
||||
|
||||
@example
|
||||
Submitted-by: @var{address}
|
||||
Archive-name: @var{name}/part@var{nn}
|
||||
@end example
|
||||
|
||||
The @var{name} must be given with the @code{-n} switch. If name
|
||||
includes a @samp{/}, then @samp{/part} isn't used. Thus
|
||||
@samp{-n xyzzy} produces:
|
||||
@example
|
||||
xyzzy/part01
|
||||
xyzzy/part02
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
while @samp{-n xyzzy/patch} produces:
|
||||
@example
|
||||
xyzzy/patch01
|
||||
xyzzy/patch02
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
and @samp{-n xyzzy/patch01.} produces:
|
||||
@example
|
||||
xyzzy/patch01.01
|
||||
xyzzy/patch01.02
|
||||
@end example
|
||||
|
||||
@item -c
|
||||
@itemx --cut-mark
|
||||
Start the shar with a cut line. A line saying @samp{Cut here} is
|
||||
placed at the start of each output file.
|
||||
|
||||
@end table
|
||||
|
||||
@node Stocking, Transmission, Headers, shar invocation
|
||||
@section Selecting how files are stocked
|
||||
|
||||
@table @code
|
||||
|
||||
@item -T
|
||||
@itemx --text-files
|
||||
Treat all files as text, regardless of their contents.
|
||||
|
||||
@item -B
|
||||
@itemx --uuencode
|
||||
Treat all files as binary, use @code{uuencode} prior to packing. This
|
||||
increases the size of the archive. The recipient must have
|
||||
@code{uudecode} in order to unpack.
|
||||
|
||||
@display
|
||||
Use of @code{uuencode} is not appreciated by many on the net, because
|
||||
people like to readily see, by mere inspection of a shell archive,
|
||||
what it is about.
|
||||
@end display
|
||||
|
||||
@item -M
|
||||
@itemx --mixed-uuencode
|
||||
Mixed mode. Automatically determine if the files are text or binary
|
||||
and archive correctly. Files found to be binary are uuencoded prior
|
||||
to packing. This option is selected by default.
|
||||
|
||||
For a file is considered to be a text file, instead of a binary file,
|
||||
all the following should be true simultaneously:
|
||||
@enumerate
|
||||
@item
|
||||
The file does not contain any ASCII control character besides @key{BS}
|
||||
(backspace), @key{HT} (horizontal tab), @key{LF} (new line) or @key{FF}
|
||||
(form feed).
|
||||
@item
|
||||
The file does not contains a @key{DEL} (delete).
|
||||
@item
|
||||
The file contains no character with its eighth-bit set.
|
||||
@item
|
||||
The file, unless totally empty, terminates with a @key{LF} (newline).
|
||||
@item
|
||||
No line in the file contains more than 200 characters. For counting
|
||||
purpose, lines are separated by a @key{LF} (newline).
|
||||
@end enumerate
|
||||
|
||||
@item -z
|
||||
@itemx --gzip
|
||||
Use @code{gzip} and @code{uuencode} on all files prior to packing.
|
||||
The recipient must have @code{uudecode} and @code{gzip} (used with
|
||||
@code{-d}) in order to unpack.
|
||||
|
||||
Usage of @code{-z} in net shars will cause you to be flamed off
|
||||
the earth.
|
||||
|
||||
@item -g @var{level}
|
||||
@itemx --level-for-gzip=@var{level}
|
||||
When doing compression, use @code{-@var{level}} as a parameter to
|
||||
@code{gzip}. The @code{-g} option turns on the @code{-z} option
|
||||
by default. The default value is 9, that is, maximum compression.
|
||||
|
||||
@item -Z
|
||||
@itemx --compress
|
||||
Use @code{compress} and @code{uuencode} on all files prior to packing.
|
||||
The recipient must have @code{uudecode} and @code{compress} (used
|
||||
with @code{-d}) in order to unpack. Option @code{-C} is a synonymous
|
||||
for @code{-Z}, but is deprecated.
|
||||
|
||||
Usage of @code{-Z} in net shars will cause you to be flamed off
|
||||
the earth.
|
||||
|
||||
@item -b @var{bits}
|
||||
@itemx --bits-per-code=@var{bits}
|
||||
When doing compression, use @code{-b@var{x}} as a parameter to
|
||||
@code{compress}. The @code{-B} option turns on the @code{-Z}
|
||||
option by default. The default value is 12, foreseeing the memory
|
||||
limitations of some @code{compress} programs on smallish systems, at
|
||||
@code{unshar} time.
|
||||
|
||||
@end table
|
||||
|
||||
@node Transmission, Kinds, Stocking, shar invocation
|
||||
@section Protecting against transmission errors
|
||||
|
||||
Transmission of shell archives is not always free of errors. So one
|
||||
should make consistency checks on the receiving site. A very simple
|
||||
(and unreliable) method is running the UNIX @code{wc} tool on the output
|
||||
file. This can report the number of characters in the file.
|
||||
|
||||
As one can guess this does not catch all errors. Especially changing of
|
||||
a character value does not change the computed check sum. To achieve
|
||||
this goal better method were invented and standardized. One very strong
|
||||
is MD5 (MD = message digests). This is standardized in RFC 1321. The
|
||||
produced shell scripts do not force the @code{md5sum} program to be
|
||||
installed on the system. This is necessary because it is not yet part
|
||||
of every UNIX. The program is however not necessary for producing the
|
||||
shell archive.
|
||||
|
||||
@table @code
|
||||
|
||||
@item -w
|
||||
@itemx --no-character-count
|
||||
Do @emph{not} check with @samp{wc -c} after unpack. The default is
|
||||
to check.
|
||||
|
||||
@item -D
|
||||
@itemx --no-md5-digest
|
||||
Do @emph{not} check with @samp{md5sum} after unpack. The default is
|
||||
to check.
|
||||
|
||||
@item -F
|
||||
@itemx --force-prefix
|
||||
Prepend the prefix character to every line even if not required.
|
||||
This option may slightly increase the size of the archive, especially
|
||||
if @code{-B} or @code{-Z} is used. Normally, the prefix character
|
||||
is @samp{X}. If the parameter to the @code{-d} option starts with
|
||||
@samp{X}, then the prefix character becomes @samp{Y}.
|
||||
|
||||
@item -d @var{string}
|
||||
@itemx --here-delimiter=@var{string}
|
||||
Use @var{string} to delimit the files in the shar instead of
|
||||
@samp{SHAR_EOF}. This is for those who want to personalize their
|
||||
shar files.
|
||||
|
||||
@end table
|
||||
|
||||
@node Kinds, , Transmission, shar invocation
|
||||
@section Producing different kinds of shars
|
||||
|
||||
@table @code
|
||||
|
||||
@item -V
|
||||
@itemx --vanilla-operation
|
||||
This option produces @dfn{vanilla} shars which rely only upon the
|
||||
existence of @code{echo}, @code{test} and @code{sed} in the unpacking
|
||||
environment.
|
||||
|
||||
The @code{-V} disables options offensive to the @dfn{network cop}
|
||||
(or @dfn{brown shirt}). It also changes the default from mixed mode
|
||||
@code{-M} to text mode @code{-T}. Warnings are produced if option
|
||||
@code{-B}, @code{-z}, @code{-Z}, @code{-p} or @code{-M} is specified
|
||||
(any of which does or might require @code{uudecode}, @code{gzip} or
|
||||
@code{compress} in the unpacking environment).
|
||||
|
||||
@item -P
|
||||
@itemx --no-piping
|
||||
In the shar file, use a temporary file to hold the file to
|
||||
@code{uudecode}, instead of using pipes. This option is mandatory
|
||||
when you know the unpacking @code{uudecode} is unwilling to merely
|
||||
read its standard input. Richard Marks wrote what is certainly the
|
||||
most (in)famous of these, for MSDOS :-).
|
||||
|
||||
(Here is a side note from the maintainer. Why isnt't this option
|
||||
the default? In the past history of @code{shar}, it was decided
|
||||
that piping was better, surely because it is less demanding on disk
|
||||
space, and people seem to be happy with this. Besides, I think
|
||||
that the @code{uudecode} from Richard Marks, on MSDOS, is wrong in
|
||||
refusing to handle @code{stdin}. So far that I remember, he has
|
||||
the strong opinion that a program without any parameters should
|
||||
give its @code{--help} output. Besides that, should I say, his
|
||||
@code{uuencode} and @code{uudecode} programs are full-featured, one
|
||||
of the most complete set I ever saw. But Richard will not release
|
||||
his sources, he wants to stay in control.)
|
||||
|
||||
@item -x
|
||||
@itemx --no-check-existing
|
||||
Overwrite existing files without checking. If neither @code{-x} nor
|
||||
@code{-X} is specified, when unpacking itself, the shell archive will
|
||||
check for and not overwrite existing files (unless @code{-c} is passed
|
||||
as a parameter to the script when unpacking).
|
||||
|
||||
@item -X
|
||||
@itemx --query-user
|
||||
Interactively overwrite existing files.
|
||||
|
||||
Use of @code{-X} produces shars which @emph{will} cause problems
|
||||
with some @code{unshar}-style procedures, particularily when used
|
||||
together with vanilla mode (@code{-V}). Use this feature mainly for
|
||||
archives to be passed among agreeable parties. Certainly, @code{-X}
|
||||
is @emph{not} for shell archives which are to be submitted to Usenet
|
||||
or other public networks.
|
||||
|
||||
The problem is that @code{unshar} programs or procedures often feed
|
||||
@file{/bin/sh} from its standard input, thus putting @file{/bin/sh}
|
||||
and the shell archive script in competition for input lines. As an
|
||||
attempt to alleviate this problem, @code{shar} will try to detect if
|
||||
@file{/dev/tty} exists at the receiving site and will use it to read
|
||||
user replies. But this does not work in all cases, it may happen that
|
||||
the receiving user will have to avoid using @code{unshar} programs
|
||||
or procedures, and call @code{/bin/sh} directly. In vanilla mode,
|
||||
using @file{/dev/tty} is not even attempted.
|
||||
|
||||
@item -m
|
||||
@itemx --no-timestamp
|
||||
Avoid generating @code{touch} commands to restore the file modification
|
||||
dates when unpacking files from the archive.
|
||||
|
||||
When the timestamp relationship is not preserved, some files like
|
||||
@file{configure} or @file{*.info} may be uselessly remade after
|
||||
unpacking. This is why, when this option is not used, a special
|
||||
effort is made to restore timestamps,
|
||||
|
||||
@item -Q
|
||||
@itemx --quiet-unshar
|
||||
Verbose @emph{off} at @code{unshar} time. Disables the inclusion of
|
||||
comments to be output when the archive is unpacked.
|
||||
|
||||
@item -f
|
||||
@itemx --basename
|
||||
Use only the last file name component of each input file name, ignoring
|
||||
any prefix directories. This is sometimes useful when building a shar
|
||||
from several directories, or another directory. If a directory name
|
||||
is passed to @code{shar}, the substructure of that directory will be
|
||||
restored whether @code{-f} is specified or not.
|
||||
|
||||
@end table
|
||||
|
||||
@node unshar invocation, Miscellaneous, shar invocation, Top
|
||||
@chapter Invoking the @code{unshar} program
|
||||
@pindex unshar
|
||||
|
||||
The format of the @code{unshar} command is:
|
||||
|
||||
@example
|
||||
unshar [ @var{option} ] @dots{} [ @var{file} @dots{} ]
|
||||
@end example
|
||||
|
||||
Each @var{file} is processed in turn, as a shell archive or a
|
||||
collection of shell archives. If no files are given, then standard
|
||||
input is processed instead.
|
||||
|
||||
Options:
|
||||
|
||||
@table @code
|
||||
|
||||
@item --version
|
||||
Print the version number of the program on standard output, then
|
||||
immediately exits.
|
||||
|
||||
@item --help
|
||||
Print an help summary on standard output, then immediately exits.
|
||||
|
||||
@item -d @var{directory}
|
||||
@itemx --directory=@var{directory}
|
||||
Change directory to @var{directory} before unpacking any files.
|
||||
|
||||
@item -c
|
||||
@itemx --overwrite
|
||||
@item -f
|
||||
@itemx --force
|
||||
Passed as an option to the shar file. Many shell archive scripts
|
||||
(including those produced by @code{shar} 3.40 and newer) accepts
|
||||
a @code{-c} argument to indicate that existing files should be
|
||||
overwritten.
|
||||
|
||||
The option @code{-f} is provided for a more unique interface. Many
|
||||
programs (such as @code{cp} and @code{mv}) use this option to trigger
|
||||
the very same action.
|
||||
|
||||
@item -e
|
||||
@itemx --exit-0
|
||||
This option exists mainly for people who collect many shell archives
|
||||
into a single mail folder. With this option, @code{unshar} isolates
|
||||
each different shell archive from the others which have been put in the
|
||||
same file, unpacking each in turn, from the beginning of the file
|
||||
towards its end. Its proper operation relies on the fact that many shar
|
||||
files are terminated by a @w{@samp{exit 0}} at the beginning of a line.
|
||||
|
||||
Option @code{-e} is internally equivalent to @w{@code{-E "exit 0"}}.
|
||||
|
||||
@item -E @var{string}
|
||||
@itemx --split-at=@var{string}
|
||||
This option works like @code{-e}, but it allows you to specify the
|
||||
string that separates archives if @samp{exit 0} isn't appropriate.
|
||||
|
||||
For example, noticing that most @file{.signatures} have a @samp{--} on
|
||||
a line right before them, one can sometimes use @samp{--split-at=--}
|
||||
for splitting shell archives which lack the @samp{exit 0} line at end.
|
||||
The signature will then be skipped altogether with the headers of
|
||||
the following message.
|
||||
|
||||
@end table
|
||||
|
||||
@node Miscellaneous, , unshar invocation, Top
|
||||
@chapter Miscellaneous considerations
|
||||
|
||||
Here is a place-holder for many considerations which do not fit
|
||||
elsewhere, while not worth a section for themselves.
|
||||
|
||||
Be careful that the output file(s) are not included in the inputs
|
||||
or @code{shar} may loop until the disk fills up. Be particularly
|
||||
careful when a directory is passed to @code{shar} that the output
|
||||
files are not in that directory (or a subdirectory of that directory).
|
||||
|
||||
When a directory is passed to @code{shar}, it may be scanned more
|
||||
than once, to conserve memory. Therefore, one should be careful to
|
||||
not change the directory contents while @code{shar} is running.
|
||||
|
||||
No attempt is made to restore the protection and modification dates
|
||||
for directories, even if this is done by default for files. Thus, if
|
||||
a directory is given to @code{shar}, the protection and modification
|
||||
dates of corresponding unpacked directory may not match those of
|
||||
the original.
|
||||
|
||||
Use of the @code{-M} or @code{-B} options will slow down the archive
|
||||
process. Use of the @code{-z} or @code{-Z} options may slow the
|
||||
archive process considerably.
|
||||
|
||||
Let us conclude by a showing a few examples of @code{shar} usage:
|
||||
|
||||
@example
|
||||
shar *.c > cprog.shar
|
||||
shar -Q *.[ch] > cprog.shar
|
||||
shar -B -l28 -oarc.sh. *.arc
|
||||
shar -f /lcl/src/u*.c > u.sh
|
||||
@end example
|
||||
|
||||
@noindent
|
||||
The first shows how to make a shell archive out of all C program
|
||||
sources. The second produces a shell archive with all @file{.c}
|
||||
and @file{.h} files, which unpacks silently. The third gives a shell
|
||||
archive of all uuencoded @file{.arc} files, into files @file{arc.sh.01}
|
||||
through to @file{arc.sh.@var{nnn}}. The last example gives a shell
|
||||
archive which will use only the file names at unpack time.
|
||||
|
||||
@contents
|
||||
@bye
|
||||
|
||||
@c Local variables:
|
||||
@c texinfo-column-for-description: 32
|
||||
@c End:
|
||||
@@ -0,0 +1 @@
|
||||
timestamp
|
||||
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,56 @@
|
||||
.TH UNSHAR 1 "September 10, 1995"
|
||||
.SH NAME
|
||||
unshar \- unpack a shar file
|
||||
.SH SYNOPSIS
|
||||
unshar [ options ] [ file ... ]
|
||||
.SH DESCRIPTION
|
||||
.PP
|
||||
Unshar scans mail messages looking for the start of a shell archive. It
|
||||
then passes the archive through a copy of the shell to unpack it. It
|
||||
will accept multiple files. If no files are given, standard input is used.
|
||||
.SH OPTIONS
|
||||
.PP
|
||||
Options have a one letter version starting with \- or a long version starting
|
||||
with \-\-. The exception is \f2\-\-help\f1 and \f2\-\-version\f1,
|
||||
which does not have a short version.
|
||||
.IP "\f2\-\-version\f1"
|
||||
Print the version number of the program on standard output,
|
||||
then immediately exits.
|
||||
.IP "\f2\-\-help\f1"
|
||||
Print a help summary on standard output, then immediately exits.
|
||||
.IP "\f2\-d\f1 DIRECTORY \f2\-\-directory=\f1DIRECTORY"
|
||||
Change directory to DIRECTORY before unpacking any files.
|
||||
.IP "\f2\-c\f1 \f2\-\-overwrite\f1"
|
||||
Passed as an option to the shar file. Many shell archive scripts
|
||||
(including those produced by `shar' 3.40 and newer) accepts a \f2\-c\f1
|
||||
argument to indicate that existing files should be overwritten.
|
||||
.IP "\f2\-e\f1 \f2\-\-exit-0\f1"
|
||||
This option exists mainly for people who collect many shell
|
||||
archives into a single mail folder. With this option, `unshar'
|
||||
isolates each different shell archive from the others which have
|
||||
been put in the same file, unpacking each in turn, from the
|
||||
beginning of the file towards its end. Its proper operation
|
||||
relies on the fact that many shar files are terminated by a
|
||||
`exit 0' at the beginning of a line.
|
||||
|
||||
Option \f2\-e\f1 is internally equivalent to \f2\-E\f1 "exit 0".
|
||||
.IP "\f2\-E\f1 STRING \f2\-\-split-at=\f1STRING"
|
||||
This option works like \f2\-e\f1, but it allows you to specify the
|
||||
string that separates archives if `exit 0' isn't appropriate.
|
||||
|
||||
For example, noticing that most `.signatures' have a `\-\-' on a
|
||||
line right before them, one can sometimes use `\f2\-\-split-at\f1=\-\-' for
|
||||
splitting shell archives which lack the `exit 0' line at end. The
|
||||
signature will then be skipped altogether with the headers of the
|
||||
following message.
|
||||
.IP "\f2\-f\f1 \f2\-\-force\f1"
|
||||
The same as \f2\-c\f1.
|
||||
.SH SEE ALSO
|
||||
shar(1)
|
||||
.SH DIAGNOSTICS
|
||||
Any message from the shell may be displayed.
|
||||
.SH AUTHORS
|
||||
The shar and unshar programs is the collective work of many authors.
|
||||
Many people contributed by reporting problems, suggesting
|
||||
various improvements or submitting actual code. A list of
|
||||
these people is in the THANKS file in the sharutils distribution.
|
||||
@@ -0,0 +1,129 @@
|
||||
'.\" Copyright (c) 1980, 1990 The Regents of the University of California.
|
||||
'.\" All rights reserved.
|
||||
'.\"
|
||||
'.\" Redistribution and use in source and binary forms, with or without
|
||||
'.\" modification, are permitted provided that the following conditions
|
||||
'.\" are met:
|
||||
'.\" 1. Redistributions of source code must retain the above copyright
|
||||
'.\" notice, this list of conditions and the following disclaimer.
|
||||
'.\" 2. Redistributions in binary form must reproduce the above copyright
|
||||
'.\" notice, this list of conditions and the following disclaimer in the
|
||||
'.\" documentation and/or other materials provided with the distribution.
|
||||
'.\" 3. All advertising materials mentioning features or use of this software
|
||||
'.\" must display the following acknowledgement:
|
||||
'.\" This product includes software developed by the University of
|
||||
'.\" California, Berkeley and its contributors.
|
||||
'.\" 4. Neither the name of the University nor the names of its contributors
|
||||
'.\" may be used to endorse or promote products derived from this software
|
||||
'.\" without specific prior written permission.
|
||||
'.\"
|
||||
'.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
||||
'.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
'.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
||||
'.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
||||
'.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
||||
'.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
||||
'.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
||||
'.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
'.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
'.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
||||
'.\" SUCH DAMAGE.
|
||||
'.\"
|
||||
'.\" Modified from
|
||||
'.\" @(#)uuencode.1 6.9 (Berkeley) 4/23/91
|
||||
'.\"
|
||||
.TH uuencode 1
|
||||
.SH NAME
|
||||
uuencode \- encode a binary file
|
||||
.PP
|
||||
uudecode \- decode a file created by uuencode
|
||||
.SH SYNOPSIS
|
||||
.B uuencode
|
||||
[\-m] [ file ] name
|
||||
.PP
|
||||
.B uudecode
|
||||
[-o outfile] [ file ]...
|
||||
.SH DESCRIPTION
|
||||
.I Uuencode
|
||||
and
|
||||
.I uudecode
|
||||
are used to transmit binary files over transmission mediums
|
||||
that do not support other than simple
|
||||
ASCII
|
||||
data.
|
||||
.PP
|
||||
.I Uuencode
|
||||
reads
|
||||
.I file
|
||||
(or by default the standard input) and writes an encoded version
|
||||
to the standard output.
|
||||
The encoding uses only printing
|
||||
ASCII
|
||||
characters and includes the
|
||||
mode of the file and the operand
|
||||
.I name
|
||||
for use by
|
||||
.I uudecode.
|
||||
If
|
||||
.I name
|
||||
is
|
||||
.I /dev/stdout
|
||||
the result will be written to standard output. By default the standard
|
||||
UU encoding format will be used. If the option
|
||||
.I \-m
|
||||
is given on the command line
|
||||
.B base64
|
||||
encoding is used instead.
|
||||
.PP
|
||||
.I Uudecode
|
||||
transforms
|
||||
uuencoded
|
||||
.I files
|
||||
(or by default, the standard input) into the original form.
|
||||
The resulting file is named
|
||||
.I name
|
||||
(or
|
||||
.I outfile
|
||||
if the \-o option is given)
|
||||
and will have the mode of the original file except that setuid
|
||||
and execute bits are not retained. If
|
||||
.I outfile
|
||||
or
|
||||
.I name
|
||||
is /dev/stdout the result will be written to standard output.
|
||||
.I Uudecode
|
||||
ignores any leading and trailing lines. The program can automatically decide
|
||||
which of the both supported encoding schemes are used.
|
||||
.SH EXAMPLES
|
||||
The following example packages up a source tree, compresses it,
|
||||
uuencodes it and mails it to a user on another system.
|
||||
When
|
||||
.I uudecode
|
||||
is run on the target system, the file ``src_tree.tar.Z'' will be
|
||||
created which may then be uncompressed and extracted into the original
|
||||
tree.
|
||||
.PP
|
||||
.IP
|
||||
.NF
|
||||
tar cf \- src_tree \&| compress \&|
|
||||
uuencode src_tree.tar.Z \&| mail sys1!sys2!user
|
||||
.FI
|
||||
.LP
|
||||
.SH SEE ALSO
|
||||
compress(1), mail(1), uucp(1), uuencode(5)
|
||||
.SH STANDARDS
|
||||
This implementation is compliant with P1003.2b/D11.
|
||||
.SH BUGS
|
||||
If more than one file is given to
|
||||
.I uudecode
|
||||
and the \-o option is given or more than one
|
||||
.I name
|
||||
in the encoded files are the same the result is probably not what is expected.
|
||||
.PP
|
||||
The encoded form of the file is expanded by 37% for UU encoding and by 35%
|
||||
for base64 encoding (3 bytes become 4 plus control information).
|
||||
.SH HISTORY
|
||||
The
|
||||
.I uuencode
|
||||
command appeared in
|
||||
BSD 4.0.
|
||||
@@ -0,0 +1,93 @@
|
||||
'.\" Copyright (c) 1989, 1991 The Regents of the University of California.
|
||||
'.\" All rights reserved.
|
||||
'.\"
|
||||
'.\" Redistribution and use in source and binary forms, with or without
|
||||
'.\" modification, are permitted provided that the following conditions
|
||||
'.\" are met:
|
||||
'.\" 1. Redistributions of source code must retain the above copyright
|
||||
'.\" notice, this list of conditions and the following disclaimer.
|
||||
'.\" 2. Redistributions in binary form must reproduce the above copyright
|
||||
'.\" notice, this list of conditions and the following disclaimer in the
|
||||
'.\" documentation and/or other materials provided with the distribution.
|
||||
'.\" 3. All advertising materials mentioning features or use of this software
|
||||
'.\" must display the following acknowledgement:
|
||||
'.\" This product includes software developed by the University of
|
||||
'.\" California, Berkeley and its contributors.
|
||||
'.\" 4. Neither the name of the University nor the names of its contributors
|
||||
'.\" may be used to endorse or promote products derived from this software
|
||||
'.\" without specific prior written permission.
|
||||
'.\"
|
||||
'.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
|
||||
'.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
|
||||
'.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
|
||||
'.\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
|
||||
'.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
|
||||
'.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
|
||||
'.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
|
||||
'.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
|
||||
'.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
|
||||
'.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
|
||||
'.\" SUCH DAMAGE.
|
||||
'.\"
|
||||
'.\" @(#)uuencode.format.5 6.4 (Berkeley) 5/10/91
|
||||
'.\"
|
||||
.TH UUENCODE 5
|
||||
.SH NAME
|
||||
uuencode \- format of an encoded uuencode file
|
||||
.SH DESCRIPTION
|
||||
Files output by
|
||||
uuencode(1)
|
||||
consist of a header line,
|
||||
followed by a number of body lines,
|
||||
and a trailer line.
|
||||
The
|
||||
uudecode(1)
|
||||
command
|
||||
will ignore any lines preceding the header or
|
||||
following the trailer.
|
||||
Lines preceding a header must not, of course,
|
||||
look like a header.
|
||||
.PP
|
||||
The header line is distinguished by having the first
|
||||
6 characters
|
||||
.I begin\ \&
|
||||
The word
|
||||
.I begin
|
||||
is followed by a mode (in octal),
|
||||
and a string which names the remote file.
|
||||
A space separates the three items in the header line.
|
||||
.PP
|
||||
The body consists of a number of lines, each at most 62 characters
|
||||
long (including the trailing newline).
|
||||
These consist of a character count,
|
||||
followed by encoded characters,
|
||||
followed by a newline.
|
||||
The character count is a single printing character,
|
||||
and represents an integer, the number of bytes
|
||||
the rest of the line represents.
|
||||
Such integers are always in the range from 0 to 63 and can
|
||||
be determined by subtracting the character space (octal 40)
|
||||
from the character.
|
||||
.PP
|
||||
Groups of 3 bytes are stored in 4 characters, 6 bits per character.
|
||||
All are offset by a space to make the characters printing.
|
||||
The last line may be shorter than the normal 45 bytes.
|
||||
If the size is not a multiple of 3, this fact can be determined
|
||||
by the value of the count on the last line.
|
||||
Extra garbage will be included to make the character count a multiple
|
||||
of 4.
|
||||
The body is terminated by a line with a count of zero.
|
||||
This line consists of one
|
||||
ASCII
|
||||
space.
|
||||
.PP
|
||||
The trailer line consists of
|
||||
.I end
|
||||
on a line by itself.
|
||||
.SH SEE ALSO
|
||||
uuencode(1), uudecode(1), uusend(1), uucp(1), mail(1)
|
||||
.SH HISTORY
|
||||
The
|
||||
.I uuencode
|
||||
file format appeared in
|
||||
BSD 4.0 .
|
||||
@@ -0,0 +1,3 @@
|
||||
@set EDITION 4.1.9
|
||||
@set UPDATED 28 October
|
||||
@set VERSION 4.1.9
|
||||
Reference in New Issue
Block a user