HDTenEightyP/NetNews huggingface dataset:
From: bhoughto@sedona.intel.com (Blair P. Houghton)
Newsgroups: comp.unix.wizards
Subject: Re: /dev
Date: 21 Dec 1992 19:53:38 GMT
Organization: Intel Corp., Chandler, Arizona
NNTP-Posting-Host: stealth.intel.com

In article <1h3m36INNd4l@usenet.INS.CWRU.Edu> cq377@cleveland.Freenet.Edu (David C. Williss) writes:
>  1.  Should I look at the /etc/printcap file to find printers?

Look at the PRINTER environment variable (RTFM getenv(3)),
and then check the printcap(5) and use the first printer
you find there.  That is, *if* the machine has a printcap
(AIX does not; it uses a thing called "qconfig.")

Or just use lpr(1).

>      Assuming that somebody at the user's site is compatent
>      (bad assumption) they would just have to setup printcap
>      The problems here are 1. Based on past experience, I can't
>      assume they know what their doing.

Tough cookies on them, then.  Have the program barf a
warning about a screwed-up printcap.  Users aren't nearly
as fragile as programmers believe.  And if they have any
normal printers to which your output could go, they'll have
to have a working printcap, so it's a bad assumption if and
only if it's a bad assumption that they have a printer.

Or just use lpr.

