> I don't think there is much point in arranging the files
> hierarchically unless the hierarchy reflects some natural order the
> files themselves. If a set of files are closely related, they should
> be kept together.
I agree. But at least the COPYING, README, NOTES etc. files should be
moved outside the source directory.
>
> > /doc - documentation, man pages etc.
>
> This directory exists in cvs, but is almost empty. I think most of the
> files (README, AUTHORS, TODO, ... belongs in the top-level directory.
> Which files would you like to move to doc/ ?
>
> > /src - source
>
> Moving all source files into a subdirectory is an easy way to make the
> top level directory cleaner.
this was the minimum I wanted to do.
>
> > /lib - library files
>
> What is your definition of "library" here? The lib/ and include/
> directories exists, but are used only for the crypto code that can
> easily be used and distributed separately (in fact, they are copied
> from the crypto module for the pike interpreter,
> http://pike.idonex.se). "lib" is definitely a poor name for this;
> something more specific would be better.
I meant the current /lib directory, and I wanted to leave it /lib,
while the src is moved to a subdir.
>
> > /include - library includes
>
> In general, I prefer keeping "internal" include files together with
> the corresponding source files. Using a separate include-directory is
> best for files that are intended to be installed somewhere under
> /usr/local/include, or something like that. Furthermore, some include
> files have corresponding .h.x files. Where would you like to put them?
again I meant the current /include which belongs to the files in /lib.
>
> I'm not saying that I'm against moving files around, but I don't want
> to do so without good reason.
ok.
>
> > I have written a perl script for checking the range of pty devices a given
> > distribution has. It inputs a header file, and expands a macro called
> > PTY_BSD_DEFS to four defines:
> >
> > #define PTY_BSD_FIRST_MIN 'p'
> > #define PTY_BSD_FIRST_MAX 's'
> > #define PTY_BSD_SECND_MIN '0'
> > #define PTY_BSD_SECND_MAX 'f'
>
> Hmm. Perhaps it would be better to use strings rather than upper and
> lower limits. Like
>
> #define PTY_BSD_FIRST "pqrs"
> #define PTY_BSD_SECOND "0123456789abcdef"
oops... missed the possible gaps. of course you are right...
> Something even more general would be to simply list all the devices,
>
> char *pty_names[] = { "/dev/ptya0", ... };
> #define NUMBER_OF_PTYS (sizeof(pty_names) / sizeof(pty_names[0]))
that would be an overkill IMHO...
>
> > It may be better to achieve the same using autoconf, but I don't know
> > that beast too much. :-)
> Adding perl to the second list is ok with me (even if I might prefer a
> scsh script ;). Adding it to the first list is worse. I think a test
> written for /bin/sh (which could be inserted directly into
> configure.in) would be better. Or a test done entirely at run time.
maybe I should have began in shell... though I was thinking in ranges, and
found it a bit too difficult for a simple bash. but here is my solution
which finds all the possible first and second characters:
#!/bin/sh
FIRST=`ls /dev/pty* | cut -c 9-9 | uniq | tr -d '\n'`
SECND=`ls /dev/pty* | cut -c 10-10 | sort | uniq | tr -d '\n'`
echo $FIRST
echo $SECND
so what do you think?
--- Bazsi
