Bug 36456

Comment 1 Giorgos Keramidas 2002-03-29 03:59:51 UTC

On 2002-03-28 19:37, Gary W. Swearingen wrote:
> The csh(1) manual references "/usr/include/signal.h" while it should
> reference "/usr/include/sys/signal.h".

Why?  Anyone who knows enough C to read /usr/include/signal.h can easily
spot the #include that leads to /usr/include/sys/signal.h:

hades:~$ grep 'signal.h>' /usr/include/signal.h
#include <sys/signal.h>

> In the "kill" description, change "signal.h" to "sys/signal.h".

But more importantly, csh.1 is hard linked to tcsh.1.gz which comes from
contrib/ source (the source of /usr/src/contrib/tcsh).  If any changes are
made to that file, they should probably be made in the tcsh developer's
source and imported to FreeBSD verbatim when a newer version of tcsh is
imported to our source.

Giorgos Keramidas                       FreeBSD Documentation Project
keramida@{freebsd.org,ceid.upatras.gr}  http://www.FreeBSD.org/docproj/

Giorgos Keramidas <keramida@freebsd.org> writes:

> Why?  Anyone who knows enough C to read /usr/include/signal.h can easily
> spot the #include that leads to /usr/include/sys/signal.h:

Because man page readers might not know any C so he can find the correct
file but anyone can easily recognize the list of signals in the correct
file.  Even C readers, especially if not Unix people familiar with signals,
would waste considerable time figuring it out.  It took me a while.

> But more importantly, csh.1 is hard linked to tcsh.1.gz which comes from
> contrib/ source (the source of /usr/src/contrib/tcsh).  If any changes are
> made to that file, they should probably be made in the tcsh developer's
> source and imported to FreeBSD verbatim when a newer version of tcsh is
> imported to our source.

I suspect that it's wrong because the tcsh developer's layout is
different, but that's about all I have to say on it.  (If you don't want
to fix it one way or the other, I don't see any good reason to not leave
it open for someone who cares about this low-priority stuff.)

Comment 3 Giorgos Keramidas 2002-03-29 15:50:19 UTC

On 2002-03-28 23:11, Gary W. Swearingen wrote:
> Giorgos Keramidas <keramida@freebsd.org> writes:
> > But more importantly, csh.1 is hard linked to tcsh.1.gz which comes from
> > contrib/ source (the source of /usr/src/contrib/tcsh).  If any changes are
> > made to that file, they should probably be made in the tcsh developer's
> > source and imported to FreeBSD verbatim when a newer version of tcsh is
> > imported to our source.
>
> I suspect that it's wrong because the tcsh developer's layout is
> different, but that's about all I have to say on it.  (If you don't want
> to fix it one way or the other, I don't see any good reason to not leave
> it open for someone who cares about this low-priority stuff.)

It's not easy to fix this one.  The /usr/include/sys/signal.h file is not
guaranteed to be there in other systems, AFAIK.  The /usr/include/signal.h
is something one can depend on, being there on all Unix systems that are
out there.  The tcsh developers chose to refer to /usr/include to avoid
writing things like:

	"If you are on FreeBSD ..., but if you are on Linux ..., ..."

The problem here is that FreeBSD uses CVS to track the changes made to
"vendor code", and making local changes to files that come from the vendor
branch of a program like tcsh means that this file has to be manually
merged every time a new version of tcsh is imported :/

I've Cc:'ed the people who have done imports of tcsh to the CVS tree.
They are the ones that know better than me if such a change needs to be
done :)

- Giorgos

Giorgos Keramidas <keramida@freebsd.org> writes:

> out there.  The tcsh developers chose to refer to /usr/include to avoid
> writing things like:
> 
> 	"If you are on FreeBSD ..., but if you are on Linux ..., ..."

Looks like that could be avoided by referring to use of "kill -l" for
signal names & numbers; the ksh manual implies that that is a POSIX-
standard option for that purpose, and it's supported by tcsh's built-
in "kill".

P.S. If anyone cares more than I do, the tcsh manual refers to
the first of these as two "forms" and the second as one "form".
    kill [-s signal] %job|pid ...
    migrate [-site] pid|%jobid ... (+)
which, in context, had me wasting time trying to determine which form
was being referred to in the description.

Comment 5 David E. O'Brien 2002-04-01 23:52:08 UTC

On Fri, Mar 29, 2002 at 05:50:19PM +0200, Giorgos Keramidas wrote:
> The problem here is that FreeBSD uses CVS to track the changes made to
> "vendor code", and making local changes to files that come from the vendor
> branch of a program like tcsh means that this file has to be manually
> merged every time a new version of tcsh is imported :/
> 
> I've Cc:'ed the people who have done imports of tcsh to the CVS tree.
> They are the ones that know better than me if such a change needs to be
> done :)

It would be best to handle this such that it does not take something off
the vendor branch.  However, I will never be doing another tcsh import,
so my concerns on the matter really isn't that important.

Comment 6 Tom Rhodes 2002-05-09 19:58:14 UTC

State Changed
From-To: open->closed

Problem is on the vendor branch, not within FreeBSD.