HDTenEightyP/NetNews huggingface dataset:
From: amerritt@dante.nmsu.edu (Angela Merritt)
Subject: Need info on 'c' library for tape backup software.
Organization: New Mexico State University, Las Cruces, NM
Date: Thu, 7 Jan 1993 15:08:53 GMT

I'm looking for some information about 8mm tape backup software,
and I'm hoping someone can help!  I have an 8mm tape system on
my 486 pc using a scsi (adaptec) interface.  We are writing
some custom software on the PC and would like to incorporate
the tape backup functions into our code.  My Wish List would
ideally include software that provides the following
functions:

1.  A 'C' library of tape functions so I can operate the
    tape drive directly from my code.

2.  Some sort of standard user interface so the operator
    can do tape functions when not using the custom software.

3.  This is the catch.  The tape formats of the two functions
    above should be interchangable.

I already have some NovaStor software that does the above but
the tape format that results from the 'c' callable routines is
different from their standard canned program.  We really need
just one tape format to worry about!  Since I'm kind of new
to the world of tape backup systems I don't even know if
what I'm looking for is available.  If anyone has any information
about this I would appreciate hearing from you!

Much Thanks
Angie
(Email: amerritt@dante.nmsu.edu)
Newsgroups: comp.bugs.misc
From: j4jbail@srv.PacBell.COM (Jack Bailey)
Subject: Bug in initgroups() when using /usr/5bin/cc (SunOS)
Organization: Pacific * Bell
Distribution: usa
Date: Thu, 7 Jan 1993 01:16:05 GMT

(My apologies if this one is already well known)

The following program demomstrates a bug on SunOS 4.1.2.  The
initgroups() library call fails to set the groups properly when a
program calling it is made with /usr/5bin/cc.  It works okay when
compiled with /bin/cc.

My guess to the cause of the problem has to do with the arugument
types passed to getgroups() from within initgroups().  The SystemV
synopsis calls for arguments of type gid_t (unsigned short); otherwise
the args would be ints.


#include <stdio.h>
#include <sys/types.h>
#include <pwd.h>

main()
{
	struct	passwd *pwd, *getpwnam();

	if((pwd = getpwnam("j4jbail")) == NULL) {
		printf("getpwnam() failed\n");
		exit(1);
	}

	system("id");

	if(initgroups(pwd->pw_name, pwd->pw_gid) < 0) {
		printf("initgroups() failed\n");
		exit(1);
	}

	system("id");

	exit(0);
}

-- 
J.J.Bailey	j4jbail@srv.pacbell.com
Contractor	510.823.6453
Newsgroups: comp.bugs.misc
From: rustomji@sol.cs.wmich.edu (Eric Rustomji)
Subject: OPENWIN 3.0 INCOMPATIBILITY
Keywords: openwin 3.0 dlopen() function
Organization: Western Michigan University
Distribution: usa
Date: Mon, 11 Jan 1993 18:09:40 GMT

Hi there,

I am at present using openwin 2.0 on my SUN Sparc IPC's, and wanted
to move to Openwin 3.0.

I re-adjusted my paths, cause openwin 3.0 on my system does not sit
in the usual place (i.e. /usr/openwin).

When I issue the openwin command, it says:

dlopen() : Stub interception failed...
Error: Cannot connect to X server...giving up...

Could anyone please tell me, why and what is happening here.
I also tried cleaning up the .X  files and I have also set up
the correct paths in my .cshrc file, as well the LD_LIB_PATHS in my
.login file.
It still does not work. PLEASE HELP!!

Thanks.
--
Eric

------------------------------------------------------
Eric  Rustomji         
Email:  rustomji@cs.wmich.edu
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Date: 12 Jan 93 18:37:44 GMT
Distribution: na
Organization: Auspex Systems, Santa Clara

>It does not
>use an external database because no matter how many little fobs and
>bells you allow in such a specification there will always be something
>it can't describe that you want it to.

Are you saying, then, something that amounts to "a Perl script can't run
another Perl script"?  I.e., the "external database" can't just be
another Perl script?
Newsgroups: comp.bugs.sys5,comp.unix.solaris
From: david@cs.uow.edu.au (David E A Wilson)
Subject: Minor formatting bug in stty(1)
Organization: Dept of Computer Science, Wollongong University, Australia
Date: Mon, 11 Jan 1993 05:50:04 GMT

