HDTenEightyP/NetNews huggingface dataset:
From: hoehle@inf-wiss.ivp.uni-konstanz.DE (Joerg-Cyril Hoehle)
Subject: working with RCS after doing an su <login>
Summary: RCS ignores su login
Keywords: RCS, su, user, logname, uid
Organization: Information Science, Univ. of Konstanz
Distribution: gnu
Date: Fri, 20 Nov 1992 15:20:35 GMT

I have installed RCS 5.6 on a Sun4 pool (IPC,IPX,SS2) and noticed that
RCS didn't work correctly with my changing user ID with the su
command. I'm not sure if I did something wrong at compile time, RCS is
not working suid or sgid here.

>Here part of an rlog output:
>RCS file: /home/hoehle/sspace/RCS/foo.lisp,v
>Working file: /home/hoehle/sspace/foo.lisp
>head: 1.4
>branch:
>locks: strict
>access list:
>	emacs
>	hoehle
>symbolic names:
>	initial: 1.1
>	zero: 1.1
>comment leader: ";;; "
>keyword substitution: kv
>total revisions: 4;	selected revisions: 4
>description:
>test of -i option
>----------------------------
>revision 1.4
>date: 1992/11/19 18:38:21;  author: hoehle;  state: Exp;  lines: +2 -1
                                     ^^^^^^ this is not true, I did
"su emacs", and the emacs login became owner of the file foo.lisp.
>EMACS did this change
>----------------------------
>revision 1.3
>date: 1992/11/19 16:52:28;  author: hoehle;  state: Exp;  lines: +1 -0
>hoehle did this change

Did I use wrong compile-time options? Is this the normal behavior for
RCS? I would expect RCS to honor the su command.

--
 	Joerg.
hoehle@inf-wiss.ivp.uni-konstanz.d

Newsgroups: gnu.utils.bug
From: rick@digibd.COM (Rick Richardson)
Subject: gmake incompatiblity with AT&T/USL make
Organization: DigiBoard Incorporated, Eden Prairie, MN
Distribution: gnu
Date: Wed, 18 Nov 1992 06:32:01 GMT

The following makefile fragment doesn't work the same in gmake 3.62
compared with AT&T/USL make on SVR2 (including derivatives HP/UX and
AIX), SVR3.X, and SVR4.X.

XXX=
VAR=foo
$(XXX)VAR=bar

In traditional "make", VAR gets the value "bar".  But in gmake,
VAR gets the value "foo", and a variable called "$(XXX)VAR"
is created with the value "bar".  Apparently, macros aren't
being expanded on the left side of the equals.

This rather bizarre syntax is used in leiu of conditions in
traditional make.  XXX is set to null (as shown above), or
to XXX=# (usually, from an included file), which has the effect
of commenting out the second assignment to VAR.

Although gmake has conditionals, it would be nice if the old way
still worked.

-Rick

-- 
Rick Richardson		Email: rick@digibd.com	This space intentionally
Senior Staff Engineer	Fax:   (612) 943-0803	blank until 1996 elections.
DigiBoard, Inc.		Tel:   (612) 943-5383
Eden Prairie, MN	Radio: N0NMY

Newsgroups: gnu.utils.bug
From: brian@ilinx.wimsey.bc.CA
Subject: tar 1.10 bug with big files, multi-volume update
Organization: InterLinx Support Services Inc.
Distribution: gnu
Date: Mon, 23 Nov 1992 22:32:55 GMT

Hey there,

	I sent a bug report last week regarding tar v1.10 and large
files across multivolumes.  Well I have some more information.

	I put in some debug statements to find the values of various
variables while the archive was being created.  The results are
interesting.  When creating the archive, I got the following
values when changing tapes...

real_s_totsize=5169664, real_s_sizeleft=2402304, head->header.offset=   12235000 

so it appears that there is not an error with creating the header.offset
value as I originally suspected.  Here are the same variables when the 
archive was read back...

real_s_totsize=5169664, real_s_sizeleft=2467840, ar_block->header.offset=   1223
5000

the value of real_s_sizeleft is 65536 bigger when reading that it was when
writing.  Why would this be??

What is real_s_sizeleft??  I suspect it is the number of bytes left to read
to make the current file complete.

any ideas??

brian

