HDTenEightyP/NetNews huggingface dataset:
From: norcott_bill@tandem.com (Bill Norcott)
Subject: Re: How can a Unix process put itself in background?
Reply-To: norcott_bill@tandem.com  (Bill Norcott)
Organization: Tandem Computers, Inc.
Date: Fri, 11 Sep 1992 22:25:46 GMT

In article <18qopsINN12n@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
|> In article <1992Sep11.170405.28836@tandem.com> norcott_bill@tandem.com  (Bill Norcott) writes:
|> >If you have a POSIX 1003.1 conforming system, a process can put 
|> >itself into the background with the setpgid() system call.
|> 
|> You still have to fork first, as the shell (or whatever process started the
|> program) waits for the original process to exit.

Sure, all UNIX user processes are created by fork().  So the process
that wants to put itself into the background was created by fork().
And it's parent should be using waidpid() or wait() to wait for the
death of the child.  But the original question was, how can the guy's
existing (child) process put ITSELF in the background.  This is where
setsid() and setpgid() are used.

-- 
---------------------------------------------------------------------|
Bill Norcott			GUARDIAN POSIX project
Tandem Computers, Inc.		
10600 N. Tantau Avenue		PHONE:  (408) 285-3253
Cupertino, CA   95014		EMAIL: norcott_bill@tandem.com


Newsgroups: comp.unix.internals
From: lma@dayton.Stanford.EDU (Larry Augustin)
Subject: Re: How can a Unix process put itself in background?
Organization: DSO, Stanford University
Date: 10 Sep 92 02:36:31 GMT

lma@dayton.Stanford.EDU (Larry Augustin) writes:

>Someone stopped by my office with this question yesterday.

>A user invokes a program at the shell, and interacts with the program
>for a short time.  Eventually the user selects some "quit" option of
>the program.  Before the program really quits, it wants to go off and
>spend a minute or two checking some database files on disk.  Is there
>any way for the program to return control to the user's shell while it
>does the background stuff?  In effect, the program wants to "detach"
>itself from stdin/stdout, return control to the shell, and continue in
>background for a while before exiting.

>The only solutions we could come up with were based on forking a child
>to do the background part.  is this the only way to do it?  Is there a
>solution that does not need a fork?

I know about job control!  I'm NOT asking how to use job control!  I'm
talking about writing a C program that places ITSELF in background.
I'm not talking about the user typing ^Z.

Please, no more messages telling me how to use ^Z!

The consensus seems to be that it can't be done (without forking), as
whatever shell exec'd the program will be stuck in a wait(), and could
only continue upon death of the child (or some interaction by the
user).  There would have to be some other convention for the running
program to tell the shell to continue.

Larry
Newsgroups: comp.unix.internals,comp.unix.sysv386
From: burris@highspl (David Burris)
Newsgroups: comp.unix.internals
Subject: Re: How can a Unix process put itself in background?
Date: 11 Sep 92 04:20:10 GMT
Organization: Dave's Home PC

From article <lma.716092591@dayton.Stanford.EDU>, by lma@dayton.Stanford.EDU (Larry Augustin):
> lma@dayton.Stanford.EDU (Larry Augustin) writes:
> 
> The consensus seems to be that it can't be done (without forking), as
> whatever shell exec'd the program will be stuck in a wait(), and could
> only continue upon death of the child (or some interaction by the
> user).  There would have to be some other convention for the running
> program to tell the shell to continue.
> 
> Larry

Yes, you MUST fork another process.

Essentially, it looks like this:

