HDTenEightyP/NetNews huggingface dataset:
From: alchemy@cs1.bradley.edu (Mike Swiston)
Subject: Re: printf() & fork() ......
Organization: salt of the earth in open wounds.
Date: 22 Nov 92 02:07:10 GMT

In <1992Nov19.133035.172@ccsun7.csie.nctu.edu.tw> mchuang@csie.nctu.edu.tw (Ming-Chuan Huang) writes:

% #include <stdio.h>

% program 1:

% void main()
% {
%     printf("Hello ");
%     if (fork() == 0)
%         printf("world\n");
% }

% result:
% Hello Hello world

Under turbo cshell, I get the output:
Hello world
Hello  Exit 1

leading me to guess that the problem is that
your output buffer isn't getting flushed the
way you might expect it to be.  You can fix
that like so:

#include <stdio.h>

void main()
{
    printf("Hello ");
    fflush(stdout);
    if (fork() == 0)
        printf("world\n");
}
From: southbay@garnet.berkeley.edu ()
Newsgroups: comp.unix.internals
Subject: UNIX Lecturers Wanted
Date: 21 Nov 1992 01:44:43 GMT
Organization: University of California, Berkeley
Distribution: ba
NNTP-Posting-Host: garnet.berkeley.edu

U.C. Berkeley Engineering Extension is looking for highly
qualified individuals to teach various courses related to UNIX,
UNIX Internals, and Communications.  We are interested in new,
novel course proposals or people who can lecture in these subject
areas:

BSD Socket Programming
UNIX Network Programming
UNIX Internals
Streams/TLI Network Programming
UNIX Kernel 
UNIX System V Release 4 Internals.

These courses will be taught in the Menlo Park area.
If you wish to be considered please send a detailed resume, course
description and course outline to:

Harvey Stern
U.C. Berkeley Engineering Extension 
Southbay Program
800 El Camino Real Ste. 150
Menlo Park, CA 94025
Tel: 415-323-8141
Fax: 415-323-1438
Newsgroups: comp.unix.internals
From: aorenste@cs.ulowell.edu (Aaron Orenstein)
Subject: Re: printf() & fork() ......
Organization: Interactive Media Group - University of Massachusetts at Lowell
Date: Sun, 22 Nov 1992 01:41:29 GMT

In article <1992Nov19.133035.172@ccsun7.csie.nctu.edu.tw>, mchuang@csie.nctu.edu.tw (Ming-Chuan Huang) writes:
-> Hello:
-> 
-> #include <stdio.h>
-> 
-> program 1:
-> 
-> void main()
-> {
->     printf("Hello ");
->     if (fork() == 0)
->         printf("world\n");
-> }
-> 
-> result:
-> Hello Hello world
-> 
-> program 2:
-> 
-> void main()
-> {
->     printf("Hello \n");
->     if (fork() == 0)
->         printf("world\n");
-> }
-> 
-> result:
-> Hello 
-> world
-> 
-> 
-> is there anybody who knows the difference between the two programs ?
-> 
->                                                       mchuang
->                                      mchuang@csie.nctu.edu.tw

Your problem is that you are using buffered I/O.
under unix, printf() does not actually output the information until
either a newline is printed, or the output is flushed.  (Output is automatically
flushed when you try to get input).  So what is happening is this:

You do a printf("Hello ") and it fills the buffer with "Hello ".  When you
fork, the child gets a copy of the buffer.  The parent exits, and flushes it's buffer which outputs "Hello " on the screen.  The child, adds "world" to it's
buffer and then, since you gave it a newline, it flushes the buffer.  So the
child prints out "Hello world"

In the second example, the newline at the end of the first printf() is flushing
the buffer so the buffer is empty when the child starts...

Your problem could be solved with the following code:
void main()
{
  printf("Hello ");
  fflush(stdout);
  if(fork()==0) printf("world\n");
}

result:
Hello world



	Anything else?

    Good luck
	- Aaron