-- 
Brian J. Murrell                                        brian@ilinx.wimsey.bc.ca
InterLinx Support Services, Inc.                        uunet!van-bc!ilinx!brian
North Vancouver, B.C.
        Platform and Brand Independent UNIX Support - R3.2 - R4 - BSD

Newsgroups: gnu.utils.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Patch for gawk-2.14 on Sequent Symmetry/Dynix
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Sat, 21 Nov 1992 23:40:28 GMT

These changes were necessary to make gawk compile happily on our Sequent,
because:

1) Dynix doesn't have fmod().
2) The definitions of str{r,}chr should match the prototypes in strftime.c.
3) The prototypes should come before the definitions.

diff -ur tmp/gawk-2.14/config/sequent gawk-2.14/config/sequent
--- tmp/gawk-2.14/config/sequent	Tue May 21 07:03:57 1991
+++ gawk-2.14/config/sequent	Sat Nov 21 15:09:35 1992
@@ -14,3 +14,4 @@
 VPRINTF_MISSING	1 
 BSDSTDIO		1 
 TZSET_MISSING	1
+FMOD_MISSING	1
Only in gawk-2.14: gawk
Only in gawk-2.14: jarthur
diff -ur tmp/gawk-2.14/missing/strchr.c gawk-2.14/missing/strchr.c
--- tmp/gawk-2.14/missing/strchr.c	Sun Nov 18 06:52:09 1990
+++ gawk-2.14/missing/strchr.c	Fri Nov 20 17:27:36 1992
@@ -6,11 +6,11 @@
 
 char *
 strchr (str, c)
-register char *str, c;
+register const char *str, c;
 {
 	for (; *str; str++)
 		if (*str == c)
-			return str;
+			return (char *) str;
 
 	return NULL;
 }
@@ -23,13 +23,13 @@
 
 char *
 strrchr (str, c)
-register char *str, c;
+register const char *str, c;
 {
-	register char *save = NULL;
+	register const char *save = NULL;
 
 	for (; *str; str++)
 		if (*str == c)
 			save = str;
 
-	return save;
+	return (char *) save;
 }
diff -ur tmp/gawk-2.14/missing.c gawk-2.14/missing.c
--- tmp/gawk-2.14/missing.c	Tue Sep 22 17:49:49 1992
+++ gawk-2.14/missing.c	Fri Nov 20 16:50:54 1992
@@ -64,10 +64,6 @@
 #include "missing/strcase.c"
 #endif	/* STRCASE_MISSING */
 
-#ifdef STRCHR_MISSING
-#include "missing/strchr.c"
-#endif	/* STRCHR_MISSING */
-
 #ifdef STRERROR_MISSING
 #include "missing/strerror.c"
 #endif	/* STRERROR_MISSING */
@@ -75,6 +71,10 @@
 #ifdef STRFTIME_MISSING
 #include "missing/strftime.c"
 #endif	/* STRFTIME_MISSING */
+
+#ifdef STRCHR_MISSING
+#include "missing/strchr.c"
+#endif	/* STRCHR_MISSING */
 
 #ifdef STRTOD_MISSING
 #include "missing/strtod.c"
--
Jason Merrill					jason@jarthur.claremont.edu
This is a self-referential .sig which is not particularly interesting.

Newsgroups: gnu.utils.bug
From: rrh@tera.com (Robert R. Henry)
Subject: glibc1.05 buglet in sprintf/fwrite when typeof(size_t)==int
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 17 Nov 1992 17:04:07 GMT

I built a version of glibc using gcc2.2.2 in a cross
development environment, target=sun3 host=sun4,
intended to run a standalone 68020 based platform.

it seems with this configuration of gcc2.2.2 that size_t is an int,
to be consistent (urgh) with sun-lossage; clearly, it should be
an unsigned.  This is a tremendous rathole, I realize.

in vsprintf is the line
  f.__bufsize = (size_t) (f.__put_limit - f.__bufp);
in which __put_limit is initialized to 0xffffffff;
this ends up giving f.__bufsize a large negative number (since size_t
is an int), which then causes these lines in fwrite
	if (n > buffer_space)
	  n = buffer_space;
to be executed (n is now < 0), which is later used as an argument to
	    memcpy ((PTR) stream->__bufp, (PTR) p, n);