pid = fork( );		/* fork the new process */
if( pid != 0 )
{
	/* parent process */

	exit( 0 );
}
else
{

/* Rest of program or exec() to new program */

If you want to inherit standard I/O it gets a little trickier, but
hopefully you get the idea.

-- 
================================================================
David Burris					Aurora,Il.
burris@highspl		           ..!linac!highspl!burris
================================================================
Xref: sparky comp.unix.internals:1807 comp.unix.sysv386:14484 comp.unix.programmer:4654
From: root@candle.uucp (Bruce Momjian)
Newsgroups: comp.unix.internals,comp.unix.sysv386,comp.unix.programmer
Subject: Poll()/select() device driver - new version available
Date: 15 Sep 92 01:17:11 GMT
Organization: a consultant's basement
X-Newsreader: Tin 1.1 PL5

Version 1.03 of Pol is now available.

Pol is my device driver implementation of poll() and select() for
systems that don't have them.

It allows me to run pcomm2.0, iscreen3.2, and ptyshl, all of which
require select() and/or poll().  My SVr3.1 machine has neither pty's,
nor a poll(), select() system call for normal (non-streams) file
descriptors.

I also include a patch to the publically available pty device driver for
System V (see my README on where to get it).

For those of you who already have pol, version 1.02, the only addition
in my 1.03 release is the inclusion of many comments to pol.c.   The
original posted source to comp.unix.internals is my 1.0 release, which
has been greatly improved.

Let me know if you want this and I will e-mail you a copy.

-- 
Bruce Momjian                          |  830 Blythe Avenue
root%candle.uucp@bts.com               |  Drexel Hill, Pennsylvania 19026 
< If your life is a hard drive,      > |  (215) 353-9879(w)  853-3000(h)
< Christ will make a backup for you. > |
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.unix.internals
Subject: Re: How can a Unix process put itself in background?
Date: 13 Sep 1992 16:46:02 +0200
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: 127.0.0.1

In comp.unix.internals, article <ceggQDG00VozICsUcq@andrew.cmu.edu>,
  fl0p+@andrew.cmu.edu (Frank T Lofaro) writes:
> This is a real obscene way of getting it to work, and it very well might
> not work. However, you should give it a try:
> 
[ Fork a child, stop the parent, make child continue parent and exit ]

I thought of this too, and it's sick. :-)  The only problem is that the shell
doesn't notice when the process continues; its state is still "stopped" until
you put it into the background, which of course has no effect on the process.

Job control works as expected, i.e. when the backgrounded process tries to
read/write stdin it gets SIGTTIN/SIGTTOU and you can "fg" it from there.
setsid() and setpgrp() don't seem to affect its behavior if you leave
stdin/stdout alone.

-- 
Well, see, Joyce, there we were, trapped in the elevator.  Now, I had
my tennis racquet and the goldfish; she was holding the Crisco.  Surely
you can imagine how one thing naturally led to another!
-- 
Matthias Urlichs  --  urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de   /(o\
Humboldtstrasse 7 -- 7500 Karlsruhe 1 -- Germany  --  +49-721-9612521     \o)/
Newsgroups: comp.unix.internals
From: rod@philips.oz.au (Rod Roberts)
Date: Tue, 8 Sep 92 05:37:55 GMT
Organization: Philips Public Telecommunications Systems, Melbourne, Australia
Subject: print spooler internal details - need info!
Summary: see subject
Keywords: lpsched spooler sysV

I am attempting to create a programatic interface to the sys-V print
spooler and need to know some internal details ( ie format of the
files: "outputq", "pstatus" & "qstatus" ). I have already read the
section covering the sys-V print spooler in W. Richard Stevens
excellent book "UNIX Network Programming" but need to know more (ie
file formats). Can anyone out there in netland help or a least point
me in the right direction. ThanX in advance!

                                                    Rod

-- 
Rod Roberts
e-mail: rod@philips.oz.au | Phone: +61 (3) 881 3574 | Fax: +61 (3) 881 3577
Philips Public Telecommunications Systems
23 Lakeside Drive, Burwood East 3151, Melbourne, Victoria, AUSTRALIA
Newsgroups: comp.unix.internals,comp.unix.programmer
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: unix process  related information -suggestion needed
Organization: Weber State University  (Ogden, UT)
Date: Tue, 15 Sep 92 18:02:21 GMT

In article <1992Sep15.054440.23924@sbcs.sunysb.edu> synchem@sbcs.sunysb.edu (Synchem proj acct) writes:
>
>Would some kind soul suggest some readings on how to manipulate
>the execution stack, implement light weight processes(simulate
>logical context switch), and use signal contexts, and so on. 
>I hope you get the idea.  All under Unix.  Thanks a lot.

I don't have a reference (other than it has a .ps extension and is in the
technical papers section of the wuarchive.wustl.edu anonymous FTP site and
I have a copy in front of me), but you may want to check out:

Register Windows and User-Space Threads on the SPARC
David Keppel
Technical Report #91-08-01
Department of Computer Science and Engineering
University of Washington
Seattle, Washington  98195

1 August 1991


The problem is not amenable to a general soloution.  You may want to ask
Brown University for a copy of "Brown-Threads", and you may want to get a
copy of "sigsched" (check archie for it).




					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu
---
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
-------------------------------------------------------------------------------
Newsgroups: comp.unix.internals
From: norcott_bill@tandem.com (Bill Norcott)
Subject: Re: How can a Unix process put itself in background?
Reply-To: norcott_bill@tandem.com  (Bill Norcott)
Organization: Tandem Computers, Inc.
Date: Fri, 11 Sep 1992 17:04:05 GMT

