DataMuseum.dk

Presents historical artifacts from the history of:

DKUUG/EUUG Conference tapes

This is an automatic "excavation" of a thematic subset of
artifacts from Datamuseum.dk's BitArchive.

See our Wiki for more about DKUUG/EUUG Conference tapes

Excavated with: AutoArchaeologist - Free & Open Source Software.


top - metrics - download
Index: R T

⟦0d2f74e21⟧ TextFile

    Length: 2235 (0x8bb)
    Types: TextFile
    Names: »README«

Derivation

└─⟦a05ed705a⟧ Bits:30007078 DKUUG GNU 2/12/89
    └─⟦ca1f037a2⟧ »./bash-1.04.tar.Z« 
        └─⟦46465a4db⟧ 
            └─⟦this⟧ »bash-1.04/README« 

TextFile

-*- text -*-

This is the README file for bash, the Bourne Again SHell.  This shell
comes with no documentation at this time.  There is an online help
facility, and a file called FEATURES that comes with the distribution.

When the documentation is completely finished, it will be included in
the distribution.  No partial documentation is included because it
causes complaints.

INSTALLING:

You must edit the Makefile that comes with Bash in order to make it.
The parameters you should pay special attention to are:

DESTDIR:	The installation directory.  It would be nice if
		everyone had a /usr/gnu/bin directory to install in.

TARGET:		The name of the target hardware.  This could be VAX,
		SUN3, SUN4, or some other hardware.

OS:		The name of the target operating system.  This could be
		SUNOS3, SUNOS4, SYSV, BSD, or some other operating
		system.

BISON:		If you are not using Bison (the GNU version of yacc) you must
		change the BISON parameter to `yacc'.

CC:		If you are not using the GNU C compiler, you must change
		the CC variable to the name of the compiler that you are
		using, perhaps `cc'.  Otherwise, it should be
		`gcc -traditional'.

Then just do `make'.  When compilation is done, test the shell with `./bash'
to insure that it compiled correctly.  To install it, just do `make install'.

REPORTING BUGS:

If you find a bug in bash, you should report it.  But first, you should
make sure that it really is a bug, and that it appears in the latest
version of Bash that you have.

Once you have ascertained that a bug really exists, you are welcome to
mail me a bug report.  If you have a fix, you are welcome to mail that
to me as well!  Suggestions and `philosophical' bug reports may be mailed
to bug-bash@ai.mit.edu.  Real bug reports may be mailed to the same
place, or to me, bfox@ai.mit.edu.

ALL bug reports should include:

	* The version number of Bash
	* The hardware and operating system
	* The compiler used to compile
	* A description of the bug behaviour
	* A short script or `recipe' which exercises the bug

Without this information, I generally cannot successfully debug Bash,
because usually, without this information, I generally cannot make the
bug manifest itself!

Enjoy,

	Brian Fox