and since n < 0 memcpy fortunately copies nothing.


Newsgroups: gnu.utils.bug
From: ellis@nova.gmi.edu (Stew Ellis)
Subject: unresolved symbol _main (???) in linking oleo
Organization: GMI Engineering&Management Institute, Flint, MI
Distribution: gnu
Date: Wed, 18 Nov 1992 01:58:27 GMT

Oleo seems like a slippery program to compile.

After giving up on a failure to include varargs stuff, I punted and defined
__STDC__ as a CFLAG.  I then got to the CELLDEF vs int conflict in
io_utils.c.  Which got me to the erroneous asm stuff, which finally got me
to link, which gives me the error above.

My latest effort was with GCC 2.3.1 on SunOS 4.1.2.  I installed the GCC,
and there were no errors in the stage 3 compile, nor in fixincludes.  I
previously had gotten to the same place with either GCC 1.42 or Sun's
bundled C.  

I did a grep -n "main *(", which rewarded me with about 5 mains.  I do not
want to have to chase tags or something to find where things are supposed to
start.  Can someone give me a clue?

Remember, is it really free if it costs you a dozen hours at whatever your
consulting rate would be?  I'd still rather have socialist software though.


--
--                                                        ___________________
  R.Stewart(Stew) Ellis, Assoc.Prof., (Off)313-762-9765  /   _____  ______ 
  Humanities & Social Science,  GMI Eng.& Mgmt. Inst.   /        / /  /  / /
  Flint, MI 48504      ellis@nova.gmi.edu              /________/ /  /  / /

Newsgroups: gnu.utils.bug
From: bothner@cygnus.com
Subject: Re: Bunutils-2.0 version of ar on a decstation?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 08:25:31 GMT

> I'd like to move my environment over to a
> Dec 5000/240 running ultrix 4.3.