In article <lma.716056953@dayton.Stanford.EDU>, lma@dayton.Stanford.EDU (Larry Augustin) writes:
|> Someone stopped by my office with this question yesterday.
|> 
|> A user invokes a program at the shell, and interacts with the program
|> for a short time.  Eventually the user selects some "quit" option of
|> the program.  Before the program really quits, it wants to go off and
|> spend a minute or two checking some database files on disk.  Is there
|> any way for the program to return control to the user's shell while it
|> does the background stuff?  In effect, the program wants to "detach"
|> itself from stdin/stdout, return control to the shell, and continue in
|> background for a while before exiting.
|> 
|> The only solutions we could come up with were based on forking a child
|> to do the background part.  is this the only way to do it?  Is there a
|> solution that does not need a fork?
|> 

If you have a POSIX 1003.1 conforming system, a process can put 
itself into the background with the setpgid() system call.  This
is "set process group".  A process can put itself into the background
by joining a background process group.  A process can find out its
own process group by calling getpgrp().  A process can disconnect
itself from the controlling terminal and create its own session
(and become a session- and group-leader).  This will push the process
into the background.  These are the mechanisms a shell uses to
implement job control.  Take a look at the man pages for these 
functions, I'm sure you can get it to work.

-- 
---------------------------------------------------------------------|
Bill Norcott			GUARDIAN POSIX project
Tandem Computers, Inc.		
10600 N. Tantau Avenue		PHONE:  (408) 285-3253
Cupertino, CA   95014		EMAIL: norcott_bill@tandem.com


Newsgroups: comp.unix.internals
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: How can a Unix process put itself in background?
Organization: Weber State University  (Ogden, UT)
Date: Sat, 12 Sep 92 02:04:57 GMT

In article <1992Sep11.222546.3878@tandem.com> norcott_bill@tandem.com  (Bill Norcott) writes:
>Sure, all UNIX user processes are created by fork().  So the process
>that wants to put itself into the background was created by fork().
>And it's parent should be using waidpid() or wait() to wait for the
>death of the child.  But the original question was, how can the guy's
>existing (child) process put ITSELF in the background.  This is where
>setsid() and setpgid() are used.

	Say!  That's right!  He never said he actually wanted the shell that
launched the program to return -- he just wanted the child in the background
instead of the foreground!  8-).  8-).

	Seriously, I think he wanted the parent (the shell) to keep running
as if the process had completed, but leaving the process in the background.
This is what everything he has posted so far has implied, although not as
tersely.


					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu
---
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
-------------------------------------------------------------------------------
Newsgroups: comp.unix.internals
From: lma@dayton.Stanford.EDU (Larry Augustin)
Subject: How can a Unix process put itself in background?
Organization: DSO, Stanford University
Date:  9 Sep 92 16:42:33 GMT

Someone stopped by my office with this question yesterday.

A user invokes a program at the shell, and interacts with the program
for a short time.  Eventually the user selects some "quit" option of
the program.  Before the program really quits, it wants to go off and
spend a minute or two checking some database files on disk.  Is there
any way for the program to return control to the user's shell while it
does the background stuff?  In effect, the program wants to "detach"
itself from stdin/stdout, return control to the shell, and continue in
background for a while before exiting.

The only solutions we could come up with were based on forking a child
to do the background part.  is this the only way to do it?  Is there a
solution that does not need a fork?

Thanks,

Larry

Larry M. Augustin			ERL 414, M/C 4055
lma@dayton.stanford.edu			Computer Systems Lab
+1 415.723.9285 (voice)			Stanford University
+1 415.725.7398 (fax)			Stanford, CA 94305
From: dave@tetra.co.uk (David Sussman)
Newsgroups: comp.unix.internals
Subject: NFS locking with BSD and System V
Date: 9 Sep 92 12:11:28 GMT
Organization: Tetra Ltd., Maidenhead, UK


I am having problems concerning locking and nfs.  We have on trial a
Sun Sparcstation (Sun OS 4.1.2) with an optical (read/write) jukebox
attatched.  The general idea is to see if it is worth having for backup
and archiving purposes.

Yesterday I had a pressing need for 100Mb to testload a tape on our ICL
DRS/6000 (SVR4), so I started up NFS and mounted one of the optical discs.
Loading the tape was fine, and everything seemed OK until I tried to
run an application.  Our applications use Informix CISAM, and use a
lot of locking, and it seems that the locking is failing.  The ICL has
a most wonderful utility called truss which traces system calls, and
the application is hanging on an fcntl(..., SETLKW).

