HDTenEightyP/NetNews huggingface dataset:
From: janc@amix.commodore.com (Jan Carlson)
Subject: Re: /dev/ser setup help needed.
Organization: Amiga UNIX Software Development
Distribution: usa
Date: Mon, 7 Sep 1992 00:07:39 GMT

In article <1992Sep4.051025.27253@becker.GTS.ORG> bdb@becker.GTS.ORG (Bruce Becker) writes:
>In article <1992Sep1.045617.5077@amix.commodore.com> janc@amix.commodore.com (Jan Carlson) writes:
>|
>|The baud rate of incoming calls depends on /etc/saf/serial/_pmtab.
>|The baud rate of outbound cu is controlled by /etc/uucp/Devices entries.
>|
>|In both cases you can reliably run at 38,400 baud on the built-in serial port
>|with no tricks.  
>|
>|This trick sounds like a joke, but it is not: Set the built-in serial
>|port to 50 baud and it will actually run at 115,200 baud.  Set it to 75
>|baud to actually run at 57,600 baud.  
>
>
>	Will these work OK with an A2620?

I don't see why not.

>
>
>|The Commodore A2232 7-port card is limited to 19,200 baud per port though.
>
>
>	Since the A2232 has the ability to do 115,200
>	baud (but nothing else above 19200), will the
>	above trick work for it too?

Yes too.  That would make a nice direct connection for slip