-- 
--------------------
"The Code is free, It's the comments that cost a lot..."
Aaron Orenstein	(aorenste@cs.ulowell.edu, 129.63.1.11)
Newsgroups: comp.unix.internals
From: fitzgb@mml0.meche.rpi.edu (Brian Fitzgerald)
Subject: Re: open() from within a Device driver
Organization: Rensselaer Polytechnic Institute, Troy, NY
Date: Tue, 24 Nov 1992 05:49:08 GMT

Rajeev Menon writes:
>I have a device driver on SCO UNIX SV3.2 (openDesktop 1.0) that
>needs to open a regular file from within the driver, write stuff to it
>and close the file later on, basically the equivalent of the open(), 
>write(), close() system call. 

Gadzooks!  Why?

Brian
Xref: sparky comp.unix.internals:1959 comp.unix.programmer:5318
From: hausler@aldetec.oz.au (Graham Hausler)
Newsgroups: comp.unix.internals,comp.unix.programmer
Subject: device driver address translations
Date: 17 Nov 92 11:13:25 GMT
Organization: Aldetec Pty Ltd, Perth West Australia

I'm searching for a couple of particular details on address translations
within the context of a device driver....

Firstly, under UNIX System V/88 R32V3 in particular, and UNIX System V in
general, what kernel address space is automatically mapped to physical 
memory? Teixeira, in his device driver text, says the kernel always maps
the upper 2 Mbytes of kernel address space to identical physical addresses.
Is this true for 88k, ie 0xFFE00000 - 0xFFFFFFFF references in kernel space
will try to access these physical addresses? I can't find any V/88
documentation that confirms or denies this (and I am not at device
driver debugging stage yet...) although samples of code I've looked at
definitely assume that this is the case.

If so, that covers accessing device registers, but how do I access 
primary memory that has been removed from UNIX via  sysgen configuration? 
For example, memory from 0x01FE0000 - 0x02000000 I want to access via my 
device driver. I've searched the documentation for some routine/method that 
allows me somehow directly access physical memory, but to no avail. 
Do I have to do something special/bypass address translation tables 
(if so, what/how ??!?), or is there simple solution? (ie a copyin/copyout
that works between kernel space and physical space...)

Thanks for any assistance
Graham Hausler.





-- 
Internet:   hausler@aldetec.oz.au      --> GEMCO, Perth, Australia.
From: merblich@imola.EBay.Sun.COM (Mitchell Erblich user)
Newsgroups: comp.unix.internals
Subject: Re: Changing the owner of a process
Date: 19 Nov 1992 20:30:49 GMT
Organization: Sun Microsystems
Distribution: world
Reply-To: merblich@imola.EBay.Sun.COM
NNTP-Posting-Host: imola.ebay.sun.com

Hey group,

	The UIDs are stored in the cred structure if you have a current version of UNIX

Mitchell Erblich : merblich@EBay.Sun.COM
@Sun

Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
From: peter@ferranti.com (peter da silva)
Subject: Re: The Problem with UNIX
Organization: Xenix Support, FICC
Date: Fri, 20 Nov 1992 01:22:52 GMT

In article <1992Nov19.000136.3970@tamsun.tamu.edu> ski8032@tamsun.tamu.edu (The Man Behind The Curtain) writes:
> echo a > a
> echo b > b
> cat a b > b
> cat: input b is output
> cat a
> a
> cat b
> a

echo a > a 
echo b > b 
cat a b > b 
b: File exists.
cat a 
a
cat b 
b

So, what's your problem?

