HDTenEightyP/NetNews huggingface dataset:
From: rhealey@ub.d.umn.edu (Rob Healey)
Newsgroups: comp.unix.amiga
Subject: Re: wot ever happen to matt's bsd 4.4 port?
Date: 6 Oct 1992 13:17:36 -0500
Organization: University of Minnesota, Duluth
NNTP-Posting-Host: ub.d.umn.edu

In article <MEHLHAFF.92Oct6010007@soda.soda.Berkeley.EDU> mehlhaff@soda.Berkeley.EDU (ERic MeHlHaFf) writes:
=Last Matt posted about it, he said he'd suspended work on it, due to the
=legal mess caused by AT&T suing BSDI and the UC. Regents about their BSD
=distributions.  I'm afraid that if you want a reasonably priced unix, 
=you'd be best off buying a cheap PC and putting LINUX or 386BSD on it.
=
=But that's just my opinion after being screwed by buying AMIX 1.1
=
	I would suggest that people with an Amiga and determined never
	to pay one cent for any software running on it look into
	helping with the Mach port. See wuarchive Amiga area for
	current code, it needs major work before it can do more
	than load into memory and sit there but hey, you pay for
	software, one way or another...

	By the way, 2.1 AmigaUNIX is a decent SVR4 UNIX, in vast contrast to
	1.1, but you have to be an "evil" capitalist that believes in paying
	money for things in order to get it and be a rich pig with a 3000 or
	heavily upgraded 2500 to use it... 1/2 B^).

		-Rob
Newsgroups: comp.unix.amiga
From: sevigny@vlsi.polymtl.ca (Benoit Sevigny)
Subject: Re: FOR SALE: Amiga Unix 2.1
Organization: Ecole Polytechnique de Montreal
Date: Thu, 8 Oct 1992 21:24:13 GMT

In article <6142@gumby.Altos.COM> clp@gumby.Altos.COM (Chuck L. Peterson) writes:
>Amiga UNIX System V Release 4
>Version 2.1
>For AMIGA 2000 and 3000
>Comes in original Box with all Manuals.
>PRICE:          $500  (Retail: $990)
>
>clp@altos.com

I would like it!!! Especially if you also sell your tape drive.
E-mail me at:

sevigny@info.polymtl.ca

I'm waiting!
--
-=*                                                                         *=-
   __ Skipping every ?86 numbered lines in your code will remove all your
__/// remaining bugs and bottlenecks 8^)
\XX/  Benoit W Sevigny, software engineering student, sevigny@info.polymtl.ca
From: md@ui.org (Mark Doran)
Newsgroups: comp.unix.amiga
Subject: Anyone got a Compressed SLIP streams head??
Keywords: SLIP, cslip
Date: 16 Oct 92 13:48:09 GMT
Reply-To: md@ui.org (Mark Doran)
Organization: UNIX International

Hi there,

With no small thanks due to folks on the net who have already helped
me along, I have now managed to connect my A3000 w/ SVR4 to the office
Suns w/ SunOS 4.1.1 via a dialup SLIP connection (initiated from the
Amiga BTW...send me email and I'll be glad to tell you what I did to
get this to work).

I was trying to run X programs over this set up (from the Sun, displaying
on the Amiga) which does work but really quite slowly...although my xtetris
high score is now really high ;-)

I have the compressed SLIP code which Van Jacobsen and Craig Leres did for
the Sun streams implentation which significantly reduces overhead and hence
boosts interactive performance over dialup lines.

Questions:

1) does anyone have/know of equivalent compressed slip code for the A3000
SVR4 streams implementation??

2) for you SVR4 streams hackers out there, is even possible that porting the
code Van and Craig did might work on the A3000??  I don't speak streams
unfortunately -- I'm much more at home in BSD source...

If necessary, I'll attempt the port myself but I'd like some knowlegeable
person to tell me that there's some chance of success first.

Cheers,