Basically, the binutils do not support DECstations or other
machines using MIPS's object file format.  There is some
minimal support in bfd as needed for gdb, but that is all.
I guess ar could be made to work without too much effort,
but without ld and gas, which would be much more difficult,
who cares?

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.utils.bug
From: meyering@cs.utexas.edu (Jim Meyering)
Subject: indent-1.6 bug with (a ? b(): c); omitted space before `: '
Organization: U of TX at Austin CS Dept
Distribution: gnu
Date: Sat, 21 Nov 1992 14:56:25 GMT

Indent-1.6 (on a sun4) removes the space before the colon in
the example below.

% cat <<'EOF' |indent --ignore-profile -st
f() { return (a ? b () : c); }
EOF
f ()
{
  return (a ? b (): c);
}

Newsgroups: gnu.utils.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: CVS cryptic installation instructions
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Sun, 22 Nov 1992 09:03:57 GMT

I followed the instructions in INSTALL up to the point where it says to run
cvsinit.  Since I wanted to put the source repository in a directory where
I do not have perms, I became root to run cvsinit.  I then set $CVSROOT and
tried to import the cvs source, but the perms in $CVSROOT were not set
properly.  How SHOULD they be set?

--
Jason Merrill					jason@jarthur.claremont.edu
This is a self-referential .sig which is not particularly interesting.

Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: oleo 1.0
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 06:47:33 GMT

oleo 1.0's configure.in doesn't include the check for AC_ISC_POSIX.
This makes it not get the POSIX features in ISC 2.2.1.  Perhaps some of
the other variant checks should be included as well.

Also, io_term.c fails to compile on ISC 2.2.1 with gcc 2.3.1, because it
uses the identifiers TRUE, ERR, and FALSE, and doesn't define them.

Also, the clean targets seem confused:
  clean shouldn't remove parse.tab.c;
  distclean should depend on clean, and (perhaps) not remove core;
  realclean should depend on distclean, and remove parse.tab.c.

Also, Makefile.in should say
  exec_prefix = $(prefix)

instead of /usr/local, so that changes to $(prefix) will be reflected in
$(exec_prefix) by default.

There is no NEWS file.

Newsgroups: gnu.utils.bug
From: leisner@wrc.xerox.COM ( Marty Leisner)
Subject: Opposite of exclude in diff?
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
Distribution: gnu
Date: Mon, 23 Nov 1992 14:16:39 GMT

Diff has an --exclude-from=FILE option for comparing directories...

It would seem to be a good idea to have an --include-from option, so
i could easily comparies source files...

Seems easy, comments?


--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom


Newsgroups: gnu.utils.bug
From: tam@ocgy.ubc.ca (Joseph Tam)
Subject: Gnutar 1.11.1 bug - ownership of directories when extracted as root
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 17 Nov 1992 01:46:00 GMT

You have probably got many reports of this bug, but I'll report it just
in case nobody else has.  Gnutar 1.11.1 doesn't set the ownership correctly
for explicitly created directories when the user is root.  The following
results are from a Sun SparcStation and an SGI Indigo.

Here is the contents of a test archive.

	gnutar tvZf test.tar.Z

	drwxr-xr-x 210/19            0 Nov 17 09:29 1992 test/
	-rw-r--r-- 210/19            0 Nov 17 09:29 1992 test/f1
	drwxr-xr-x 210/19            0 Nov 17 09:29 1992 test/d1/
	drwxr-xr-x 210/19            0 Nov 17 09:29 1992 test/d1/d2/
	-rw-r--r-- 210/19            0 Nov 17 09:29 1992 test/d1/d2/f5
	-rw-r--r-- 210/19            0 Nov 17 09:29 1992 test/d1/d2/f6
	-rw-r--r-- 210/19            0 Nov 17 09:29 1992 test/d1/f4
	-rw-r--r-- 210/19            0 Nov 17 09:29 1992 test/d1/f3
	-rw-r--r-- 210/19            0 Nov 17 09:29 1992 test/f2

user #210 = tam
group #19 = atmos

When extracting the archive as root, I get

	gnutar xZf test.tar.Z
	ls -lR test

	total 1
	drwxr-xr-x   3 root     wheel        512 Nov 17 09:29 d1
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:29 f1
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:29 f2

	test/d1:
	total 1
	drwxr-xr-x   2 root     wheel        512 Nov 17 09:29 d2
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:29 f3
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:29 f4

	test/d1/d2:
	total 0
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:29 f5
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:29 f6


As you can see, the directories have ownership root/wheel.  However, if
you add the f_modified flag, you get the correct ownership at the cost
of changing the original modification time:

	gnutar xmZf test.tar.Z
	ls -lR test

	total 1
	drwxr-xr-x   3 tam      atmos        512 Nov 17 09:40 d1
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:40 f1
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:40 f2

	test/d1:
	total 1
	drwxr-xr-x   2 tam      atmos        512 Nov 17 09:40 d2
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:40 f3
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:40 f4

	test/d1/d2:
	total 0
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:40 f5
	-rw-r--r--   1 tam      atmos          0 Nov 17 09:40 f6


Joseph Tam <tam@ocgy.ubc.ca>   \___ \___________
Department of Oceanography     \___ \___________
University of British Columbia \___ \___________
Vancouver, BC, Canada          \___     \___
V6T 1W5                \___    \___     \___
                       \___    \___     \___
Phone: (604) 822-3911   \_________  \__ \___ \__
Fax:   (604) 822-6091    \______    \__ \___ \__

Newsgroups: gnu.utils.bug
From: store@nobipol.unit.NO (Store manager)
Subject: shellutils stty missing flush
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 21 Nov 1992 21:55:06 GMT

   In shellutils-1.8, the 'stty' program supplied is missing the
'flush' control character. Diffs follow.
   Thanks,
Arne H. Juul -- arnej@lise.unit.no

*** stty.c.orig	Wed Oct 28 21:19:41 1992
--- stty.c	Sat Nov 21 20:22:41 1992
***************
*** 105,110 ****
--- 105,113 ----
  #if defined(VLNEXT) && !defined(CLNEXT)
  #define	CLNEXT Control ('v')
  #endif
+ #if defined(VFLUSHO) && !defined(CFLUSHO)
+ #define	CFLUSHO Control ('o')
+ #endif
  
  char *visible ();
  unsigned long baud_to_value ();
***************
*** 345,350 ****
--- 348,356 ----
  #endif
  #ifdef VLNEXT
    {"lnext", CLNEXT, VLNEXT},
+ #endif
+ #ifdef VFLUSHO
+   {"flush", CFLUSHO, VFLUSHO},
  #endif
  
    /* These must be last because of the display routines. */

Newsgroups: gnu.utils.bug
From: djm@eng.umd.edu (David J. MacKenzie)
Subject: gawk 2.14 Makefile targets
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 20 Nov 1992 17:28:41 GMT

In gawk 2.14, `make test' should be renamed `make check' for the GNU
coding standards.  Also, there should be a `make uninstall' target.


Newsgroups: gnu.utils.bug
From: John_Rouillard@dl5000.bc.edu (John P. Rouillard)
Subject: Possible bug in gtar 1.11.2
Organization: Boston College, Institute for Space Research (Bedford, MA)
Distribution: gnu
Date: Thu, 19 Nov 1992 18:56:49 GMT

Hi:

Using gtar 1.11.1, when I use the following command line:

   tar -cvvf  /dev/null /

and / contains long file names that have to be mangled, I get the
following error message:

  ./tar: Visible longname error

  ?rwxr-xr-x root/system       0 Nov 19 13:33 1992 ././@LongLink unknown file type 'L'
  drwxr-xr-x rouilj/system     0 Nov 19 13:33 1992 usr/tmp/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/foo/
  ./tar: Visible longname error

  ?rwxr-xr-x root/system       0 Nov 19 13:33 1992 ././@LongLink unknown file type 'L'

Why is listing an @LongLink file an error? With a single -v option the
@LongLink files are listed as being on the tape. Why should it be an
error to request a long listing of these files?  

Also, why are the @LongLink files being listed at all. With a "tar
-tvf", these @LongLink files aren't listed at all. Shouldn't the long
listing generated during the creation of the file jibe with the
listing of the file after the fact?

I would very much like to comment out the warning message in list.c at
line 576, but I am not sure why this would be an error in the first
place. Is ignoring this "error" a safe thing to do?

This has implications for some patches I am making to gnu tar to
support saving of verbose listing information to a file so that the
listing infomation isn't lumped into the error stream when gnu tar
produces an archive to standard output. This provides a better
interface between gnu tar and some wrapper scripts that drive the
backup process.

A quick reply would be appreciated.

-- John

-- 
                            John Rouillard
Special Projects Volunteer                	Systems Programmer
rouilj@cs.umb.edu (Preferred Address)	  	rouilj@dl5000.bc.edu
(617) 287-6480					(617) 552-8793

University of Massachusetts at Boston 	  	Boston College
   Boston, MA				  	Institute for Space Research  
					     	   Bedford, MA  
===============================================================================
My employers don't acknowledge my existence much less my opinions.

Newsgroups: gnu.utils.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Thought re: autoconf
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Sun, 22 Nov 1992 06:59:43 GMT

Much of autoconf's work involves finding routines that are missing on the
host machine.  It would seem to me that if the standard ones were included
in libiberty.a (as many are) and autoconf checked for its presence when
deciding which functions were missing, many packages could compile more
easily on more machines.  It just seems to me that since I DO in fact have,
say, vprintf hanging around in libiberty.a, GNU programs should know to use
it.  I'm not saying that this should exclude the workarounds (ever looked
at error.c?), but should be an available option.

Thoughts?

--
Jason Merrill					jason@jarthur.claremont.edu
This is a self-referential .sig which is not particularly interesting.

Newsgroups: gnu.utils.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Re: (none)
Organization: Harvey Mudd College, Claremont, CA 91711
Distribution: gnu
Date: Sat, 21 Nov 1992 23:27:52 GMT

>>>> GSCOTT@manvm1.vnet.ibm.COM writes:

>OBJS = lfan_main.o lfan_track.o lfan_bf.o tb_bf.o
>SOURCES = lfan_main.c lfan_track.c lfan_bf.c tb_bf.c

>$(OBJS): $(SOURCES) $(INCLUDES)
>	$(CC) $(CFLAGS) -c $<

>$ /bin/make -n

>gcc -g -Wall -c lfan_main.c
>gcc -g -Wall -c lfan_track.c
>...

>$ /usr/local/gnu/make -n

>gcc -g -Wall -c lfan_main.c
>gcc -g -Wall -c lfan_main.c
>...

This is not a bug in gcc, but rather a documented feature :).  If you look
in the GNU Make manual (make.texi), you will see that $< is always set to
the FIRST dependency, not to the dependency with the same name as the
target.  Consider the line

>$(OBJS): $(SOURCES) $(INCLUDES)

AIX make is interpreting it one of three ways:

If there are multiple targets and multiple dependencies, then a given
target depends on:

1) The dependency at the same index, plus all dependencies to which no
   target corresponds.
2) The dependency with the same name (minus extension) as the target, plus
   all dependencies to which no target corresponds.

Try rearranging the SOURCES line in your makefile and see if AIX make still
does the right thing; that will tell you which rule it is using.

GNU make is interpreting it as follows:

If there are multiple targets and multiple dependencies, then a given
target depends on ALL of the dependencies.

I think that the GNU behavior makes perfect sense.  To make your Makefile
work under GNU make, you must use an implicit rule.  Change the lines

>$(OBJS): $(SOURCES) $(INCLUDES)
>	$(CC) $(CFLAGS) -c $<

to

%.o: %.c $(INCLUDES)
	$(CC) $(CFLAGS) -c $<

Of course, this won't work under AIX make.  This will probably work under
both:

.c.o: $(INCLUDES)
	$(CC) $(CFLAGS) -c $<

>Below is a script of what happens when the files must be retrieved
>with RCS.  Note, it retrieves all of the correct files, but still only
>tries to compile the first file in OBJS

Yes, because it is using an implicit rule to retrieve the files from RCS,
but not to compile them.

--
Jason Merrill					jason@jarthur.claremont.edu
This is a self-referential .sig which is not particularly interesting.

Newsgroups: gnu.utils.bug
From: schrod@iti.INformatik.TH-darmstadt.DE (Joachim Schrod)
Subject: Re: Difference in sort
Organization: TU Darmstadt
Distribution: gnu
Date: Sun, 22 Nov 1992 14:33:19 GMT

In article <1992Nov20.151359.22899@spectrum.xerox.com>, leisner@wrc.xerox.COM ( Marty Leisner) writes:
> I'm running sort (from textutils version 1.3) on SunOS Sparcs 4.1.2...
> 
> The options are very different then the one on the sun...I don't have
> a posix spec around...most of the time the GNU utilities are
> better...
> 
> [...]
>
> What does posix say?

Sorry, not to answer your question directly, but --

An inofficial version of the POSIX Draft is available by anonymous ftp
from research.att.com, directory /netlib/posix. Currently, it holds
drafts of POSIX.0, POSIX.2, POSIX.2a, and POSIX.2b. (Ie, POSIX.1, the
API, is not there.)
    European folks may want to fetch this files from
ftp.th-darmstadt.de [130.83.55.75], directory pub/docs/posix. It's
mirrored automatically, so it will be up-to-date.

--
Joachim

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Joachim Schrod			Email: schrod@iti.informatik.th-darmstadt.de
Computer Science Department
Technical University of Darmstadt, Germany

Newsgroups: gnu.utils.bug
From: carl@granite.COM (Carl Dahlberg)
Subject: question: PS font conversion
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 23 Nov 1992 20:59:43 GMT

If you've got the time, I have a question:

I've got a PC-version of an Adobe font (EurostileTwo, consisting
of .afm .inf and .pfb files) that I'd like to convert so that we
can use it on our printers and xterms.

Adobe says they don't make any Unix versions of their fonts ("yet"),
but suggested that there was shareware that might do the conversion.
I ftp'd the fontutils-0.5 package and took a look at what was in it,
but there doesn't seem to be anything to help me.  Part of the problem
is that I have no idea what kind of conversion I'd have to do to the
font for it to be availiable to Wyse xterms running off of SCO/Open
Desktop (2.0) Unix.  But hey, the note in the README file suggested
this mailbox for questions, so I thought I'd give it a shot.

Muchly obliged in advance for any help you can give me,
Carl

+-----------------------------+------------------+----------------------------+
| Carl Dahlberg               |                  | carl@granite.com           |
| Information Systems Analyst |    Lost in       | (800) 443-7625 (Toll Free) |
| Granite Computer Products   |      Font        | (510) 769-2849 (Voice)     |
| 1350 South Loop Road        |       Land       | (510) 769-2898/9 (FAX)     |
| Alameda, CA  94501 USA      |                  |                            |
+-----------------------------+------------------+----------------------------+

Newsgroups: gnu.utils.bug