Now my knowledge of NFS locking is very limited.  The lock daemon is
running on both machines (even though the optical disk is only
exported to the ICL), so what gives?  Is System V locking compatible
with Sun OS locking?

Any ideas ?
-- 
dave@tetra.co.uk           | .signature cancelled due to rain :
dave%tetra.co.uk@ukc.ac.uk |   The 1974 England v West Indies Test Match
...ukc!tetra.co.uk!dave    |   will be shown instead.
Newsgroups: comp.unix.wizards


Seeing that Eric has mentioned the book "STREAMS Programming Book" could
someone give me the full reference for this book so that I can order it
please?

Thanks,
Mike.


--------------------------------------------------------------------------------
E-Mail:       Michael_Bright@hpgnd.grenoble.hp.com || 100024.1101@compuserve.com
              S=mjb;OU1=grenoble;OU2=unix;O=hp;P=hp;A=ATLAS 400;C=FR
In-Real-Life: Michael Bright
Organisation: Hewlett-Packard Grenoble, Telecom Networks Operation
Address:      5, ave Raymond Chanas, 38320 Eybens, FRANCE
Telephone:    [+33] 76 62 58 23 FAX 76 62 14 88
Home:         [+33] 76 54 62 37

Newsgroups: comp.unix.wizards
From: frank@D012S436.sniap.mchp.sni.de ()
Subject: Re: A few UNIX questions
Organization: Siemens-Nixdorf AG
Date: Tue, 8 Sep 92 16:47:06 GMT

bsullivn@sc.sni.ie (Bryan O'Sullivan) writes:
: frank@D012S436.sniap.mchp.sni.de writes:
: 
: ::Because lseek() needs to be able to return -1 on error, and not have it
: ::look like a valid file offset.
: 
: :Umm, and a *signed* file size helps, does it?
: 
: RTFM.  Lseek(2) returns the current position in the file, or -1 on
: error.  If you can think of any way to produce -1 by using unsigned
: values, well ...

UYFH (Use Your F****** Head :-)

Hint: The manual describes things as they are, not as they have to be.

Firstly, There are other ways to signal the error:

1: (unsigned long) -1   works fine, and you only lose one value, instead of
half the value space.

2: If casting upsets you, you can define an ERROR constant as being
the maximum unsigned, for example, and have the same thing going 
for you.

3: 'errno' can be used to signal the error.

Secondly, even if there were no other way to signal the error,
there is no need to considere the file offset stored *on the
disk* as being signed - it's not - a file's size is never negative.

: 
: 	-- Bryan
: 
: -- 
: Bryan O'Sullivan                                             +353-1-767551 x225
: Siemens-Nixdorf Informationssysteme AG                          bryan@sc.sni.ie
: Software Development Centre                    "Theory like mist on eyeglasses.
: Dublin                                          Obscure facts." -- Charlie Chan
--
Frank O'Dwyer		       			Disclaimer: 
Siemens-Nixdorf AG 	                        I will deny everything
Tel.  : +49 (89) 636-40639                      Fax.  : +49 (89) 636-45860
e-mail: Frank.ODwyer@sniap.mchp.sni.de <--Use this, reply-to is broken
Newsgroups: comp.unix.wizards
Subject: how to connect a modem to a Sun SPARCstation?
From: marcello@deis21.cineca.it (Marcello Dalpasso)
Date: 14 Sep 92 23:36:51 +0100
Distribution: world
Organization: Dept. of Electronics, Computer Science & Systems, Univ. of Bologna, Italy


Hi netters,

I'm wondering about connecting a modem to my Sun SPARCstation 1+ (SunOS 4.1.1)
via its serial port.

In particular, I would get the following situation:

1) At home, call the Sun from my PC via kermit and my modem.
2) The modem connected to the Sun replies (it has the auto-answer facility)
3) The Sun offers the login prompt
4) I login into my Sun account
5) I start a program (or a shell-script) such that:
 a) I can hang up at home
 b) In a few seconds, the Sun dials my home phone number
 c) My PC replies to the incoming call and gets a login prompt by the Sun.

Is this procedure possible?
I think so, but I cannot figure out which setup to perform on my Sun and which
software (Public Domain...) I must use.

Any solution is welcome, even partial.
Please reply by e-mail, and I will post a summary.

Thanks in advance.

-- 
	Marcello Dalpasso (e-mail: marcello@deis16.cineca.it)
	D.E.I.S. - Department of Electronics, Computer Science and Systems
	Viale Risorgimento 2, I-40136 Bologna, Italy			
	Phone: +39-51-644-3015 (fax: +39-51-644-3073)