Mark.
--
Mark Doran                                     ATT:  +1 201 263 8400 x 265
Project Manager                                UUCP: m.doran@ui.org
UNIX International                             FAX:  +1 201 263 8401
From: fkao@buengf.bu.edu (Frank Kao)
Newsgroups: comp.unix.internals
Subject: PostScript Document Printing Problem
Date: 14 Oct 92 13:33:01 GMT
Organization: College of Engineering, Boston University, Boston, MA, USA
Originator: fkao@buengf.bu.edu

Hi Netters,

Is there any utilities out there that can read a post script document file,
and print the result onto a regular vt series terminal?

thanks in advance for your response
fkao
Newsgroups: comp.unix.internals,comp.unix.programmer,comp.unix.questions,comp.unix.wizards
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: Fork and Stop
Organization: Weber State University  (Ogden, UT)
Date: Fri, 16 Oct 92 20:37:45 GMT

In article <Bw84x7.GL2@solbourne.com> perrin@solbourne.com (Neil Perrin) writes:
>#include <signal.h>
>
>main()
>{
>  if (fork() == 0)
>  {
>    setpgrp(getpid(), getpid());
>    kill(getpid(), SIGSTOP);
>    printf("In the child process\n");
>  }
>  else 
>  {
>    printf("In the parent process\n");
>    /*
>     * Need to allow the child to setpgrp before exiting.
>     * Better to synchronise some way other than delaying (eg global)
>     */
>    sleep(2);
>  }
>}

This can puke on a heavily loaded system, unless you want to sleep for a
ridiculous amount of time.  The following code gets around this by having
the child explicitly notify the parent when it's ready:

#include <signal.h>

huphandler()
{
}

main()
{
	int	child;

	signal( SIGHIP, huphandler);

	switch( child = fork()) {
	case -1:	/* error*/
		perror( "fork");
		exit( 1);
	case 0:	{	/* child*/
		int	pid;
		int	ppid;

		pid = getpid();
		ppid = getppid();		/* get now (dont kill init!)*/

		setpgrp( pid, pid);
		kill( ppid, SIGHUP);	/* tell parent OK*/
		kill( pid, SIGSTOP);
		printf( "In the child process\n");
		do_child_stuff();
		exit( 0);
	    }
	default:	/* parent*/
		printf( "parent waiting for child to be ready\n");
		pause();		/* wait for sighup*/
		break;
	}

	printf( "Do any other parent stuff before exiting\n");
	exit( 0);
}


					Terry Lambert
					terry@icarus.weber.edu
					terry_lambert@novell.com
---
Any opinions in this posting are my own and not those of my present
or previous employers.
-- 
-------------------------------------------------------------------------------
                                        "I have an 8 user poetic license" - me
 Get the 386bsd FAQ from agate.berkeley.edu:/pub/386BSD/386bsd-0.1/unofficial
-------------------------------------------------------------------------------
Xref: sparky comp.unix.internals:1879 comp.unix.programmer:4955 comp.unix.questions:12084 comp.unix.wizards:4311
From: phil@adam.adelaide.edu.au (Phil Kernick)
Newsgroups: comp.unix.internals,comp.unix.programmer,comp.unix.questions,comp.unix.wizards
Subject: Fork and Stop
Date: 14 Oct 92 07:23:09 GMT
Followup-To: poster
Organization: University of Adelaide, South Australia
NNTP-Posting-Host: adam.adelaide.edu.au

Consider the following code:

------------------------------------------------------------------------
#include <signal.h>

void main(void)
{
  if (fork() == 0)
  {
    kill(getpid(), SIGSTOP);
    printf("In the child process\n");
  }
  else
    printf("In the parent process\n");
}
------------------------------------------------------------------------

What I think it *should* do is print "In the parent process" and leave a
process in a stopped state that when SIGCONT is sent to it will print "In
the child process".

However what happens is that it prints "In the parent process" but does not
leave a child process behind.  Why?

If I remove the kill, then both lines get printed, but this is not what I
want.

What I specifically want is to be able to start a child process, stop it,
and exit the parent, leaving the child in a stopped state.

How can I do this?


Thanks,
Phil.

-- 
   _-_|\    Phil Kernick                        "Sleep all day,
  /     \   University of Adelaide               Party all night,
  \_.-*_/   E-Mail: phil@adam.adelaide.edu.au    It's fun to be a
       v    Phone:  +61 8 228 5914               Vampire!"