rm a b
-- 
Peter da Silva / 77487-5012 USA / +1 713 274 5180
true(<<VV$@\\$'&O 9$O%'$LT$&$"V6"$&$<4$?'&$ #I&&?$=$<<@)24 24 scale 3 21 moveto
{dup 36 eq{pop not}{dup 7 and 4 sub exch 56 and 8 div 4 sub 2 index{rlineto}{
rmoveto}ifelse}ifelse}forall stroke pop showpage % Har du kramat din varg idag?
Xref: sparky comp.unix.wizards:4735 comp.unix.shell:4742 comp.unix.misc:4205
From: ken@sugra.uucp (Kenneth Ng)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: Re: The Problem with UNIX
Date: 17 Nov 92 01:19:06 GMT
Organization: Private Computer, Totowa, NJ

In article <1992Nov14.145943.1288@global.hacktic.nl: peter@global.hacktic.nl (Peter Busser) writes:
:kanderso@reed.edu (Karl Anderson) writes:
:>Is there any reason why there can't be another stream for more
:>user-friendly messages?
:Yes! Feeping creaturism. I'm pro user friendly messages, but, IMHO, consistency
:and clarity are much more important than verboseness. Furthermore, it would
:require existing programs to be extended with the verbose message.
:A better approach would be, IMHO, to leave the messages what they are and make
:every program return a meaningful error number. A seperate program could
:figure out which verbose message belongs to that number.

I would like to see two things: one, have the program that generates the
error message put *ITS* *NAME* as the first part of the error message.
Second, print something meaningful like perror().  I do not know how many
times I've seen "can not open file" in a script that calls other scripts
that calls a few dozen routines.  So then I have to find out WHAT program
could not open WHAT file.

-- 
Kenneth Ng
Please reply to ken@eies2.njit.edu for now.
Apple and AT&T lawsuits: Just say NO!
Newsgroups: comp.unix.wizards
From: rudi@igc.ethz.ch (Rudi van Drunen)
Subject: vacation program hackin'
Followup-To: comp.unix.wizards
Reply-To: rudi@igc.ethz.ch
Organization: Computational Chemistry, ETH, Zuerich
Date: Mon, 23 Nov 1992 23:26:21 GMT

Hi wizards!

I got some problem (well.. problem...) with the vacation program.
I have composed a nice msg. to send to all (but some) people when I am
away... No probem. The problem comes in with the -but some-.

The fact is that I would like anyone, but some people (specified in a
file) to receive te message. The people whose addresses are specified in
that file will not get any vacation msg. 
That is to let those selected ones not get a msg. back while i am 
away, 'cause I will read my mailbox so now and then, and mail with them.
It is very annoying to get a vacation msg. everytime you send something...

Ok, there must be at least one of you who wrote a script(or so) for this.
Let him or her speak, and mail it a.s.a.p ...

Thanks so much !

Please use Email, as I don't have that much of time to walk trough the news
every day Thanks !!

rudi (rudi@igc.ethz.ch)

BTW if this is not possible it might as well be handy to have something that
every sender gets the vacation msg. only once when sending a number of
From: sivap-s@acsu.buffalo.edu (Suresh .S)
Newsgroups: comp.unix.wizards
Subject: Re: system call write
Date: 18 Nov 92 19:34:01 GMT
Organization: UB
X-Newsreader: TIN [version 1.1 PL6]

P S Narayan (pnarayan@cs.tamu.edu) wrote:
: When I do a write (fd, buf, bytes), assuming that the file descriptor refers
: to an open block device say disk, is the kernel going to copy buf from user
: space to system buffer or is it going to flush it immediately onto disk ?
: System V literature says that it is copied onto buffer and then by LRU 
: algorithm, it gets flushed when another process tries to access this buffer.
: In that case how can the user process without closing the files, ensure that
: his write system call flushes info onto disk ? Is there a way to do it ?
: 
: My question is how can I get synchronous write ?

When you are opening the file, you can  set  the  O_SYNC option in the
flags, which will give you synchronous writes. Another way could be to
set the descriptor flags using fcntl()[cmd is F_SETFL].

I am not sure if that  is available in  others OS, it  is available in
SunOS4.1.1.

-- 
Suresh Sivaprakasam                    
Department of Computer Science,    SUNY Buffalo,    Amherst,   NY - 14260-0001
Internet :sivap-s@cs.Buffalo.EDU               Bitnet : sivap-s@SUNYBCS.BITNET
Xref: sparky comp.unix.wizards:4716 comp.unix.shell:4729 comp.unix.misc:4188
From: barnett@grymoire.crd.ge.com (Bruce Barnett)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: Re: The Problem with UNIX
Date: 16 Nov 92 15:08:53 GMT
	<1992Nov12.193707.27532@chpc.utexas.edu>
	<BARNETT.92Nov13093417@grymoire.crd.ge.com>
	<1992Nov13.224718.15935@chpc.utexas.edu>
Reply-To: barnett@crdgw1.ge.com
Organization: GE Corp. R & D, Schenectady, NY

In article <1992Nov13.224718.15935@chpc.utexas.edu> michael@chpc.utexas.edu (Michael Lemke) writes:
>   No, I don't.  I am complaining that the options are a) parsed
>   inconsistently (`bla -lx a' might be valid and `bla -l x a' not but
>   `foo -l x a ' is ok and `foo -lx a' is not) and b) that -l means long
>   for ls -l but library for f77 -l.  I want ls -long and f77 -library and
>   be able to abbreviate both -long and -library because `long' and
>   `library' is what I mean and not -l.

>   >It sounds like most of your problem is due to the large number of UNIX
>   >utilities. How many does DOS have? 

>   No idea.  I don't know DOS.

Well, what are you comparing Unix to? As I stated, I currently have
2033 commands available. When you consider the large number of
commands, along with the ease of creating new ones, it is no wonder
they are inconsistent. As Boyd says, VMS also has inconsistencies
(I personally don't know enought to comment). ANY system that has the
large number of commands is bought to have inconsistancies, unless the
creation of these programs are under tight control, and we can throw
out backwards compatability. Even so, people will want to deviate from
the strict guidelines because it makes the interface friendlier.

Consider your "-l" example. Unix is considerate of the person typing
all day.  I don't want to type dozens of extra characters for commands
I execute all of the time.

How can you allow variable length options and still allow terseness
when typing?

I don't want to type
	list -long -time  -reverse -all
or 
	list -lo -ti  -r -a
or 
	list -lo/ti/r/a
or even 
	list -l/t/r/a
when I can type
	ls -ltra


Same thing with the -l option to cc/ld.

	-lm
is equivalent to the more logical

	 -library=/usr/lib/libm.a
or even
	 -library=libm.a
or	 -l=libm.a

Unix is inconsistant and power user friendly. 

You must also consider the possibility of adding new options (which is
very easy to do.) Consider a command that allowed
	-long
	-lon
	-lo
and
	-l

as valid. Suppose you add a "-low" option? Old scripts who uses "-l"
or "-lo" could break. This is a fatal flaw. You could add new options
that never conflict with previous options, but then this also has
problems because you are forces to select options whoes words that
might not make sense.

IMHO adding consistency to Unix would place an extra burden for the person
typing on the keyboard all day long.
--
Bruce Barnett <barnett@crd.ge.com> uunet!crdgw1!barnett
From: so@brownie.cs.wisc.edu (Bryan S. So)
Newsgroups: comp.unix.wizards
Subject: Re: The Problem with UNIX
Date: 18 Nov 92 02:04:02 GMT
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.

In response to my suggestion that the shell should help the user
buffer "b" when it sees the command "cat a b > b",
mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
 
>There are also problems with buffering the input.  What if the "b" is
>a FIFO or a device, not a regular file?  In that case, "cat b > b" is
>perfectly valid and not at all abnormal.  What if "b" is a Unix-domain
>socket, and the program at the other end writes something and then
>waits for a response before closing the file?  Your program will never
>run, because Unix will be sitting there waiting to read the "rest" of
>the input file before giving the program control.

 If "b" is a FIFO, it may make "cat b > b" syntactically or even
 semantically valid.  But how would it make that psychologically
 valid?

 I suppose "cat a > a" or some variance of it is documented 
 somewhere as "pitfalls" and users warned.  So, whoever thought
 up a FIFO "b", such that the proper usage is "cat b > b", is 
 just absurd.  Can you give a practical application for such use?


Bryan
Xref: sparky comp.unix.wizards:4809 comp.unix.shell:4803
From: mouse@thunder.mcrcim.mcgill.edu (der Mouse)
Newsgroups: comp.unix.wizards,comp.unix.shell
Subject: Re: The Problem with UNIX
Date: 20 Nov 92 09:26:23 GMT
Organization: McGill Research Centre for Intelligent Machines

In article <id.2X1V.U99@ferranti.com>, peter@ferranti.com (peter da silva) writes:
> In article <1992Nov13.091914.6799@thunder.mcrcim.mcgill.edu> mouse@thunder.mcrcim.mcgill.edu (der Mouse) writes:

>> Yes, it might.  So what?  Is "acceptance in the general
>> microcomputer market place" something we wish for UNIX?
> If we want to keep being able to buy nice cheap UNIX systems with
> decent performance for the long-term, yes.

Keep?  You mean they're available now?  The only decent systems I know
of are ones you have to put together from pieces yourself anyway....

> I would say that a friendly shell that does all the command parsing
> (like DCL does) would be quite a nice touch.

You need the equivalent of .cld files to do this.  Since *nobody*
provides them, your user has to write them for every new program
obtained - and that kinda defeats the purpose of having them to begin
with.

(I *think* .cld is the right extension; it's been a long time.)

					der Mouse

			    mouse@larry.mcrcim.mcgill.edu
From: mbarkah@slate.mines.colorado.edu (Ade Barkah)
Newsgroups: comp.unix.wizards
Subject: Re: Changing the owner of a process
Date: 24 Nov 92 02:47:50 GMT
Organization: Colorado School of Mines

steve@nuchat.sccsi.com (Steve Nuchia) writes:
: In article <1992Nov19.220759.1846@exlog.com> mcdowell@exlogcorp.exlog.com (Steve McDowell) writes:
: >Why is it going to panic over an inconsistent process count? That's simply
: >not good operating system design. When it hits an inconsistancy (as it
: >eventually will in some remote region of the world) it should simply alert
: >the operator and re-count things.
: 
: Three points:
: 
: 1: If you have enough free time on your hands, feel free to write
: the necessary recounting code for all the places where the kernel
: keeps counts.  I'd prefer to have the CSRG's remaining time spent

I agree with you there. However, I also agree with the previous 
poster in that in the _commercial_ arena products should tend
to be more rugged and recover if it could.

: 2: I may be old-fashioned, but I prefer to have a system panic
: when it detects a "can't happen" bug.  That means something
: has gone wrong.  Under those circumstances, why would you want
: to trust a piece of recovery code that hasn't been tested in
: living memory?

Because a panic() and shutdown may be inappropriate. Take some
real time applications, for example, like piloting a plane. Boy
I sure hope the computer wouldn't just panic on me if it can
recover.

: 3: What is the opertator going to do about it, anyway?  If one of
: these counts gets out of whack, somebody who can fix the code needs
: to know about it, fast.  Something caused the fault, and there is
: literally no telling what else may be broken until the cause is found.

That's for the operator to decide. He/she may immediately shutdown
the system. Or continue at her own peril. Researchers can't always
know what the product is going to be used for. While it is probably
true that the large majority of people wouldn't be bothered with
recoverable-panics, to some it would be disastrous.

: Of course, if one is building a system for binary-only distribution
: or attempting to provide for non-stop operation, other considerations
: apply.  BSD Unix does not have those design goals.

No questions there. I think most of us do know that we're talking
about two kinds of worlds here, lab-research vs. commercial, and 
the needs are sometimes mutually exclusive.

And lets leave it at that. In the lab time is much better spent
doing something else. The commercial people have their own respon-
sibility of providing what their clients want or need.

: Steve Nuchia      South Coast Computing Services, Inc.      (713) 661-3301

-Ade Barkah-
-- 
Internet  : mbarkah@slate.mines.colorado.edu    (NeXT Mailable)
CompuServe: 74160,3404
From: Steve_Kilbane@gec-epl.co.uk
Newsgroups: comp.unix.wizards
Subject: Re: The Problem with UNIX
Date: 23 Nov 92 10:28:31 GMT

Just thought I'd make my comments to the few who haven't got this thread in
their kill files:-).

The answers seem mainly to be in one of two camps - the "UNIX should be easy to
use" camp, and the "lay off my OS" camp. The first might be nearer to "UNIX
should be SAFE to use", but that's besides the point. There *is* work going on
to try to improve the user interface of UNIX, though it's not everybody's
idea of what's required - two examples that spring to mind are Sun and Rob Pike.

Sun have flooded my disks with a huge amount of graphical tools which are
supposed to be easy to use, and will supposedly improve my productivity. Maybe
they would - I haven't tried them (I'm a shell person, myself).

Rob (from the papers I've read) believes that bitmaps and mice are the way
forward, and is trying hard to look at them without prejudice: best of luck.

Enough stage-setting; time for some points (or opinions):

(a) new users want something easy, simple and safe; experienced users like
their fast, efficient command lines. There's no middle ground.

(b) Just because the interface involves a mouse (or *whatever*), it doesn't
mean that it doesn't have all speed, power or flexibility of a *pure*
command line.

I think (a) is probably the most urgent area for research. We need something
that allows new users to come into UNIX, and start working with it without
obscure error messages or cryptic commands, and from there, build up to the
full power and simplicity of UNIX gracefully. Note that this is a general
problem with any computer system.

(b) is also hard: I'm still waiting to see a window system that supports the
concept of a pipe, and personally, I don't have any answers.

As a minor, final point on the subject of error messages, somebody mentioned
that it would be nice for all the commands to be consistent in their handling.
I agree. Since the Plan 9 group have had to do a major overhaul/rewrite of
many of their utilities to support UTF, to unify the regular expressions, etc,
it would be nice to think that they took the opportunity to unify the error
handling, too.

Enough waffle: back to the mv/cat problem.
$ cat a b > a
why?
$

Steve
-----------------------------------------------------------------------------
Steve Kilbane, MDD, CEGELEC PROJECTS Ltd, Boughton Road, Rugby, CV21 1BU,
England. Tel: +44 788 563493.            email:Steve_Kilbane@gec-epl.co.uk
Disclaimer: I don't speak for my employers. I don't speak for me. I mutter.
        "Another good night to sleep in a euphemistic tree"
Newsgroups: comp.unix.wizards,comp.unix.shell
From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
Subject: Re: The Problem with UNIX
Date: Sun, 15 Nov 1992 20:26:23 GMT
Organization: The Programmer's Pit Stop, Ann Arbor MI

In article <1992Nov14.153857.1666@global.hacktic.nl> peter@global.hacktic.nl (Peter Busser) writes:
>I did just that with bash and it didn't complain. But yet, echo is often a
>built-in command. It complained about 'cat a b >b' but didn't complain about
>'cat a b|cat>b' so it's not perfect.

You fail to see the point.  It's useless for cat to complain, because
once cat gets to run "b" has already been clobbered by the shell.  Try

$ echo foo >foo
$ echo bar >bar
$ cat foo
foo
$ cat bar
bar
$ cat foo bar >bar
cat: input/output files 'bar' identical
$ cat bar
foo
$ 

-- 
Marc Unangst, N8VRH         | "There are two ways to solve this problem:
mju@mudos.ann-arbor.mi.us   | the hard way, and the easy way.  Let's start
                            | with the hard way."
                            |   - W. Scheider, from a Physics lecture
Xref: sparky comp.unix.wizards:4793 comp.unix.shell:4783 comp.unix.misc:4250
From: boyer@sumax.seattleu.edu (Chuck Boyer)
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc
Subject: FAQ location please, info on setting up .profile/bash...
Date: 19 Nov 92 06:24:33 GMT
Organization: Seattle University

I just need to be directed to an information source for shell
setups please. All responses appreciated.
In particular I would like my 'pwd/cwd' to be reflected in my
prompt in Linux at home.
Thanks.
chuck
Newsgroups: comp.unix.wizards,comp.unix.shell,comp.unix.misc