From: hgreenho@axion.bt.co.uk (Hilary Greenhow)
Newsgroups: comp.unix.wizards
Subject: Memory mapping to VMEbus
Keywords: vme SunOS
Date: 14 Sep 92 18:08:08 GMT
Organization: BT Laboratories

I am modifying a VME device driver for a SPARC 1E card running SunOS 4.1e 
and am having problems mapping physical VME addresses to virtual addresses. 

For the simple case when I let the kernel do the mapping at config time I 
get no problems. This method is not sufficient when I want to address the
shared memory of other VME cards.

Ideally, for each card that I want to look at, I would like to be able
to map 4Mbytes of shared memory into my virtual address space.  If
this consumes too many resources I could live with mapping more
smaller chunks (a total of about 250kBytes per card as 2 small bits and
1 big lump)

I believe that there are two approaches.
	1) Using rmalloc and mapin (see below for my current suspect code)
	2) Using segkmem_mapin

I have some documentation and an example for method 1 so may eventually
get it to work. I am currently having problems. When I try to rmalloc
enough clicks for 4Mbytes it fails. When I use a smaller number (1) the
mapping appears to work but when I dereference any data I get a PAGE FAULT
and panic.

I have failed to find documentation for method 2. Any examples would
be appreciated

-- 
E-Mail:       HGreenhow@axion.bt.co.uk (...mcvax!ukc!axion!hgreenhow)
Organisation: BT Laboratories (Software Technology Division)
Snail Mail:   BTL, Rm 306 SSTF, Martlesham Heath, IPSWICH IP5 7RE, UK
Telephone:    +44 473 645573

*********************************
Extract of code for method 1

/*
   When SIZE_IN_BYTES 4Mbytes then rmalloc fails
   When smaller then the mapping apparently works but I get a PAGE FAULT
   and panic even when I think that I am accessing a valid address
*/
  char *vaddr;		/* virtual address */
  int kmx;			/* kernel map index */
  int numClicks;
  int addrOffset;

      numClicks = btoc ( SIZE_IN_BYTES);
      addrOffset = (int)(addr - 
			 ptob (btop ((unsigned int) addr & 0xffffff)));
      if ((kmx = rmalloc (kernelmap, numClicks)) == 0)
	{
	  printf ("bp: no kernelmap for slave memory\n");
	  panic ("bpMapSlave");
	}
      vaddr = (char *)kmxtob (kmx);
     
      mapin (&Usrptmap [kmx], btop (vaddr), 
	     btop (pCpu->cd_pSlvAnchor) | PGT_VME_D32,
	     numClicks, PG_V | PG_KW);

      vaddr += addrOffset;
Newsgroups: comp.unix.wizards
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Subject: Intro to comp.unix.wizards - read before posting! (weekly announcement, last change: Jul 31 10:30)
Followup-To: poster
Organization: Rensselaer Polytechnic Institute, Troy NY
Date: Sun, 13 Sep 1992 10:00:43 GMT
Expires: Tue, 13 Oct 1992 10:00:22 GMT

Please take a moment to read this before posting to comp.unix.wizards
for the first time.

comp.unix.wizards is for in-depth discussion of advanced unix topics.

Elementary questions do not belong in comp.unix.wizards.  Although some
socket questions (for example) are appropriate, "How do I program with
sockets?" is not.

Crossposting to comp.unix.wizards and comp.unix.questions is
inappropriate.  Plenty of wizards read comp.unix.questions and answer
questions there.

A wizard is someone who can rewrite the entire system from scratch.  If
you are not a wizard, you are welcome to follow along the discussions
anyway.  You'll learn quite a bit about how UNIX works.  Caution: post
to wizards only if you are yourself a wizard.

For a list of answers to frequently asked questions (FAQ), please refer
to comp.unix.questions (or comp.lang.c, news.answers, etc...).  "How do
I delete a file whose name starts with a '-' ?" is an example of such a
question.  Please do not ask or answer FAQ's on the net.

Write to Unix-Wizards-Request@BRL.MIL (Subject: subscribe.  Any
message.) if you want a daily digest of this newsgroup mailed to you.

To unsubscribe from the unix-wizards mailing list, send mail to
Unix-Wizards-Request@BRL.MIL Subject: unsubscribe.  It is incorrect to
post such requests to the list, or to mail them to me, though others
may mistakenly do so.

E-mail comments about this posting are welcome.  From time to time I'll
summarize them.

Brian
--
These opinions are mine, and do not necessarily reflect those of any
academic department or computing service at Rensselaer.