Newsgroups: comp.unix.internals,comp.unix.programmer,comp.unix.questions,comp.unix.wizards
From: perrin@solbourne.com (Neil Perrin)
Subject: Re: Fork and Stop
Organization: Solbourne Computer, Inc., Longmont, CO
Date: Fri, 16 Oct 1992 17:07:53 GMT

In article <LIMES.92Oct15195652@ouroborous.eng.sun.com> limes@ouroborous.eng.sun.com (Greg Limes) writes:
>In article <phil.719047389@adam.adelaide.edu.au> phil@adam.adelaide.edu.au (Phil Kernick) writes:
>
>|   #include <signal.h>
>|
>|   void main(void)
>|   {
>|     if (fork() == 0)
>|     {
>|       kill(getpid(), SIGSTOP);
>|       printf("In the child process\n");
>|     }
>|     else
>|       printf("In the parent process\n");
>|   }
>
>
>|   What I specifically want is to be able to start a child process, stop it,
>|   and exit the parent, leaving the child in a stopped state.
>
>Actually, you have succeeded.
>
>Anyway, the child's parent process has exited. The system then uses the
>normal process inheritance rules, and sets your child process' parent
>pointer to process #1, init, who is just happy to sit there doing nothing
>but waiting for and reaping "dead" processes.

Yes indeed, you succeed but only until the parent exits, at which time 
the child is sent both a SIGHUP and a SIGCONT (this can be proven by
catching the signals). So this is the reason the child dies (at least
on SunOS 4.1.2). This occurs because the process group is orphaned when 
the parent exits, and the children are "zapped". To avoid this, a new 
process group can be created for the child, however this introduces a 
possible race, between the parent exiting and the child setting the 
process group. See code below.

Note, that trussing both processes on Solaris shows different symptoms
as the kernel acts entirely differently (eg no killer signals), but
otherwise acts identically to SunOS 4.X.

>Did you check with "ps" to see if your child process is still hanging
>around? I just tried it here (Sun 4/330, SunOS 4.1.3) and while a bare
>"ps" did not show it and neither did "ps a", both "ps x" and "ps tp8"
>did.

Yes you need to use "ps x" to find the process, however without creating
a new process group its history. 

If the shell does not set a new process group for any of its children then 
the grandchild wouldn't go away, however I thought all shells would do this.
This is the only reason I can think of as to why Phil's child hangs around
but mine dies, as they're really the same kernel source, at least in that 
area.

#include <signal.h>

main()
{
  if (fork() == 0)
  {
    setpgrp(getpid(), getpid());
    kill(getpid(), SIGSTOP);
    printf("In the child process\n");
  }
  else 
  {
    printf("In the parent process\n");
    /*
     * Need to allow the child to setpgrp before exiting.
     * Better to synchronise some way other than delaying (eg global)
     */
    sleep(2);
  }
}

Hope this helps. This one intrigued me for a while - it helps having the
kernel source!

	Neil.
-- 
Neil Perrin, Solbourne Computer,  perrin@solbourne.com  (303) 678 4545
From: fkao@buengf.bu.edu (Frank Kao)
Newsgroups: comp.unix.internals
Subject: signal.h examples
Date: 13 Oct 92 15:31:00 GMT
Organization: College of Engineering, Boston University, Boston, MA, USA
Originator: fkao@buengf.bu.edu

Hi, unix gurus:

I am trying to write an timer interrupt driver here, and I am having
all kinds of problems.  I am having trouble understanding the man pages
that came with the Sun OS.  Anyone out there that have an example of
working code, so I can have a better idea of how signal.h works.

thanks
fkao@buengf.bu.edu
Xref: sparky comp.unix.internals:1889 comp.unix.questions:12176 comp.unix.wizards:4347 comp.unix.programmer:4976
From: geek+@CMU.EDU (Brian E. Gallew)
Newsgroups: comp.unix.internals,comp.unix.questions,comp.unix.wizards,comp.unix.programmer
Subject: Re: Fork and Stop
Date: 16 Oct 92 10:44:46 GMT
Article-I.D.: andrew.AerkqSK00VAvMTA1ty
	<Bw84x7.GL2@solbourne.com>