>
>
>-- 
>  ,u,	 Bruce Becker			Toronto, Ontario
>a /i/	 Internet: bdb@becker.gts.org	Uucp: ...!web!becker!bdb
> `\o\-e	 "We want the worm, and we want a cow!"
> _< /_	 	- More Jimison, ordering drinks for his table


Newsgroups: comp.unix.amiga
From: crash@ckctpa.UUCP (Frank "Crash" Edwards)
Subject: Re: HELP!! Is there a LoadSeg command or an Overlay under Unix?
Date: Thu, 10 Sep 1992 23:11:41 GMT
Reply-To: crash%ckctpa@tct.com (Frank "Crash" Edwards)
Organization: Edwards & Edwards Consulting

slmt9@cc.usu.edu (Joshua Dinerstein) writes:
>	Hi All,
>
>	Is there a LoadSeg type of command under Unix? Or even and overlay
>manager?
>
>	Any information at all would be great!

Hmmm, I suppose this isn't a joke, eh?

(Most) Unix implementations provide a flat memory model (as opposed to
a segmented model) which utilizes a virtual memory scheme that renders
an "overlay manager" obsolete.  Just keep dynamically allocating
memory using malloc() or some such and the system will provide up to
(physical memory) + (paging space) - (some constant) amount of memory
to your program.

There are efficiency considerations of course, but they don't usually
figure in until you start paging pretty bad -- check the man pages on
swap(1) and ps(1) for some information on process management by the
kernel.

If your question was really, "how do I spawn another program" then
that should have been the question asked (!).  The easiest way is to
call system(3) with a character string which contains the command line
you want executed.  The shell (determined by the SHELL environment
variable) parses the command so it may contain I/O redirection, pipes,
wildcards, etc.

However, system(3) is not the most secure nor the most efficient way
to get the job done.  It is implemented using system-level calls known
as fork(2), exec(2), and wait(2).  There is an entire family of
exec(2) routines and wait(2) routines; look in the man pages for
details.

Some versions of Unix, such as Amiga Unix, provide for dynamic linking
of object modules into the executing program at _run_time_.  This
allows a program, for example, to decide which algorithm it wants to
use and then dynamically link in the associated object module and
execute it.  When it's done, it frees that module and its resources.
Something similar to this can be arranged with shared libraries (see
ld(1) and ar(1) in the man pages).

>	Thanks
>	Joshua

Perhaps you could ask your question(s) in terms of what you want to do
rather than what you want to implement?  Generally that lets other
netters hear the problem and you get flooded with a variety of answers
that you can simply pick from.

-- 
Frank "Crash" Edwards            King Marine Electronics, Inc.
Home: 813/786-3675               Work: 813/530-3411
    There will be times in life when everyone you meet smiles and pats you on
    the back and tells you how great you are ... so hold on to your wallet.
From: ford@yoda.uucp (Mike "Ford" Ditto)
Newsgroups: comp.unix.amiga
Subject: Re: /dev/ser setup help needed.
Summary: term/ql*: 38400 = 115200;  term/ser: 50 = 115200
Date: 11 Sep 92 09:03:46 GMT
Reply-To: ford@yoda.uucp (Mike "Ford" Ditto)
Organization: Omnicron Data Systems

janc@amix.commodore.com (Jan Carlson) writes:
> Set the built-in serial port to 50 baud and it will actually run at
> 115,200 baud.

In article <1992Sep4.051025.27253@becker.GTS.ORG>
bdb@becker.GTS.ORG (Bruce Becker) writes:
>	Since the A2232 has the ability to do 115,200
>	baud (but nothing else above 19200), will the
>	above trick work for it too?

Yes, but note this oddity:

	To do 115200 bps on term/ser, use "stty 50".
	To do 115200 bps on term/ql*, use "stty 38400".

Why are they different?  Because the builtin serial hardware can do
38400 but can't do 50, and the A2232 ports can do 50 but can't do 38400.
It makes sense for the supported baud rates to be specified by the
corresponding stty setting.  If there were a standard speed that was
unsupported on both kinds of hardware, it would be the obvious choice,
but there isn't one.

It just shows to go you -- through many years of evolution of Unix and
its terminal interfaces, nobody was smart enough to make a reasonable
baud rate interface.  Even the more recent efforts like POSIX introduced
new, incompatible interfaces, but which perpetuate the braindamage.

					-=] Ford [=-

"I was a piece of yogurt."		(In Real Life:  Mike Ditto)
    -- Roel Pieper			ford@yoda.uucp
					uunet!cbmvax!kenobi!ford
From: ahh@moji.uucp (Andy Heffernan)
Newsgroups: comp.unix.amiga
Subject: Re: Switching to X11r5
Date: 8 Sep 92 21:56:58 GMT
Organization: Something or other

In article <joe.06q6@jaguar.eagle.mission.tx.us> joe@jaguar.eagle.mission.tx.us (Joe Gonzalez) writes:
>Hello! I'm having some trouble switching to X11r5 on my UNIX 2.1p2a
>Amiga. I pulled the source off the tape (If there's an easier way than
>a complete rebuild, please let me know :) and tried to do a 
>     make World BOOTSTRAPCFLAGS=  ...
>just like it says in RELNOTES.TXT but make responds with an error 
>about no seperator between rules on line 1544. Since this line is
>blank, I dont know what to try. I'd really appreciate any info on
>getting r5 up and running. Thanks for any info!

	I've seen that before somewhere.  Find the Makefile that has
the error.  Then find the Imakefile which produced the Makefile.  I'll
bet that one of the blank lines in the Imakefile really has one or two
tab characters in it.  Delete the tab(s) and restart the build so that
the Makefile gets regenerated and then the Makefiles get run.
-- 
Andy Heffernan          $BJ8;z(J    ahh@moji.uucp (uunet!glyph!moji!ahh)
"Your bangability is very high tonight, baby." -- Arnold Schwarzenegger
                       -[ Quayle/Ice-T in '96. ]-
Newsgroups: comp.unix.amiga
From: crash@ckctpa.UUCP (Frank "Crash" Edwards)
Subject: Re: (/usr/ucb) 'ls' bug report
Date: Fri, 11 Sep 1992 02:47:51 GMT
Reply-To: crash%ckctpa@tct.com (Frank "Crash" Edwards)
Organization: Edwards & Edwards Consulting

vandel@di.epfl.ch (Jean-Marc Vandel) writes:
>I found a BIG bug in '/usr/ucb/ls' under Amix 2.03, while configuring my anonymous ftp : 
>the ucb version always display the MAJOR number of a device as '0' !!!
>Is this bug still present in Amix 2.1 ? Does it exists in other SVR4 ?
>--

I don't mean to be too snide, but does it matter?  It is BSD after all...

>                                           Jean-Marc Vandel
>    Swiss Institute of Technology     |    E-mail : vandel@di.epfl.ch

-- 
Frank "Crash" Edwards            King Marine Electronics, Inc.
Home: 813/786-3675               Work: 813/530-3411
    There will be times in life when everyone you meet smiles and pats you on
    the back and tells you how great you are ... so hold on to your wallet.
From: rblewitt@sdcc3.ucsd.edu (Richard Blewitt)
Newsgroups: comp.unix.amiga
Subject: Re: Unix and the New Amigas
Date: 13 Sep 92 07:19:24 GMT
Organization: University of California, San Diego

In article <79600@ut-emx.uucp> sjk@ut-emx.uucp (Phil Alvin) writes:
>
>Does anyone know if Commodore's Unix is going to run on any of the
>new '040 machines - specifically, the A4000 and the 3000T '040?
>
>Also, did WOC produce any comment from Commodore on their
>commitment to or future plans for Unix?

Since getting Unix to run on an 040 would take a large ammount of
work, they were thinking of doing the port directly from the new
(4.2 or 4.3, I forgot which) version of the Unix kernal.  When such
a beast will come out, who knows.

Rick

-- 
_____________________________________________________________________
_____________________________.sig____________________________________
_____________________________________________________________________
The generic .sig          Rick Blewitt     rblewitt@ucsd.edu
From: mike@agrijag.UUCP (Mike Schiller)
Newsgroups: comp.unix.amiga
Subject: Re: MINIX stuff for 3000?, or MD's port of Berkley, or upgrade C=?
Date: 9 Sep 92 00:28:29 GMT
Organization: Not an Organization
X-NewsSoftware: GRn 1.16e (7/4/92) by Mike Schwartz & Michael B. Smith

Can anyone tell me more about Minix? How well implemented is it for the A3000?
I currently have an older A3000UX with v1.1 AmigaUnix (or whatever it's called)
Would I be better off to upgrade to AmigaUnix 2.1 (lots of $$$), get Minix, or
wait for Matt Dillon's port of Berkley Unix 4.x ?
--
                        -Mike Schiller
                         CIS  : 76416,3065 or 76416.3065@compuserve.com
                         BIX, GEnie, DELPHI  : schiller
                         UUCP : ...uflorida!novavax!agrijag!mike
From: umsmigi0@ccu.umanitoba.ca (Trevor Allan Smigiel)
Newsgroups: comp.unix.amiga
Subject: Re: Amiga SCSI tape (Caliper CP-150SAEH)
Date: 7 Sep 92 21:01:06 GMT
Organization: University of Manitoba, Winnipeg, Canada

In <1992Sep04.000029.26458@mhs.oz.au> jimbo@mhs.oz.au (James Davidson) writes:


>I am looking for info on the jumper settings of the
>Caliper CP-150SAEH tape drive.  This is the tape drive
>that was shipped with our Amiga 3000 UX.  The jumpers
>are located inside the casing with must be removed to
>get at them.

	I need these as well. Could some please post the info,
instead of e-mail?

Thanks,
From: fl0p+@andrew.cmu.edu (Frank T Lofaro)
Newsgroups: comp.unix.internals
Subject: Re: How can a Unix process put itself in background?
Date: 12 Sep 92 20:43:59 GMT
Article-I.D.: andrew.ceggQDG00VozICsUcq
	<18rlr4INNi23@early-bird.think.com>
Organization: Sophomore, Math/Computer Science, Carnegie Mellon, Pittsburgh, PA

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:

Have the process fork. (don't worry, the parent is what lives on in the
end, not the child, so this should be okay for you.)
The parent does a kill(getpid(),SIGSTOP).
The child does a sleep(1);kill(getppid,SIGCONT), and then exit
after the parent resumes, have it mess with the tty so that it is in the
background as far as tty interaction goes (e.g. setsid()).

Note: sleep(1) should be enough, but it might not be.
Also, this is a real kludgy way of doing it, but it has a good chance of
working.

The process getting itself stopped should cause the wait4 in the shell
to return. The fork and sigcont are needed so that the process doesn't
sleep forever.

I hope this helps.
Newsgroups: comp.unix.internals,comp.unix.programmer
From: synchem@sbcs.sunysb.edu (Synchem proj acct)
Subject: unix process  related information -suggestion needed
Organization: State University of New York at Stony Brook
Date: Tue, 15 Sep 1992 05:44:40 GMT


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.

- Chyouhwa
From: libes@cme.nist.gov (Don Libes)
Newsgroups: comp.unix.internals
Subject: Re: How can a Unix process put itself in background?
Date: 15 Sep 92 18:37:44 GMT
Organization: National Institute of Standards and Technology

In article <lma.716092591@dayton.Stanford.EDU> lma@dayton.Stanford.EDU (Larry Augustin) writes:
}lma@dayton.Stanford.EDU (Larry Augustin) writes:
}>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?

}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.

Here's a bit of Expect to do this.  It works as follows - when you are
ready to detach the program, you type "~detach".  Expect puts itself
into the background, tells the program to do the "longrunningcommand",
and when done, tells it to exit gracefully.  Obviously Expect is doing
the fork for you.  Nonetheless this is the easiest way to solve the
whole problem without hacking up the original program. - Don

spawn prog                      ;# start program
interact ~detach {
        if [fork] exit          ;# parent exits
        disconnect
        send "longrunningcommand\r"
        expect $prompt          ;# wait for prog to say it is ready to quit
        send "quit\r"           ;# tell program to quit
        expect eof
}
Newsgroups: comp.unix.internals
From: shane@sbgrad7.cs.sunysb.edu (Shane Bouslough)
Subject: Re: How can a Unix process put itself in background?
Organization: State University of New York at Stony Brook
Date: Sun, 13 Sep 1992 18:04:17 GMT

In article <lma.716092591@dayton.Stanford.EDU> lma@dayton.Stanford.EDU
  (Larry Augustin) writes:

>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

I seem to remember there was a signal you could send yourself to be
suspended (this was on MassComp UNIX), but I forget if you could do
so and still be running. Am I hallucinating?

-Shane

--
Shane Bouslough       | #include <stddisc.h>
shane@sbcs.sunysb.edu | #include <happy.rhodes>
Newsgroups: comp.unix.internals,comp.unix.sysv386
From: pham@ucselx.sdsu.edu (Peter Pham)
Subject: How md_space in struct mb_device defined?
Keywords: [SunOS4.1.1]
Organization: San Diego State University Computing Services
Date: Wed, 9 Sep 1992 23:16:54 GMT


I am trying to make a device driver loadable on SunOS 4.1.1
(on a Sun4/330).  There is a structure 'mb_device' that I need
to initialize.  Under this structure, there is a field called
'u_int  md_space'.  The comment for this field (structure 
defined in <sundev/mbvar.h>) says this is a field for "encoded
address space".  Suppose I want the VME address space of 32D32,
what should I put in this field?  Does anyone know the "encoded
address space" is pre-defined some where?

Thanks in advance.

Peter Pham
From: terry@thisbe.Eng.Sandy.Novell.COM (Terry Lambert)
Newsgroups: comp.unix.internals
Subject: Re: How can a Unix process put itself in background?
Date: 10 Sep 92 19:41:31 GMT
Organization: Novell NPD -- Sandy, UT

In article <lma.716092591@dayton.Stanford.EDU> lma@dayton.Stanford.EDU (Larry Augustin) writes:
>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?


Have you tried this to wake the shell up?

	kill( getppid(), SIGCHLD);

This is pretty bogus, and I assume that you have a good reason for not using
a "fork()" where the child dissociates (becomes a child of init) and the
parent returns to satisfy the wait(4).

This works on some machines, and not on others, and the values returned for
the exit status of the child from the wait4 are bound to be incorrect
(unless you link with -lprognosticate 8-) 8-)), and this isn't guaranteed
to not crash your shell.  But it's about the only way to make the shell
"forget" about a subprocess (by interrupting the mechanism it uses to do
it's "remembering").  The specific reason it may not work is dependant
on how the "wait for child death" code is written and the actuality
itself trapped in the shell.  Cruddy shells (shells which can miss a
child completing if the child exits when multiple background tasks
occur at around the same time) will probably let you get away with it.

The correct way is to use fork() as part of the procedure.  If you'll tell
us why you don't want to use fork(), perhaps someone in the group can
tell you why the reasoning is invalid, and suggest a workaround to the
problem you think you have with fork()?


					Terry Lambert
					terry_lambert@gateway.novell.com
					terry@icarus.weber.edu

---
Disclaimer:  Any opinions in this posting are my own and not those of
my present or previous employers.
Newsgroups: comp.unix.internals,comp.unix.wizards,comp.unix.programmer
From: synchem@sbcs.sunysb.edu (Synchem proj acct)
Subject: unix process related information - suggestion needed
Organization: State University of New York at Stony Brook
Date: Tue, 15 Sep 1992 05:35:35 GMT


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.

- Chyouhwa
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.internals
Subject: Re: How can a Unix process put itself in background?
Date: 11 Sep 1992 18:33:32 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

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.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.unix.internals
From: antony@ee.uts.edu.au (Antony Richards)
Subject: How to get a fine resolution clock
Organization: University of Technology, Sydney, Australia
Date: Thu, 10 Sep 1992 05:45:12 GMT

Hello,
I am developing some protocol test software for my PhD.  I need access to a high
resolution clock (to be accessed by C/C++ software) on the Sun Sparc.  Does
anybody know how to do this?

thanks in advance,
antony.
Newsgroups: comp.unix.internals,comp.unix.programmer,comp.unix.wizards
From: rsaripa@mars.cs.clemson.edu (Saripalli Ramakrishna)
Subject: Any books on Lightweight processes on Unix?.
Organization: Clemson University Computer Science Dept.
Distribution: na
Date: Mon, 7 Sep 1992 17:54:17 GMT

Hi,

	I would appreciate if anyone could tell me what would be the 
	best books to read/study on Lightweight processes on Unix.
	I am currently managing with the SunOS manuals from my library.
	Is there any textbook ?.



					Thanks a lot,
					Saripalli Ramakrishna

e-mail : rsaripa@cs.clemson.edu
Man is a beast and usually has no control over his passions.
From: hurtta@cs.Helsinki.FI (Kari E. Hurtta)
Newsgroups: comp.unix.internals
Subject: Re: How can a Unix process put itself in background?
Date: 9 Sep 92 18:28:11 GMT
Organization: Department of Computer Science, University of Helsinki, Finland

In article <lma.716056953@dayton.Stanford.EDU> lma@dayton.Stanford.EDU (Larry Augustin) wrote:
>                                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?

No, there isn't without help of shell. And there isn't such shell.
Returning control to the shell is hard part. Control returns to shell,
when process exits or change state from running to stopped (ie. when
wait4 -system call returns in shell).

- K E H
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.internals
Subject: Re: How can a Unix process put itself in background?
Date: 12 Sep 1992 02:49:08 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Sep11.222546.3878@tandem.com> norcott_bill@tandem.com  (Bill Norcott) writes:
>In article <18qopsINN12n@early-bird.think.com>, barmar@think.com (Barry Margolin) writes:
>|> 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.

A background process is one that runs in parallel with the one that
originally created it.  The child process has to fork() a grandchild, so
that the child can exit(), which will cause the parent's wait() to return
and allow it to continue processing.  Simply calling setsid() and setpgid()
won't cause the parent's wait() or waitpid() to return.

The only thing that setsid() and setpgid() do is dissociate the process
from the original process group.  And process groups only affect signal
handling.  For instance, if the child calls setpgid(), and then the phone
line is hung up, the child process won't receive a SIGHUP because it's no
longer in the controlling terminal's process group.  So, whether it's
appropriate to call setsid() or setpgid() depends on whether you want the
background process to be immune to signals from the terminal (depending on
what you're doing, you may actually want a background process to be killed
when you hang up -- consider a program like leave(1)).
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.unix.internals