Date: Sat, 15 Mar 1997 11:41:39 -0800 (PST)
From: Evan Dickinson <evand AT wsunix DOT wsu DOT edu>
Reply-To: evand AT scn DOT org
To: OpenDOS Mailing List <opendos AT mail DOT tacoma DOT net>
Subject: Re: [opendos] Standard Directories (was: FSSTND)
In-Reply-To: <Pine.NXT.3.95.970314224555.16736O-100000@eagle1>
Message-ID: <Pine.OSF.3.95.970315113345.23745A-100000@unicorn.it.wsu.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-opendos AT mail DOT tacoma DOT net
Precedence: bulk

Look!  A new subject line.

On Fri, 14 Mar 1997 jdashiel AT eagle1 DOT eaglenet DOT com wrote:

> Yes, I am suggesting placing all paths in paths.dir for a couple reasons.
> New users, they have lots of trouble with paths five or more directories
> deep and this way the new user can be told,
> print out paths.dir and you'll have all existing paths in ffront of you.
> An engineering student from Bengal messed up the computer of a good friend 
> I have who is a very new user and did it in precisely that way.
> Beyond this, there are security concerns.
> If paths.dir were run through the rcs utilities any time
> any software changed path structure either by adding or deleting paths
> this could be quickly bought to the user's attention.
> Beyond that, perhaps lines with # on them or lines that have something
> else on them followed by # could also hold comments about file directory
> content left by
> the user.
> If this structure were extended to files.dir which documented files in the
> same way, opendos would come closer to 4dos at very little cost.

It would also help to read these comments outside the file.  So if I had
the line:

c:\batch #Directory for storing batch files.

I could use a command like:

c:\batch>dirinfo

and get:

Directory for storing batch files.

Also, dirinfo should accept a path name so:

c:\>dirinfo c:\batch

would return as above.