Organization: Administrative Systems, Carnegie Mellon, Pittsburgh, PA

Another thing may be the difference in shells that you are using.
Some shells automatically nohup child processes, and others don't.
See your local man page to know if yours does 


                                  -Brian

-------------------------------------------------------------------------
| "Are they dead?"                                                      |
| "Does it matter?"                                                     |
|   - Pugsley and Wednesday in "The Addams Family."                     |
-------------------------------------------------------------------------
Newsgroups: comp.unix.internals
From: jl@CS.CMU.EDU (Juan Leon)
Subject: copy-on-write fork()?
Originator: jl@SHELLEY.SP.CS.CMU.EDU
Organization: School of Computer Science, Carnegie Mellon University
Date: Tue, 13 Oct 1992 19:07:16 GMT


  I would like to know what flavors of unix, besides Mach, implement
fork() using copy-on-write.

  What I would like the OS to do is to flag the pages of a process which
has executed fork(), without copying them.  Only when the parent or the 
child try to write to a page should that page be copied in a manner
transparent to either process.  

  Ideally, I would have copy-on-write fork() in all commercial unixes.  
In practice, I would like to know how much would I be restricting myself 
were I to assume the efficiency of copy-on-write fork() in whatever system
my code happens to be running.

Thanks,

Juan 

P.S: Please send mail, I'm no unix guru and I don't read this newsgroup.



Newsgroups: comp.unix.internals
From: apas614@chpc.utexas.edu (Andy Heekin)
Subject: trapping signal withn kernel
Keywords: signal kernel
Organization: The University of Texas System CHPC
Date: Fri, 16 Oct 92 14:49:39 GMT


I would like to know if there is a way to catch a SIGINT while a
process is sleeping in the kernel.  I have written a device driver
that sleeps while it waits for a certain event to occur.  I want
the user to have the ability to cntrl-c their way out of the
program that is accessing the device, but I also want to do some
house cleaning first before the process jumps back into user mode.
Can this be done?
				       thanx,
				       Andrew Heekin
				       Univ. of Texas @ Austin
Xref: sparky comp.unix.internals:1885 comp.unix.programmer:4969 comp.unix.questions:12157 comp.unix.wizards:4330
From: limes@ouroborous.eng.sun.com (Greg Limes)
Newsgroups: comp.unix.internals,comp.unix.programmer,comp.unix.questions,comp.unix.wizards
Subject: Re: Fork and Stop
Date: 15 Oct 92 23:56:52 GMT
Organization: Sun Microsystems Computer Corporation
NNTP-Posting-Host: ouroborous
In-reply-to: phil@adam.adelaide.edu.au's message of 14 Oct 92 07:23:09 GMT

In article <phil.719047389@adam.adelaide.edu.au> phil@adam.adelaide.edu.au (Phil Kernick) writes:

|   #include <signal.h>
|
|   void main(void)
|   {
|     if (fork() == 0)
|     {
|       kill(getpid(), SIGSTOP);
|       printf("In the child process\n");
|     }
|     else
|       printf("In the parent process\n");
|   }


|   What I specifically want is to be able to start a child process, stop it,
|   and exit the parent, leaving the child in a stopped state.

Actually, you have succeeded.

Anyway, the child's parent process has exited. The system then uses the
normal process inheritance rules, and sets your child process' parent
pointer to process #1, init, who is just happy to sit there doing nothing
but waiting for and reaping "dead" processes.

Now, you are *not* going to get the C-shell to recognize your child
process as a "stopped job". The process CSH started has already died
and the shell has forgotten about the job.

Did you check with "ps" to see if your child process is still hanging
around? I just tried it here (Sun 4/330, SunOS 4.1.3) and while a bare
"ps" did not show it and neither did "ps a", both "ps x" and "ps tp8"
did.

I think you have left some random processes, whose PPID is now "1",
hanging around on your system. You might want to use "ps x" to find
them and kill them off.