>2. Seems not all flavors
>      of unix use /etc/printcap. (We're supporting multiple platforms)
>
>  2.  How do I print to a remote printer.  I suppose I could fork
>      and exec lpr.  Is that the reccomended method?  

Barry says to use popen(3) and lpr.  I say, "What he said."

>  3.  For the sake of argument, lets say I ignore printcap and let the
>      user select printer driver/port from within my program.  Is
>      there any way to tell which special files in /dev are ports
>      and which aren't?  Every book I've read talks about "conventional"
>      names, but every implementation seems to have its own ideas
>      as what to name them.  I want to avoid confusing the user by
>      showing such things as /dev/rroot.

Okay, sounds like what you're really saying is they'll have
printers available that never need to use lpr.  Some
plotter drivers I know of are like this, and at least one
plotter around here used to double as a (very strange) text
printer.

The problem with this paradigm is that it takes a fair
amount of history (oral or filed-away) to remember what
devices are what.  Devices that come with a system are
(often but not always) documented.  Devices added to a
system (presumably by the field engineer who installed
this funny printer) may not be, if the local users
who bought the funny printer have misplaced the docs.

				--Blair
				  "Welcome to the real world."
Newsgroups: comp.unix.wizards
From: winzker@scoop.ims.uni-hannover.dbp.de (Marco Winzker)
Subject: Re: resident clock under vt100?
Reply-To: winzker@scoop.ims.uni-hannover.dbp.de
Organization: LFI, Uni Hannover, Germany
Date: Tue, 22 Dec 1992 12:53:53 GMT

In article 25356@blaze.cs.jhu.edu, schles@whatever.cs.jhu.edu (The Skateboard Dude) writes:
[...]
>The problem was I was constantly typing in 'date' to check the time.  Is there
>a command or program similar to TSR's on IBM's which could constantly keep me
>informed of the time and/or have an alarm that could ring the default beep at
>a specific time?  It doesn't even need to be resident, I just want something
>that would run until I pressed ctrl-c or logged out.


Here is the solution to your problem. At least on SunOS.

LEAVE(1)                 USER COMMANDS                   LEAVE(1)

NAME
     leave - remind you when you have to leave

SYNOPSIS
     leave [[ + ] hhmm ]

DESCRIPTION
     leave sets an alarm to a time you specify and will tell  you
     when  the time is up.  leave waits until the specified time,
     then reminds you that you have to leave.  You are reminded 5
     minutes  and  1  minute  before  the actual time, and at the
     time.  After the specified time, it reminds you every minute
     thereafter  10  more  times.  leave disappears after you log
     off.



Regards   Marco

+---------------------------------------------------------------------------+
|    _            If it wasn't hard, | Marco Winzker, LfI, University of    |
| --|&|_    _     they wouldn't call | Hannover, Germany                    |
| --|_| `-o|&|__  it hardware !      | Voice: +49-511-762-5058,  Fax: -5051 |
| --------o|_|    (unknown designer) | winzker@scoop.ims.uni-hannover.de    |
+---------------------------------------------------------------------------+
( Alle Aussagen stellen meine private Meinung dar / All opinions are my own )

Newsgroups: comp.unix.wizards
From: mstowski@seas.gwu.edu (Mike Mstowski)
Subject: MAIL MESSAGE HANDLING
Keywords: MAIL MESSAGE HANDLING 
Organization: George Washington University
Date: Wed, 23 Dec 1992 18:47:26 GMT

 We need to set up our UNIX system so that email addressed to ANY login is
accepted and made available to a single login NOT KNOWN to the author of the
message.  This needs to work for mail origination of the same system as well 
as mail originating on other systems.  What do we have to do to accomplish
this in as portable a way as possible?  Also, is there a manpage, book,
magazine article or other published resource that addresses this in detail
sufficient to make implementation possible?
We have a system where thousands of people login as the same account name,
but have different login levels afterward.  How can they share mail if 
everyone has the same login id?

Xref: sparky comp.unix.wizards:5293 comp.unix.programmer:5750 comp.unix.questions:14856
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.wizards,comp.unix.programmer,comp.unix.questions
Subject: Re: Portability issues in using a memory dump
Date: 21 Dec 92 16:58:35 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <1992Dec17.222402.18347@sj.ate.slb.com>, bharat@sj.ate.slb.com (Bharat Venkatasubramanian) writes:

> I have a wierd problem.  I would like to dump the contents of a chunk
> of contiguous memory locations.   The contents represent some complex
> graph structure which once built is constant over different
> invocations of the program.

> Instead of traversing the graph and dumping its contents, I would
> like to dump the contents of this contiguous memory.  Subsequent
> invocations of this program could then use mmap() system call to map
> the information in this file to the address used when the file was
> first created.

It's a bit ugly, but it should be workable on most systems.  Sendmail
does something similar with its frozen config files.

> The program has static behavior until the creation of this graph and
> so on the same machine I will definitely be able to guarantee the
> availability of that address space.

Are you sure?  Part of that space is probably already occupied by
data/bss.  You'd probably be better off using brk() to set the break to
the appropriate place and then just read()ing in the file.  Be careful
to use only automatic variables....

Unless you are specifically allocating a block of memory for this
purpose, and want to save and restore only that block.  You still may
be better off with read than mmap, if for no other reason than some
systems don't have mmap.

> One of my concerns is will the address space be different on
> different Operating Systems??

Yes.  The difference is usually fairly minor; most UNIXish systems just
give you text/data/stack at runtime, so if you dump out the data
segment you should be OK, even though the data segment may begin at a
different address and be a different size from system to system.  If
you encounter a system that doesn't fit this model, you may have to
abandon this technique.  (On SunOS 4.x, for example, you will likely
have to link -Bstatic if you want to dump the whole data segment,
because otherwise pieces of the conceptual data segment are up at
random addresses thanks to shared object files being brought in at
run-time.)

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: gbarnet@uswnvg.com (Gary Barnette)
Newsgroups: comp.unix.wizards
Subject: Code on a Sun, run on a Tandem?
Date: 31 Dec 92 23:37:51 GMT
Organization: U S WEST NewVector Group, Inc.
X-Newsreader: Tin 1.1 PL5

Question:

I was talking to a friend that mentioned his
company was thinking about developing a huge telecom
package on Sparc stations because of the development,
debug, and revision control tools but the final
destination is a Tandem. A Tandem not running Unix but
running their proprietary system, whatever that is.
This is so they get all the feature of fault tolerance.
Apparently the Unix on the Tandem is missing some. He 
thinks that it's POSIX compliant but I still have
concerns that they are looking for trouble. This is not
a small project...approx. 40+ developers. 

Can anyone tell me if this is possible or is disaster
just around the corner?

Much appreciated,

Gary Barnette
E-mail: gbarnet@uswnvg.com
From: meunier@cyclone.enst.fr (Sylvain Meunier)
Newsgroups: comp.unix.wizards
Subject: Re: crypt()/encrypt() functions ?
Date: 23 Dec 92 23:29:03 GMT
Reply-To: meunier@inf.enst.fr
Organization: Telecom Paris, France

In article <1h8uhgINNded@usenet.INS.CWRU.Edu>, cq377@cleveland.Freenet.Edu (David C. Williss) writes:
-> In a previous article, vec@alnitak.Kodak.COM (Vance Cochrane) says:
-> >In article <1967@enst.enst.fr>, meunier@quasar.enst.fr (Sylvain Meunier) writes:
-> >>Hi,
-> >>
-> >>Are crypt()/encrypt() functions sames for all UNIX ? If I crypt something
-> >>on a UNIX system A does it will be same on a other UNIX system B ?
-> >>
-> >well you could try it and see what happens before you ask 
-> >comp.unix.wizards....
-> >
-> How rude!  Not everybody *HAS* more than one unix system to try it on.
-> I believe the answer is "yes", but I'd have to try it to know for sure.
->
Thanks, Moreover a test on N unix system will never prooved that on a Mth unix
system it will be same result. It could be a rule that all crypt are sames or
just an use... As somebody reply me the DES is normally limited of USA and it
is used by crypt.

-- 

	S. Meunier		E-Mail: meunier@inf.enst.fr
From: Unix-Wizards@BRL.MIL
Newsgroups: comp.unix.wizards
Subject: >To:
Date: 23 Dec 92 21:04:33 GMT

Date: Wed Dec 23 20:16:03 GMT 1992
Received: from BRL.MIL by tintin.csl.sni.be; Wed, 23 Dec 1992 21:16 MET
Received: by snibru.uucp (/\==/\ Smail3.1.25.1 #25.4)
	id <m0n4bVz-0000leC@snibru.uucp>; Wed, 23 Dec 92 20:13 MEZ
Received: from vm1.NoDak.edu by ub4b.buug.be (5.65c/ub4b_02)
	id AA08946; Wed, 23 Dec 1992 20:59:07 +0100
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP V2R2)
   with BSMTP id 2023; Wed, 23 Dec 92 13:57:37 CST
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 2225; Wed, 23 Dec 92 13:57:35 CST
Original-Date: Wed, 23 Dec 1992 14:32:31 EST
Original-Subject: SUBSCRIBE me to Unix new group
Not-Delivered-To: tintin!\  due to 12  Inability To Transfer
     ORIGINAL MESSAGE ATTACHED
     (rmail: Error # 21 'Permission denied by /etc/mail/mailsurr file')
End-Of-Header: 
Content-Type: text
Content-Length: 922

Received: by snibru.uucp (/\==/\ Smail3.1.25.1 #25.4)
	id <m0n4bVz-0000leC@snibru.uucp>; Wed, 23 Dec 92 20:13 MEZ
Received: from vm1.NoDak.edu by ub4b.buug.be (5.65c/ub4b_02)
	id AA08946; Wed, 23 Dec 1992 20:59:07 +0100
Message-Id: <199212231959.AA08946@ub4b.buug.be>
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP V2R2)
   with BSMTP id 2023; Wed, 23 Dec 92 13:57:37 CST
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 2225; Wed, 23 Dec 92 13:57:35 CST
Date:         Wed, 23 Dec 1992 14:32:31 EST
Reply-To: Unix-Wizards@BRL.MIL
From: Tilak Kasturi <tbk@AAAHQ05.AAA.COM>
Subject:      SUBSCRIBE me to Unix new group
X-To:         unix-wiz@vm1.nodak.edu
To: Multiple recipients of list UNIX-WIZ <UNIX-WIZ@VM1.NoDak.EDU>
Content-Type: text
Content-Length: 62

Tilak B. Kasturi
American Automobile Association

tbk@aaa.com
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.wizards
Subject: Re: /dev
Date: 22 Dec 92 18:15:32 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <1h3m36INNd4l@usenet.INS.CWRU.Edu>, cq377@cleveland.Freenet.Edu (David C. Williss) writes:

> I'm working on a software package wich we are porting to Unix and one
> of my parts is the hardcopy output.

> 1.  Should I look at the /etc/printcap file to find printers?

In general, no.  It is perhaps not unreasonable to do this if someone
turns on a configuration option to do so, but don't depend on it.  The
lab I work for, for example, uses a completely different printer
interface that doesn't even know printcap exists.

> 2.  How do I print to a remote printer[?]

I see no reason to make any distinction between "remote" printers and
non-"remote" printers.  In either case, you should use whatever command
you're told to use.

> 3.  For the sake of argument, lets say I ignore printcap and let the
>     user select printer driver/port from within my program.  Is there
>     any way to tell which special files in /dev are ports and which
>     aren't?

Define "port".  We had a VAX with an LP-11 in it, using a dumb driver.
It did nothing but speak to the LP-11; in particular, it did not look
like a tty device.

Anyway, no, and you shouldn't be trying anyway.  You should let the
user configure a command to be used to print.  This may be "lpr".  It
may be "cat >/dev/printer/lwiintx-rm718".  It may be "uux - xyzzy!lpr".
It may be "txt2ps | rsh foobox /usr/local/magic/mumble -name ps".

Note that "user" may mean the person who installs the software.  It
would be reasonable to have the installer configure a few common
options that the end-user can then pick from...but don't forget to let
the end-user specify a command if desired.

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: torek@horse.ee.lbl.gov (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: file system layout
Date: 1 Jan 1993 00:08:16 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.15

In article <1992Dec30.163131.17280@ll.mit.edu> singer@ll.mit.edu
(Matthew R. Singer) writes:
>>Since I am writing just one big file on a newly formatted disk, it
>>should be contiguous (right?) [under SunOS].

In article <lk6u47INN47f@appserv.Eng.Sun.COM> lm@slovax.Eng.Sun.COM
(Larry McVoy) writes:
>Nope.  Even though I wacked it to do contig allocation when it can, it
>still switches cylinder groups every meg or so.  I suppose you could
>dick around with the tuning parameters to make one mondo cyl group.

The `change groups' strategy exists to prevent the local clustering
tactics from turning the file system into a series of unmanageable
clumps.  By forcing a seek every 1 MB or so, the file system tries to
guarantee a high probability of a `well positioned' block being
available whenever needed.  Without this, large files would fill their
primary cylinder group, and new files created in that group would get
scattered hither and yon.

Of course, if you are just going to write one single file on a disk,
the file system policies work against you.  Then again, if you are
going to use the entire disk as a single file, you hardly need a file
system at all....

Incidentally, Margo Seltzer found the following bug in the original BSD
block allocator:

[ffs_alloc.c: your line numbers will differ; in fact your code might
even differ a bit, and/or be found in ufs_alloc.c.  Presumably this is
fixed in SunOS.]
***************
*** 458,464 ****
	 */
	nextblk = bap[indx - 1] + fs->fs_frag;
! 	if (indx > fs->fs_maxcontig &&
! 	    bap[indx - fs->fs_maxcontig] + blkstofrags(fs, fs->fs_maxcontig)
! 	    != nextblk)
		return (nextblk);
	if (fs->fs_rotdelay != 0)
--- 464,469 ----
	 */
	nextblk = bap[indx - 1] + fs->fs_frag;
! 	if (indx < fs->fs_maxcontig || bap[indx - fs->fs_maxcontig] +
! 	    blkstofrags(fs, fs->fs_maxcontig) != nextblk)
		return (nextblk);
	if (fs->fs_rotdelay != 0)

Kirk got the test backwards originally, so the tunefs -a parameter
never mattered....  I no longer have VAXen, but I am curious as to
whether this fix might improve performance on the old RA81 disks.  I
was never able to tune those at all; the performance was always
miserable, never more than a few hundred K per second.
-- 
In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 510 486 5427)
Berkeley, CA		Domain:	torek@ee.lbl.gov
From: Unix-Wizards@BRL.MIL
Newsgroups: comp.unix.wizards
Subject: >To:
Date: 21 Dec 92 23:22:56 GMT

Date: Mon Dec 21 22:02:27 GMT 1992
Received: from BRL.MIL by tintin.csl.sni.be; Mon, 21 Dec 1992 23:02 MET
Received: by snibru.uucp (/\==/\ Smail3.1.25.1 #25.4)
	id <m0n3uDB-0000jAC@snibru.uucp>; Mon, 21 Dec 92 21:58 MEZ
Received: from vm1.NoDak.edu by ub4b.buug.be (5.65c/ub4b_02)
	id AA22077; Mon, 21 Dec 1992 22:47:37 +0100
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP V2R2)
   with BSMTP id 1451; Mon, 21 Dec 92 15:46:08 CST
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 0991; Mon, 21 Dec 92 15:46:05 CST
Original-Date: Mon, 21 Dec 1992 22:30:21 MET
Original-Subject: MS SMTP-gateway
Not-Delivered-To: tintin!\  due to 12  Inability To Transfer
     ORIGINAL MESSAGE ATTACHED
     (rmail: Error # 21 'Permission denied by /etc/mail/mailsurr file')
End-Of-Header: 
Content-Type: text
Content-Length: 1655

Received: by snibru.uucp (/\==/\ Smail3.1.25.1 #25.4)
	id <m0n3uDB-0000jAC@snibru.uucp>; Mon, 21 Dec 92 21:58 MEZ
Received: from vm1.NoDak.edu by ub4b.buug.be (5.65c/ub4b_02)
	id AA22077; Mon, 21 Dec 1992 22:47:37 +0100
Message-Id: <199212212147.AA22077@ub4b.buug.be>
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP V2R2)
   with BSMTP id 1451; Mon, 21 Dec 92 15:46:08 CST
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 0991; Mon, 21 Dec 92 15:46:05 CST
Date:         Mon, 21 Dec 1992 22:30:21 MET
Reply-To: Unix-Wizards@BRL.MIL
From: Lars Hornborg <lasseh@MICROFRONT.SE>
Subject:      MS SMTP-gateway
X-To:         listor@microfront.se
To: Multiple recipients of list UNIX-WIZ <UNIX-WIZ@VM1.NoDak.EDU>
Content-Type: text
Content-Length: 810

I've asked questions relating to the MS SMTP gateway before. This time I'd
like to know if anybody has either

-  succeeded in getting this product to work correctly, in terms of setting
   reply addresses correctly, answering to the correct address in the local
   network, etc.

or

-  knowledge of an alternative third-party product. Our current status is
   that we feel we can't comfortably use or recommend it due to the
   problems mentioned above. I'd very much appreciate advice about alternative
   products for either SMTP or UUCP, but they MUST work with MS Mail.

Happy Holidays,
--
  Lars Hornborg                         Tel: +46-47081065
  Microfront Vaxjo AB                   Fax:        82356
  P G Vejdes vag 15                     Internet: lasseh@microfront.se
  S-352 52  VAXJO
  SWEDEN
Newsgroups: comp.unix.msdos
From: S_GAISER@rzmain.rz.uni-ulm.de (Gaiser Juergen)
Subject: RE:>RE:>Unix for 386
Organization: University of Ulm, Germany
Date: Mon, 21 Dec 1992 11:41:57 GMT
X-News-Reader: VMS NEWS 1.24

Hello John !!

I think, the Linux-System is Freeware and you could copy it from
the fileserver of the university of ulm.

FTP: info.rz.uni-ulm.de
Dir: pub/linux/........
Newsgroups: comp.unix.programmer,comp.unix.internals
From: ernst@opal.cs.tu-berlin.de (Ernst Kloecker)
Subject: RPC descriptions RFC1014 and RFC1057 still up to date ?
Organization: Techn. University of Berlin, Germany
Date: Tue, 29 Dec 1992 13:06:33 GMT

Hi,

I am new to RPC programming and I am using the RFC1044 (XDR) and RFC1057
(RPC) as documentation. Those RFC's were written in 1987 and 1988.
So I am wondering wether they are still valid ?

Apart from that, can anybody recommend other documentation for RPC and
XDR ? I had a look at Stevens' Network book, but he only gives a short
overview.


Thanks for any info, Ernst.
--

-----------------------------------------------------------------------------
Ernst Kloecker      phone: ++49-30-6181635      e-mail: ernst@cs.tu-berlin.de
-----------------------------------------------------------------------------
From: walt@bcarh1d7.bnr.ca (Walt Sullivan)
Newsgroups: comp.unix.programmer
Subject: Re: How can I find the C-beauty program??
Date: 22 Dec 92 16:11:14 GMT
Organization: Bell-Northern Research, Ottawa, Canada
In-reply-to: u7911093@cc.nctu.edu.tw's message of 14 Dec 92 14:26:34 GMT

>>>>> On 14 Dec 92 14:26:34 GMT, u7911093@cc.nctu.edu.tw (Erik Wang) said:

Erik> 	Please tell me where can I find a good C-beauty program as unix's
Erik> cb. Because the cb have some error, I don't like it. I can easy find TP's
Erik> beauty program,but I can't find the C's beauty program. I don't know why...

GNU Indent (probably available via anonymous ftp from prep.ai.mit.edu, check
archie for sites closer to you) is the tool you want. Extremely customizable.


--
Walt Sullivan
INTERNET: walt@bnr.ca (work)
UUCP: walt@orbit.ocunix.on.ca (home)
FIDO: 1:163/109.4
Newsgroups: comp.unix.programmer
From: glenn@admin.acadiau.ca (GLENN DAVIDSON)
Subject: How to get SELECT to return 0?
Organization: Acadia University
Date: Tue, 22 Dec 1992 16:15:47 GMT


	Forgive my ignorance but I need to determine this since the means by 
which the SUN manuals describe do not apply in my case. (ie: Timeout has  
expired) Is there a signal that can be sent from the other process?

---------------------------------------------------------------------------
Glenn Davidson, User Consultant    | New more creative signature in the 
Acadia University Computer Centre  | works. Staye tuned for developements.
Internet: GLENN@ACE.ACADIAU.CA     |
---------------------------------------------------------------------------
Newsgroups: comp.unix.programmer
From: ian@netcom.com (James Ian McGowan)
Subject: Beginner question about chdir()
Keywords: chdir cd environment
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Wed, 30 Dec 1992 16:51:09 GMT

A beginner question:

How can i use the chdir() call in a program and have it affect
the current directory of the parent process?  Is there some
tricky way of telling the shell (csh in this case) to do a cd?

If this is a FAQ, i apologise.  Pointers to sources of
information about how a child process can affect the environment
of its parent would be very welcome.

Thanks
-- 
ian@netcom.com
Newsgroups: comp.unix.programmer