I am sure I reported this as a bug in SysV.2 about 5 years ago...

The System 5 stty(1) displays control characters as ^ followed by a lowercase
letter (unlike the BSD stty(1) which uses ^ + uppercase letter). This is ok
for ^A..^Z, a bit strange for ^[,^\,^],^^ (which appear as ^{,^|,^},^~) but
disastrous for ^_ which appears as ^ (followed by a DEL character which is
invisible on most terminals). If a NUL were valid it would be displayed as
^` rather than ^@. 

The fix is to add 0x40 rather than 0x60 and under Solaris 2.1 can be patched
easily. This is the output from cmp -l on stty & /usr/bin/stty:
 10692 100 140

This is running SunOS 5.1 Generic sun4c sparc.
-- 
David Wilson				+61 42 213802 voice, +61 42 213262 fax
Dept Comp Sci, Uni of Wollongong	david@cs.uow.edu.au
Newsgroups: comp.bugs.sys5
From: dws@ssec.wisc.edu (DaviD W. Sanderson)
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Organization: UW-Madison Space Science and Engineering Center
Distribution: na
Date: Tue, 12 Jan 1993 03:50:32 GMT

>Or, alternatively, it could have all of the "standard" smarts built in,
>but, if possible, source another script that contains local additions;
>that way, you can keep the standard distribution and local additions
>separate, and be able to drop in an updated standard distribution
>without necessarily having to hack local additions in....

My perl script is designed to make it easy to add in new modules for
local additions at 'make' time.  (And of course, you can also
selectively omit any recognition modules you don't want.)  It does not
use an external database because no matter how many little fobs and
bells you allow in such a specification there will always be something
it can't describe that you want it to.  E.g. determining whether a NeXT
Mach executable is stripped requires traipsing through the file using
values you pick up along the way.

DaviD W. Sanderson (dws@ssec.wisc.edu)
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Date: 10 Jan 93 05:58:21 GMT
Distribution: na
Organization: Auspex Systems, Santa Clara

>I'm just learning to use perl and wonder if anyone else thinks that perl
>would be a good implementation language for the extended file(1) that
>Guy describes.

Actually, at this point, most of it is already implemented in another
language, namely C; Ian Darwin's "file", version 3.0, has much of what's
needed, and I sent him a pile of changes that add in some missing stuff:

	I added "beshort" and company, although it still does C-style
	strings for "string";
	

	I added "multi-level" continuations, so that you can say "if
	this matches, the file is an XXX; if so, then if *this* matches,
	it's a YYY type of XXX, and if *that's* true, then if, in turn,
	*this* matchines, the file is a ZZZ type of YYY type of XXX";

	and, it turns out, that plus some other hacks that already exist
	provide some of the string extraction stuff that I wanted -
	*and*, returning to the posting that started this, allows it to
	decode the core files you get from a SunOS 4.x SPARC binary
	that blows up when run on a 5.x machine.

No, I'm not going to distribute it, because one of the files in Ian's
distribution asks people not to distribute modified versions - he ends
up getting mail about it *anyway*, even though the modified versions say
"It's Not Ian's Fault".

However, don't let me dissuade you from writing one in "perl"
(presumably, it would be its own configuration file, or would run its
configuration file); it might be an interesting hack, although I'm not
about to jump in and do it - try posting the suggestion to
"comp.lang.perl" and see if somebody takes it as a challenge....
Newsgroups: comp.bugs.sys5
From: dws@ssec.wisc.edu (DaviD W. Sanderson)
Newsgroups: comp.bugs.sys5
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Date: 10 Jan 93 18:34:51 GMT
Article-I.D.: cs.1993Jan10.183451.7302
Distribution: na
Organization: UW-Madison Space Science and Engineering Center

In article <16320@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>However, don't let me dissuade you from writing one in "perl"

I have already done so, more or less.  I call my program 'magic'.  I
posted an early version in alt.sources some time ago.  I have a
significantly enlarged and speeded-up version which I'll post sometime
this spring, after I'm done with my smiley book.

In any case, 'magic' doesn't use an external configuration file.  All
the smarts are built in, and since it has the full power of perl it can
recognize things that even Guy's proposed extensions to the /etc/magic
file format can't handle.

DaviD W. Sanderson (dws@ssec.wisc.edu)

	"The Noah Webster of smileys is David Sanderson"
		- The Wall Street Journal, 15 Sep 1992
From: gsf@ulysses.att.com (Glenn S. Fowler)
Newsgroups: comp.bugs.sys5
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Date: 10 Jan 93 14:39:07 GMT
Distribution: na
Organization: AT&T Bell Labs

In article <16320@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>>I'm just learning to use perl and wonder if anyone else thinks that perl
>>would be a good implementation language for the extended file(1) that
>>Guy describes.
>
>Actually, at this point, most of it is already implemented in another
>language, namely C; Ian Darwin's "file", version 3.0, has much of what's
>needed, and I sent him a pile of changes that add in some missing stuff:
>
>	I added "beshort" and company, although it still does C-style
>	strings for "string";

instead of changing the magic file format to handle BE/LE, change the
file command to test, for each short/long initial entry, both BE and
LE orderings, and then stick with the ordering for that entry

our local file does this and successfully handles all of the magic
formats on the cross-mounted files for our local architectures
(sun,vax,mipsel,mipseb,i386,dynix,3b,hp,etc.)

by having one file (and one magic file) we get the same output for
a given set of input files no matter what host file runs on and we
avoid the magic file duplication that would be required with
short-beshort-leshort and long-belong-lelong

of course there is a possibility of BE/LE clash or diff architectures
with diff meaning for the same magic, but we haven't hit this yet

Glenn Fowler    (908)-582-2195    AT&T Bell Laboratories, Murray Hill, NJ
uucp: {att,ucbvax}!ulysses!gsf              internet: gsf@ulysses.att.com

Glenn Fowler    (908)-582-2195    AT&T Bell Laboratories, Murray Hill, NJ
uucp: {att,ucbvax}!ulysses!gsf              internet: gsf@ulysses.att.com
From: andrewr@ultrix.EBay.Sun.COM (Andy Roach)
Newsgroups: comp.bugs.sys5
Subject: Re: Can a script find out, under SVR4, the ABI to which a machine conforms?
Date: 7 Jan 93 17:51:25 GMT
Reply-To: andrewr@Eng.Sun.COM
Organization: Sun Microsystems Inc.
NNTP-Posting-Host: ultrix

Why whould a script care. The Generic ABI lists all the commands an
ABI conforming script may call. If a script is attempting to perform
different functions based on architecture type then by definition "sort of"
the script is non ABI conforming.

The goal of the ABI is one executable per architecture and in the case of
scripts, one script per generic ABI for all machines.

Now this doesn't address the real world problem of having servers
export a tree which contains binaries for a bunch of different machines,
but some view this as an admin problem not an ABI problem.

Andy
Newsgroups: comp.bugs.sys5
From: drl@vuse.vanderbilt.edu (David R. Linn)
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Organization: Vanderbilt University School of Engineering, Nashville, TN, USA
Distribution: na
Date: Thu, 7 Jan 1993 15:08:54 GMT

In article <16235@auspex-gw.auspex.com> guy@Auspex.COM (Guy Harris) writes:
>"file" probably should have some way of saying something like
>
>	0	pattern		%! PS-Adobe-*	PostScript document, version %s
>	0	string		%!		PostScript document
>
>It should probably *also* have keywords such as "beshort", "belong",
>"leshort", and "lelong", to extract a multi-byte number in a *fixed*
>byte order, rather than in the machine's *native* byte order.
>
>It should probably also remove the backslash escapes from "string", and
>have a "cstring" type for strings that *do* include the backslash
>escapes, unless AT&T picked up the backslash escapes in SVR4; otherwise,
>the Solaris 2.x "file" is incompatible with the "file" in other SVR4's,
>because the SVR4 one would have an entry
>
>	0	string		\begindata	Andrew Toolkit document
>
>for Andrew Toolkit documents, while the SunOS 4.x and 5.x one would have
>an entry
>
>	0	string		\\begindata	Andrew Toolkit document
>
>Oh, yes, and USL should pick up *all* of the above, including "cstring",
>*and* should pick up the bit-field extracting stuff from the SunOS
>"file", *and* should pick up the damn man page for the magic file format
>- they're all clear wins.  ("Documenting" the format only with that
>quick-and-dirty comment in the beginning of "/etc/magic" is just
>ridiculous.)

I'm just learning to use perl and wonder if anyone else thinks that perl
would be a good implementation language for the extended file(1) that
Guy describes.
-- 
David R. Linn, System/Mail/News Manager	| INET: drl@vuse.vanderbilt.edu
Disclaimer: I speak only for myself	| Phone: [+1] 615-343-6164
      "Some do, some don't and that's the way of the world."
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Date: 10 Jan 93 23:18:57 GMT
Distribution: na
Organization: Auspex Systems, Santa Clara

>instead of changing the magic file format to handle BE/LE,

Too late, I've *already* changed it, and nobody's yet shown any
disadvantages to doing so....

>by having one file (and one magic file) we get the same output for
>a given set of input files no matter what host file runs on and we
>avoid the magic file duplication that would be required with
>short-beshort-leshort and long-belong-lelong

I just changed all the magic numbers for VAX and i386 "a.out" and COFF
executables to use "le{short,long}" and all the "a.out" and COFF magic
numbers for architectures I knew were big-endian to "be{short,long}"; no
duplication was required there.

ELF required a little duplication, so that it extracts the various
fields in the right byte order for the architecture.

That was the *only* duplication required; the same "magic" file works on
big-endian and little-endian architectures (although you may want to
change what entries appear if, say, some particular magic number is used
both for TLA, Inc.'s "a.out" files and FroboTech PLC's "a.out" files).

What happens if you have a field whose value you don't test at all, or
test with a test other than one for equality or inequality, and whose
value you later print?
Newsgroups: comp.bugs.sys5
From: mats@netcom.com (Mats Wichmann)
Subject: Re: Can a script find out, under SVR4, the ABI to which a machine conforms?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Tue, 5 Jan 1993 15:00:47 GMT

guy@Auspex.COM (Guy Harris) writes:

>The SVR4 documentation I have indicates that the "sysinfo()" routine
>will, if given the "command" SI_ARCHITECTURE, return "a string
>describing the instruction set architecture of the current system, e.g.,
>'mc68030', 'm32100', or 'i80486'."

>It also hints that said "command" is used by "uname -p" to return the
>"processor type" string.

>Unfortunately, as I read it, that *doesn't* correspond to the ABI to
>which the machine conforms:

Uname -p is inended as the generic processor type, but was not firmly
enough specified to guarantee that.  The MIPS ABI Group Technical
Committee wrestled with this problem for a while, decided that there
simply hadn't been enough standardization on sysinfo (esp. amongst the
members of that group!) and defined a series of extensions to sysinfo
to handle the needs of that ABI.  Comments were submitted (I believe)
to the ABICC (UI's ABI Coordinating Committee), but I don't know the
results.  I'll look into it, however.

>	the same presumably applies to other ABIs for processors for
>	architectures that have acquired new instruction over time.

>A *program* probably doesn't have to care what the ABI is for the
>machine on which it's running - if it's the wrong ABI, it won't run,
>period - but a *script* might care.  In particular, Frame Maker has a
>"fmarch" script that, at least on some platforms, is used to select the
>directory from which executables are to be run.

Programs may care about other issues - what _version_ of the ABI,
for example, or the detailed processor type (for (yuck) licensing
reasons. There's an open can of worms here.

>If, in fact, "uname -p" returns a *detailed* processor type, rather than
>an ABI type, "fmarch" and, conceivably, other scripts will have to know
>all the detailed processor types that support a particular ABI, and may
>thus have to change over time as new instructions are added to
>instruction sets and new processor types are added.

>Perhaps later SVR4.x releases have already done this, but if not:

>	There should be a new SI_ABI "command" for "sysinfo()", that
>	returns a string that indicates the ABI to which a system
>	conforms; for example, it would return "i386", or something such
>	as that, on 80386-based machines, 80486-based machines,
>	Am386-based machines, Cyrix-chip-based machines, Pentium-based
>	machines, etc..

Not done, but not a bad idea...
-- 
Mats Wichmann
Unisoft Corporation
mats@unisoft.com (or mats@netcom.com)

Silly Disclaimer:  speaking only for myself, except when I'm not.
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Date: 12 Jan 93 18:36:08 GMT
Distribution: na
Organization: Auspex Systems, Santa Clara

>(guy) requires a-priori partitioning of file formats into
>big and little endian classes -- the problem here is that
>there are some formats that are architecture independent
>but still byte order dependent, like the binary cpio format
>the solution is to provide duplicate magic file entries:
>
>0	short		070707		cpio archive
>0	short		0143561		cpio archive

Nope.  Try:

0	short		070707		cpio archive
0	short		0143561		byte-swapped cpio archive

Given that, unfortunately, not all versions of "cpio" are capable of
decoding binary "cpio" files with the opposite byte order, it is
potentially useful to know whether the archive is byte-swapped or not.

>(gsf) is based on the assumtion that a byte swapped binary magic number
>will not clash with other magic file magic numbers (not a problem so far)

Actually, I think the old Sun-2 executable format *does* clash with the
VAX BSD executable format - one has 4 bytes of 0407/0410/0413 in
big-endian order at the beginning, the other has them in little-endian
order at the beginning.

>this method avoids most magic file duplication for formats that cannot
>be a-priori labeled BE or LE -- it also handles byte orderings other
>then BE and LE (pdp shorts were LE but longs were half LE half BE)

Mine handles that as well, although you would have to use "belong" or
"lelong" with a constant the two halves of which are swapped.

>you must provide a duplicate entry for binary cpio, no?

Nope.  See above.

>what about cpu's with byte swap HW jumpers -- does the format change
>or just the byte order (not a trick question, I really don't know about
>this)

It appears, from some of the magic file entries, that the magic number
changes on at least one MIPS object/executable format.

Besides, I, at least, would want to know whether something is a
big-endian or little-endian Frobozz executable, not just whether it's a
Frobozz executable or not....
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Date: 11 Jan 93 21:58:12 GMT
Distribution: na
Organization: Auspex Systems, Santa Clara

>What happens if you have a field whose value you don't test at all, or
>test with a test other than one for equality or inequality, and whose
>value you later print?

Actually, you can pile an additional hack on top of the "test both byte
orders" hack for *some* of those cases - have "file", once it finds a
match with one particular byte order, use the byte order for all
subsequent extractions of numeric data from the file.

It *is* a hack atop a hack, though, and doesn't handle the ELF case,
wherein you find out the byte order of the file by checking a one-byte
field....
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.bugs.sys5
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Date: 10 Jan 93 23:20:42 GMT
Distribution: na
Organization: Auspex Systems, Santa Clara

>In any case, 'magic' doesn't use an external configuration file.  All
>the smarts are built in,

This may, or may not, be convenient; a site might want to have a single
common copy of the program, but have different configuration files on
different machines.  Can a "perl" script source another "perl" script? 
If so, the command would be the first script, and the configuration file
would be the one it sources....
Newsgroups: comp.bugs.sys5
From: lwall@netlabs.com (Larry Wall)
Subject: Re: Improving "file" (was Re: Making Solaris 2.1 smarter...)
Organization: NetLabs, Inc.
Distribution: na
Date: Tue, 12 Jan 1993 19:32:19 GMT

In article <1993Jan12.035032.23598@cs.wisc.edu> dws@ssec.wisc.edu (DaviD W. Sanderson) writes:
: >Or, alternatively, it could have all of the "standard" smarts built in,
: >but, if possible, source another script that contains local additions;
: >that way, you can keep the standard distribution and local additions
: >separate, and be able to drop in an updated standard distribution
: >without necessarily having to hack local additions in....
: 
: My perl script is designed to make it easy to add in new modules for
: local additions at 'make' time.  (And of course, you can also
: selectively omit any recognition modules you don't want.)  It does not
: use an external database because no matter how many little fobs and
: bells you allow in such a specification there will always be something
: it can't describe that you want it to.  E.g. determining whether a NeXT
: Mach executable is stripped requires traipsing through the file using
: values you pick up along the way.

But you do have an external database of sorts, if you have to do a
"make".  And Guy wasn't advocating a passive external database.  His
point still stands--if, from a standard location, you can "source" your
architecture dependent modules at runtime (and you can in Perl, using
"require") then your program can construct itself at runtime, and you
can upgrade either the architecture independent or the architecture
dependent portions without doing any "make" mumbo-jumbo, which is part
of what Perl is all about anyway.  Another way of saying it is that
Perl tries to make compile-time bindings fairly cheap in order to delay
such bindings until invocation time, and that constructing a script
with "make" may be indicative that you aren't using Perl's strengths.

Then again, maybe not.  There's more than one way to optimize your
bindings.  There are certainly valid reasons for doing it earlier--you
just haven't said any of them yet.  :-)

Larry Wall
lwall@netlabs.com