Perhaps you want to do something like this?

  #include <signal.h>

  void main(void)
  {
    printf("Process stopping\n");
    kill(getpid(), SIGSTOP);
    printf("Process restarting\n");
  }
Newsgroups: comp.unix.internals
From: thayer@cs.columbia.edu (Charles Thayer)
Subject: Re: System V IPC
Organization: Columbia University Department of Computer Science
Date: Fri, 16 Oct 1992 04:43:03 GMT

>Piercarlo Grandi writes:
>++ All the system V IPC mechanisms are completely inconsistent
>++ with the rest of the i/o facilities provided by Unix.
>+And for a damn good reason! They do not come from Unix, really. The
>+reason for which they exist at all, when named pipes would have been
>+sufficient, is that a particular group within AT&T used a particular

Named pipes are not sufficient, sockets maybe :)  Either way I don't 
like sys V, but am not terribly happy with BSD either.  Mach is getting
warmer, but not there yet.

-- 
==============================================================================
Charles Thayer, Columbia University, Dept. CS, Tech-staff... my words only.
Newsgroups: comp.unix.internals
From: jlbrand@pb2esac.uucp (Jack Brand)
Subject: Re: System V IPC
Organization: Pacific*Bell ESAC, Oakland, CA.
Date: Mon, 12 Oct 1992 07:15:07 GMT


Piercarlo Grandi writes:

++ All the system V IPC mechanisms are completely inconsistent
++ with the rest of the i/o facilities provided by Unix.

+And for a damn good reason! They do not come from Unix, really. The
+reason for which they exist at all, when named pipes would have been
+sufficient, is that a particular group within AT&T used a particular
+version of something that looked like Unix, and they needed for their
+real time application (switching) an especially fast, if crude, IPC
+mechanism, so they came up with a set of interfaces that were custom
+designed for their application and nothing else.

Are you saying that "named pipes would have been sufficient" for the
application you allude to and/or to all applications in SysV which have 
since made use of message queues, semaphores and shared memory???
This seems a bit indefensible...

By the way, CBUNIX was not for switching but for Operations Support
Systems (see Rochkind...)

+Piercarlo Grandi                   | JNET: pcg@uk.ac.aber
+Dept of CS, University of Wales    | UUCP: ...!aber-cs!pcg
+Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@aber.ac.uk

Jack Brand
From: gram@aim1.aztec.co.za (Graham Wheeler)
Newsgroups: comp.unix.internals
Subject: Question about timeout()
Date: 13 Oct 92 12:12:55 GMT
Article-I.D.: aim1.gram.718978375
Organization: Aztec Information Management

Hi all

I notice from the source of SAS that the implementors use a single integer
variable for timeout IDs, with the value zero indicating that no timeout
is scheduled. Is this legitimate? I have always used two variables, one for
the ID and the other a `timeout scheduled' flag. This was based on the SVR4
manual entry for timeout:

RETURN VALUE: If the function specified by fn is successfully scheduled,
	timeout returns an identifier that can be passed to untimeout to
	cancel the request. If the function could not be scheduled (because
	the timeout table is full), the following panic message results:

		PANIC: timeout table overflow


(This has to be the most absurd `return value' I've ever seen - a routine
that might cause a panic if you call it! Surely the implementors could have
designed it to return -1 on failure instead of panicking the system.)

Anyway, from this, it appears that 0 is a legitimate timeout ID value and
thus cannot be used the way it is in SAS (where the code has things like

	if (timeoutID) {
		untimeout(timeoutID)
		timeoutID = 0;
	}

and I instead use:

	if (timeoutScheduled) {
		untimeout(timeoutID);
		timeoutScheduled = 0;
	}
)

This is not a critical issue, as I am happy with the way I am doing it; I
just wonder if the SAS designers know something that I don't.

Right at the moment our e-mail is very flakey so please post replies rather
than mailing them. Thanks!

-- 
Graham Wheeler                     | "That which is weak conquers the strong,
Network Systems Programmer         | that which is soft conquers the hard."
Aztec Information Management       | 		Lao Tzu - Tao Te Ching Ch. 78
gram@aim1.aztec.co.za              | There's no justice, there's just us
From: jc@minya.UUCP (John Chambers)
Newsgroups: comp.unix.internals
Subject: Re: How can a Unix process put itself in background?
Summary: if (fork()) exit(0);
Date: 8 Oct 92 02:56:46 GMT

