HDTenEightyP/NetNews huggingface dataset:
From: terry@cs.weber.edu (A Wizard of Earth C)
Subject: Re: micro or terminal to Unix
Organization: Weber State University  (Ogden, UT)
Distribution: usa
Date: Fri, 16 Oct 92 03:58:22 GMT

In article <1992Oct15.203140.4304@bnr.ca> johnh@nnshh127.uucp (John Hawkins) writes:
>I am interested in finding an 'optimal' way to connect some sort
>of pc - DOS - MAC - to a host hp 800 series over a WAN. 
>Hmmm well optimal means (in this particular case) the least # 
>of packets sent over the WAN, while still having the ability
>to function sometimes on a character by character basis. say
>running a script remotely that prompts for a char.
>
>I have tried using telnet packages ->ncsa etc. however it seems
>that the pc sends every single key press in a packet of ~80 some bytes.
>Note:packet size and info from using etherpeek software....
>
>Wish I knew more 'bout these protocols... we are using tcp/ip
>over the ethernet WAN.

Use a modern telnet client and a telnetd that will negotiate "line mode"...
this way you will get a packet per line rather than a packet per character
(unless the read is for a single character, you have "smart" pty's, and
you hack telnetd to take mode control messages from the pty).

"Single character I/O" is my biggest gripe with "MUSH" and "MUCK" and "M"...
software, since the authors either don't know how to negotiate options or
simply refuse to code it up.  Packets of one character piss me off.

Check out the telnet RFC's for more info on "line mode".


					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
-------------------------------------------------------------------------------
From: libes@cme.nist.gov (Don Libes)
Newsgroups: comp.unix.wizards
Subject: Re: Keyboard logging
Date: 8 Oct 92 21:26:52 GMT
Organization: National Institute of Standards and Technology

In article <80488@ut-emx.uucp> dougmc@ccwf.cc.utexas.edu (Doug McLaren) writes:
}In article <1617@integow.uucp> paul@integow.uucp (Paul van Boxmeer) writes:
}}i need a program to log all keyboard input and the times on which these
}}keys were entered.
}}
}}The log-file will later be used to examine a users response time at
}}specific menu's, data entry screens, error-messages, etc. wich is used
}}for research on user-interfaces.
}}
}}My question is:
}}
}}	how do i log terminal input (including times) without a
}}	user and any program knowing he/she/it is being logged.

}Sounds like the perfect password stealer ...
}It'd be easier to do on a PC w/ an ethernet or similar connection.  Just
}make a TSR that intercepts the keyboard interrupts, stores the character
}pressed on disk, and passes the keystroke on ...
}Passwords would be fairly easy to find in this datafile ...

You can do it easily from UNIX as well.  See the short script on page 112
in Computing Systems, Vol. 4, No. 2.  Unlike the suggestion (above) to
save every keystroke, this Expect script saves just the login names and
passwords.

Don
Newsgroups: comp.unix.wizards
From: rstevens@noao.edu (W. Richard Stevens)
Subject: Re: TTL value in ip struct
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Distribution: usa
Date: Fri, 9 Oct 1992 12:00:42 GMT

> 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?

Newer BSD systems (from 4.3BSD Reno and later, I think) have a new
socket option, level=IPPROTO_IP, option=IP_TTL, to set or fetch
the TTL that's used on that socket.  But, looking at the "recent"
traceroute sources, it doesn't use this feature yet.

	Rich Stevens  (rstevens@noao.edu)
From: tholome@bangalore.esf.de (Eric Tholome)
Newsgroups: comp.unix.wizards
Subject: crontab problem
Keywords: crontab sh csh argument
Date: 13 Oct 92 12:39:57 GMT
Reply-To: tholome@bangalore.esf.de (Eric Tholome)
Organization: ESF Headquarters, Berlin, FRG

I've already asked this question in comp.unix.questions and didn't get an answer. So maybe it is indeed something for you, wizards!

I have the following problem:

I have a little script (that begins with #! /bin/csh) which uses two arguments.
When I run it by hand (myscript arg1 arg2), it runs perfectly.
When it is in a crontab (30 0 * * * myscript arg1 arg2), it seems that $1 $2
are in fact empty, as if the arguments hadn't been passed to the script.

Now, I kinda remember that using csh for crontab stinks. Is this the reason for
my problem? Is the shell (sh) launched by cron not able to pass the parameters
to my script?

For all that it matters, I'm on a Sun4Sparc running SunOS 4.1.

Can anybody enlighten me?

Thanks a lot,

                                                Eric


--
_____________________________________________________________________________
Eric Tholome       ESF Headquarters             internet: tholome@esf.de
                   Hohenzollerndamm 152         UUCP:     tholome@esf.uucp
                   D-1000 Berlin 33             Ph.:      +49 30 82 09 03 25
                               Germany          Fax:      +49 30 82 09 03 19
From: sequent!verdix.COM!MAILER-DAEMON@uunet.uu.net
Newsgroups: comp.unix.wizards
Subject: failed mail
Date: 15 Oct 92 19:16:12 GMT

=======     command failed      =======

 COMMAND: /usr/bin/uux -r - encore!rmail '(schandle)'

======= standard error follows  =======
bad system name: encore
uux failed. code 68
======= text of message follows =======
From sequent!uunet!sem.brl.mil!unix-wiz
Received: by sequent.sequent.com (5.65/1.34)
	id AA23340; Wed, 14 Oct 92 23:19:10 -0700
Received: by sequent via UUCP from uunet; Thu Oct 15 00:40:29 1992
Received: from SEM.BRL.MIL by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA08029; Thu, 15 Oct 92 00:40:29 -0400
Received: by SEM.BRL.MIL id ab24540; 14 Oct 92 16:42 EDT
Received: from SEM.BRL.MIL by SEM.BRL.MIL id aa18794; 14 Oct 92 15:30 EDT
Received: from scws0.ctstateu.edu by SEM.BRL.MIL id aa18545; 14 Oct 92 15:14 EDT
Received: by scws0.ctstateu.edu (5.57/Ultrix3.0-C)
	id AA00436; Wed, 14 Oct 92 15:15:25 -0400
Date: Wed, 14 Oct 92 15:15:25 -0400
From: Hiu Cheung <sequent!uunet!scws0.ctstateu.edu!orphy>
Message-Id: <9210141915.AA00436@scws0.ctstateu.edu>
To: unix-wizard@sem.brl.mil
Subject: help

help on how to join your guys???
From: smee@bristol.ac.uk (Paul Smee)
Newsgroups: comp.unix.wizards
Subject: Disk leakage?
Date: 8 Oct 92 09:53:28 GMT
Reply-To: P.Smee@bristol.ac.uk (Paul Smee)
Organization: University of Bristol

We've got a mystery, in that large (in our context) chunks of disk
occasionally mysteriously vanish, to reappear if you reboot.  I believe
I understand the mechanism, question is a bit deeper than that.

My current theory is that the space is 'vanishing' owing to files which
have been removed from the directory hierarchy, but which are still
being held in existence because someone still has them open, so keeping
the inode's refcount from zeroing.  Sounds reasonable, Unix does that.

Question is, anyone have any magic which would aid in determining which
process(es) still hold the files, or (less useful, but also less
likely) even which files they were while they still were attached to
directories, from which I could probably make reasonable guesses
about who was using them?  

The space never comes back before reboot, so the 'holder' is almost
certainly either one of the daemons, or a 'zombie' (though I've found
no correlation between number of Zs and disk loss), or (worst case) one
of the standard 'listeners' -- init, getty, ...  

The system is small, but pivotal to our service, so taking it out (or
even selected processes out) for extended periods is not an option --
so, something which works on the fly would be best.  We don't have
another similar box which we could nab for extended test work.  And,
just to put the icing on the cake, we couldn't afford a source license
for it, so I'm flying semi-blind.

System is (if it matters, probably does) a Sun Sparc 4/330 on SunOS
4.0.3.  I'm (probably vainly) hoping someone has already seen and
cracked this.  RTFM is, as always, an acceptable answer, but if that IS
the answer, some pointers into the FM would be really appreciated.
(I've already gone thru the obvious man -k on inode, dir, and file, and
read, several times each, man dcheck, icheck, and fsck.)  Alternative
theories about possible cause would also be appreciated.  Thanks...

-- 
Paul Smee, Computing Service, University of Bristol, Bristol BS8 1UD, UK
 P.Smee@bristol.ac.uk - ..!uunet!uknet!bsmail!p.smee - Tel +44 272 303132
From: hm@opus40.ix.de (Harald Milz)
Newsgroups: comp.unix.wizards
Subject: Re: unsubscribe me
Date: 12 Oct 92 08:40:05 GMT
Organization: iX-Redaktion


Do-it-yourself.
-- 

|Dipl.-Ing. Harald Milz                   |    EMail:		hm@ix.de |
|iX - Multiuser Multitasking Magazin      |    FAX:    +49 511 547 47 33 |
|D-3000 Hannover 61, Helstorfer Str. 7    |    Tel.:   +49 511 547 47 66 |
From: rol@grasp1.univ-lyon1.fr (Paul Rolland)
Newsgroups: comp.unix.wizards
Subject: Re: how to get a signal when a non-child process dies
Date: 16 Oct 92 13:04:31 GMT
Followup-To: comp.unix.wizards
Organization: Univ-Lyon1

In article <1992Oct14.025524.13523@ckctpa.UUCP>, crash@ckctpa.UUCP (Frank
"Crash" Edwards) wrote:
> 
> luochen@screen.Princeton.EDU (Luoqi Chen) writes:
> >From article <Bw0Grz.28C@wldelft.nl>, by kool@ws01cso.wldelft.nl (Marc H. Kool):
> >> What I want is to be able to leave the `master' process, (re)start it
> >> at a later time and to get a signal when a ``child process'' 
> >> (which I created with the previous master process) dies.
> 

I know this is not a really clean way to do that, but why not using a
block of shared memory. Each of your process will have access to it, and
could
register when ending, and the master could read in it, of an intermediate
could be checking this block every minute and send a signal to the master.
The only problem is now for each of your process to access this shared
memory.


Paul Rolland, rol@grasp1.univ-lyon1.fr

-*-*-*-*-*-*-*-*-*-*- DISCLAIMER -*-*-*-*-*-*-*-*-*-

All the opinions I express in this posting are mine, but I'm
ready to share them with anybody interested :-)
Newsgroups: comp.unix.wizards
From: rjf@dptg.att.com (51351[efw]-Robert Feddeler(MT4799)T343)
Subject: Re: fork() and forget..How?
Keywords: fork() wait() getpid() getppid()
Organization: AT&T/NCR, Lincroft, NJ, USA
Distribution: usa
Date: Mon, 12 Oct 1992 21:46:02 GMT

In article <1992Oct12.194855.28936@crd.ge.com> davidsen@crd.ge.com (bill davidsen) writes:
>In article <1992Oct07.194020.14527@ctms.gwinnett.com>, kirk@ctms.gwinnett.com (R. Kirk Waterhouse) writes:
>
>| I followed the examples in the AT&T Programmers Guide and other books and they 
>| won't quite work.
>| 
>|    if (fork()) {
>|       if(child) {
>|          ...
>|          process_data_and_die();
>|          exit(1);
>|       }
>|       else
>|       if (parent) {
>|          wait()
>|       }
>|    }
>| 
>| If I do it basicly like this I only get one instantiation of my child process
>| because the parent sits there at the wait, losing data from it's input because
>| this child takes approx. 1-2 minutes to complete.
>
>  Well, assuming that you don't need more "channels" than the system
>will let you have due to process number limitations, the way you do it
>is to use signal() to catch the SIGCHILD, then do a wait after the child
>is dead. It doesn't keep you from hitting the wall if you need more
>children that the system will let you have, though.


If you don't care about the exit status of the sub-processes, the easiest
way to forget about running children is to set SIGCLD to SIG_IGN.  No
zombies are created; no wait(2) is required.

If you do this, note that system(3) calls wait(2) and mucks with SIGCLD.


bob.				| Heap big trouble in the land of plenty!

If it were more than just my opinion, it would cost a bit more.
Newsgroups: comp.unix.wizards
From: kherron@ms.uky.edu (Kenneth Herron)
Subject: Re: fork() and not forget
Distribution: na
Date: Thu, 15 Oct 1992 18:16:36 GMT
Organization: University Of Kentucky, Dept. of Math Sciences

a2mp@loki.cc.pdx.edu (Michael Perrone) writes:

>> waiter()
>> {
>> 	union wait st;
>> 	while (wait3(&st, WNOHANG, NULL) > 0);
>> }
>> 
>> in your process that fork()s, stick this in:
>> 
>> signal(SIGCHLD, waiter);

>Well, this is nitpicking... But chances are the original poster doesn't have
>the wait3 call available to him.
> .....
> int *status_ptr; /* dead child's status */
> ....
>      while (waitpid(-1, status_ptr, WNOHANG) > 0)
>.....

[Aside:  I'm typing this on a system that has wait3 but not waitpid]

> You can use plain old wait() (without the while) in your signal handler, 
> but the advantage of using a non blocking call is clear - if another child
> dies while your in the signal handler, you'll catch it; otherwise you'll
> miss the signal because you were in the handler.

There's a more serious problem with wait() which hasn't been addressed 
so far.

If you start paying attention to SIGCHLD, you'll find that the parent
receives a SIGCHLD if the child process is stopped by any of the
process stopping signals.  So any SIGCHLD handler on a system with
job control must be prepared to deal with a merely stopped, rather
than terminated, child process.

The problem is that wait() explicitly waits for terminated processes,
and won't return due to a stopped one.  Both waitpid() and wait3()
will return due to a stopped process.
-- 
Kenneth Herron                                   kherron@ms.uky.edu
University of Kentucky                              +1 606 257 2975
Department of Mathematics      I just thought of a neat disproof of
     Fermat's last theorem, but .signatures can only be four lines.
Newsgroups: comp.unix.wizards
From: bill@toby.transportation.state.mn.us (Hari Seldon psycohistorian)
Newsgroups: comp.unix.wizards
Subject: whats the scoop??
Date: 12 Oct 92 14:38:53 GMT


ok i just got into work and i find that this, um, person has been remailing all
of the posts over the weekend. so what gives?
this is pretty darn annoying.

Date: 12 Oct 1992 01:43:31 +0000
From: "OUT, OUT - YOU'LL NOT FEEL THE FALL-OUT..."
<OLIVOTTO%ITNCISCA.bitnet@icineca.cineca.it>
Subject: (From: IN%"Unix-Wizards@BRL.MIL") (From: IN%"UNIX-WIZARDS@BRL.MIL")
 UNIX-WIZARDS Digest  V16#035
To: Unix-Wizards@BRL.MIL
Message-Id: <01GPUE1MZKJM9PM1KC@itnvax.cineca.it>
X-Envelope-To: Unix-Wizards@BRL.MIL
X-Vms-To: IN%"Unix-Wizards@BRL.MIL"
Mime-Version: 1.0
Content-Transfer-Encoding: 7BIT


bill pociengel
Xref: sparky comp.unix.wizards:4220 comp.unix.programmer:4903 comp.lang.c:14653 comp.unix.sysv386:15321
From: oleg@csufres.CSUFresno.EDU (Oleg Kibirev)
Subject: Re: fork() and forget..How?
Organization: California State University, Fresno
Keywords: fork() wait() getpid() getppid()
Date: Fri, 9 Oct 1992 22:53:16 GMT
X-Posted-From: csufres.cs.csufresno.edu
NNTP-Posting-Host: sol.ctr.columbia.edu

In article <569@alden.UUCP> sgr@alden.UUCP (Stan Ryckman) writes:
>In article <1992Oct07.194020.14527@ctms.gwinnett.com> kirk@ctms.gwinnett.com (R. Kirk Waterhouse) writes:
>A couple of responders suggested catching SIGCHLD.  Since this doesn't
>really do what was wanted (fork() and forget), I'll point out that there
>are indeed a couple of ways to do that (and without that FIFO mess) that
>I have found to work.
>
>What is happening is that UNIX expects that child processes, when they
>die, to be wait()ed for by the parent.  Until then, they are
>zombie/defunct.  UNIX needs to keep them until the parent gets around
>to wait()ing (since it doesn't know _your_ parent process does not want to
>eventually wait()), and they consume slots in the process table.  If,
>however, the parent dies, they will be inherited by the init process (pid 1),
>will be waited for, and thus dumped from the table.  The trick is,
>then, for you to create processes with no parent.
>
>The easiest method, which has drawbacks, is to do what you were trying
>to do but reverse the role of parent and child process.  In other words,
>have the _parent_ go do the "Channel x" stuff and the _child_ take
>over the "My Process" which the parent had been doing.  Drawbacks?
>One example would be trying to kill the "My Process."  Doing a "ps"
>and then a "kill -TERM {pid}" where {pid} is what you got from ps
>might kill instead a process now doing "Channel x" if a fork() occurred
>in the meantime, for example.  This method may also leave a few defunct
>processes around until the oldest of the bunch gets done.  Too messy.
>
>Instead, I recommend the following, which I have used with much success:
>     PARENT: fork() then wait() for death of CHILD, then go back to business
>     CHILD:  fork() then exit() immediately
>     GRANDCHILD:  run the program you really want to run.
>Now the grandchild has no parent, and init will clean it up when
>it (the grandchild) finishes.  Signal catching is not required, and "ps"
>will show you what you expect for other purposes (except PPID will be 1
>for the grandchild).  It costs an extra fork(), but leaves things "cleaner."
>
>Good luck.
>
>Stan.
>--
>X-Obligatory-.sig
>    Stan Ryckman   sgr@alden.UUCP
What happens if a child runs setsid()? I haven't tried it, so no flames please,
but ps -jx does show that secondary shell in script is orphane. 

Oleg
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.wizards
Subject: Re: Disk leakage?
Date: 8 Oct 1992 17:30:46 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: telecaster.think.com

In article <1992Oct8.095328.4108@bristol.ac.uk> P.Smee@bristol.ac.uk (Paul Smee) writes:
>The space never comes back before reboot, so the 'holder' is almost
>certainly either one of the daemons, or a 'zombie' (though I've found
>no correlation between number of Zs and disk loss), or (worst case) one
>of the standard 'listeners' -- init, getty, ...  

I don't think a zombie process can have open files.  The only state that a
zombie process has is it process table entry, which holds the information
that the parent may extract using getrusage(2).

I've never heard of any of the standard daemons or system processes doing
stuff like this, either.

You could try killing and restarting processes one by one, to see when the
disk space becomes available.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
From: orphy@scws0.ctstateu.edu (Hiu Cheung)
Newsgroups: comp.unix.wizards
Subject: help
Date: 14 Oct 92 19:33:23 GMT

help on how to join your guys???
Newsgroups: comp.unix.wizards
From: jtk@netcom.com (Jane Valencia)
Subject: Re: Disk leakage?
Organization: Netcom - Online Communication Services  (408 241-9760 guest) 
Date: Sun, 11 Oct 1992 15:36:57 GMT

brnstnd@nyu.edu (D. J. Bernstein) writes:

>> I don't think a zombie process can have open files.
>Zombie processes can have open files and quite a bit more state. On a
>variety of BSD systems you can see this using pff from my kstuff
>package.

I think you need to start listing particular operating systems.  On
the (BSD-based) operating systems I've worked on, the exiting process
closes all its files before becoming a zombie.  I'd be *very curious*
to know when the files actually do get closed on a system in which
zombies can still have open files.  This would be particularly
interesting with respect to slow closes (drains on, say, printers),
as it isn't clear to me what process context is going to hang around
while the output drains.

					Andy Valencia
From: olson@anchor.esd.sgi.com (Dave Olson)
Newsgroups: comp.unix.wizards
Subject: Re: init output to console - why not?
Date: 7 Oct 92 05:28:00 GMT
Organization: Silicon Graphics, Inc.  Mountain View, CA

In <1992Oct6.150439.419@decuac.dec.com> mjr@decuac.dec.com (Marcus J. "Buddy can you spare a clue?" Ranum) writes:
| 	I was just wondering the other day if there really actually *is*
| a good reason why init doesn't attach its output and error to /dev/console
| during autoboots. All this crud of redirecting everything in /etc/{rc|rc.local}
| to /dev/console is tedious and irritating. So I tried it. It works, of course.
| 
| 	Am I missing something - is there any reason NOT to do this?
| 
| mjr.

The original reason was to make sure that init never had a controlling
terminal, partly to avoid keyboard signals (when there wasn't any
reliable (non-resetting signal handlers) signal system call).  Now
that there is, init could probably be re-written to be simpler,
and also simplify all the startup scripts.
--
Let no one tell me that silence gives consent,  |   Dave Olson
because whoever is silent dissents.             |   Silicon Graphics, Inc.
    Maria Isabel Barreno                        |   olson@sgi.com
From: runewi@alkymi.unit.no (Rune Winsevik)
Newsgroups: comp.unix.wizards
Subject: *** I NEED HELP WITH YACC !!! ***
Keywords: yacc lex
Date: 8 Oct 92 18:49:53 GMT
Organization: Norwegian Institute of Technology

Hi.

Is there any yacc-gurus out there?
Could anybody please help me out?
I just can't get yacc to accept this yacc descripition. I KNOW the problem
is somewhere in the "ADigP1_4" part (or isn't it....:-)....

A helping hand would be greatly appreciated!!!!!!!

-Rune









/************************************************************************/
/*									*/
/*			YACC part of the evaluator 			*/
/*									*/
/************************************************************************/

%token		SBS_BUSY SBS_NO SBS_SEIZED PRIV_CALL
%token		CONV M_KEY END_CONV SBS_FREE CALL_BUSY
%token		C_KEY DIGIT INTEGER SBSNUM NL ENDS


%%

Sessions	: Sessions Session
		|
		;

Session		: ABSession			/* A Calls B    	*/
		| ENDS				/* END-token detected. Stop	*/
		{
		  printf("End detected!\n");
		  exit(0);
		}
		;

/*----------------------------------------------- The A-Calls-B session */

ABSession	:  ADigP1_4 _ASBSNum ANumB

		{
		  if($1==$2)
		  {
		    printf("\n*** Complete ABSession detected ***\n\n");
		  }
		  else
		  {
		    printf("A Fetched wrong number!!!! %d != %d\n\n",$1,$2);
		    exit(0);
		  }
		}

		;

ANumB		: _CallBusy _SBSFree		/* B is busy. Hang up?	*/
		| _PrivCall _Conv EndSession	/* Private call		*/
		| _Conv EndSession		/* Normal call		*/
		;

EndSession	: _CKey _EndConv _SBSFree	/* A presses C_KEY	*/
		;
ADigP1_4	: _ADigP _ABusy
		{
		  $$ = $1;
		}
		| _ADigP _ABusy _ADigP
		{
		  $$ = 10*$1 + $3;
		}
		| _ADigP _ABusy _ADigP _ADigP
		{
		  $$ = 100*$1 + 10*$3 + $4;
		}
		| _ADigP _ABusy _ADigP _ADigP _ADigP
		{
		  $$ = 1000*$1 + 100*$3 + 10*$4 + $5;
		}
		;



_ADigP		: SBSNUM DIGIT INTEGER NL	/* A pressed a digit	*/
		{
		  $$ = $3;
		  printf("%d trykket paa '%d'\n",$1,$3);
		}
		;

_ABusy		: SBSNUM SBS_BUSY NL
		;
		
_ASBSNum	: SBSNUM SBS_NO SBSNUM NL
		{
		  $$ = $3;
		  printf("SBS-num = %d\n",$3);
		}
		;

_CallBusy	: SBSNUM CALL_BUSY SBSNUM NL
		;

_SBSFree	: SBSNUM SBS_FREE NL
		;

_PrivCall	: SBSNUM PRIV_CALL SBSNUM NL
		;

_Conv		: SBSNUM CONV SBSNUM NL
		;

_CKey		: SBSNUM C_KEY NL
		;

_MKey		: SBSNUM M_KEY NL
		;

_EndConv	: SBSNUM END_CONV SBSNUM NL
		;

%%


#include "lex.yy.c"