Well, all those convoluted methods  are  certainly  entertaining,  but
what I usually do is just:

	if (fork()) exit(0);

Well, I suppose  there  is  a  technicality  that  says  this  doesn't
*exactly*  answer the original question:  The background process has a
different pid than the  original  process,  so  the  process  *really*
hasn't put *itself* in the background.

What this really is is an answer to an almost identical question: "How
can a Unix program put itself in the background?" If you don't care to
quibble over the distinction between a process and a program, then the
above is usually what you want. I'm disappointed that nobody suggested
it (at least in the articles that made it here ;-), as there's a  good
chance that the original questioner would have found it acceptable.

But I was entertained by the other approaches.  I'm  still  trying  to
think  of  a situation where it's vital that the background process be
the same process that was in the foreground, and  not  just  the  same
program  with all the same files and everything.  Maybe something that
has to do with inter-process communication, where the  processes  have
already noted each others' pids for subsequent uses in kill() ...

-- 
All opinions Copyright (c) 1992 by John Chambers. Inquire for licensing at:
1-617-647-1813 ...!{bu.edu,harvard.edu,eddie.mit.edu,ruby.ora.com}!minya!jc 
--
Pensu tutmonde; agu loke.
From: ericma@soda.berkeley.edu (Eric S. Ma)
Newsgroups: comp.unix.wizards
Subject: Change WINSIZE under curses
Date: 15 Oct 1992 01:11:45 GMT
Organization: U.C. Berkeley, CS Undergraduate Association
Distribution: world
NNTP-Posting-Host: soda.berkeley.edu

Can someone please tell me how to handle window size change in curses? It
seems it can't be done easily in curses. Thanks in advance for any help.
Please reply by email.


Eric Ma
ericma@soda.Berkeley.EDU
From: jsm@shade.Princeton.EDU (John Scott McCauley Jr.)
Newsgroups: comp.unix.wizards
Subject: can I plock() another process?
Date: 15 Oct 92 19:39:53 GMT
Organization: Princeton University
Originator: news@nimaster

Hello,
	I am having trouble with CPU hogs swapping out interactive processes
(csh, xterm, vtwm).  I suppose I could add a plock(TLOCK) in every process
I don't want swapped  out, but that would require recompiling a lot of
code plus locking too much memory would be bad.

	Anyone have such a program? Would it be possible to write a program
to do this? Call it 'plock pid', where pid is the pid of a process to lock.
Plock would:

	open /dev/mem, /vmunix
	look through the process table to find the pages corresponding
	     to the text segment of 'pid'
	mmap these pages to plock's data space  
	lock these pages in core using shmctl.
	sleep forever or exit ?

Would this work? I'd probably start with the source to 'gcore' as it 
finds the pages in /dev/mem.

	Thanks,

		Scott
Newsgroups: comp.unix.wizards
From: fgs@kepler.unh.edu ( F r e D  S l a m A )
Subject: TTL value in ip struct
Organization: University of New Hampshire  -  Durham, NH
Distribution: usa
Date: Fri, 9 Oct 1992 03:32:18 GMT




		In order to manually generate, fill in, and prepend an ip
		header (struct ip) to an outgoing IP datagram, trace route
		implementations, for example, reply on a kernal patch to
		prevent the system from doing so itself. IPPROTO_RAW will
		allow the receipt of all of the incoming header & data info
		as recieved. 
			My question. Shouldn't there be (is there?) a better way than a
	    kpatch to allow, for example, the time to live field to
		be changed prior to sending?
			This Q must have been raised at some point. I am just a
		little late..

			Gush forth O oracle of knowlege..
				
										Thanks,
													Fred
			

-- 
 ===============================================================================
 Frederick G. Slama at >>>>>>>>>>>>>| slama@ctron.com (just a CO-OP)
 The University of New Hampshire <<<| fgs@kepler.unh.edu   F_SLAMA@unhh.unh.edu
 ===============================================================================