[comp.unix.questions] talk session

greg@athena.cs.uga.edu (Greg Whitlock) (05/07/91)

Recently there was a post concerning the capturing of a 'talk'
session.  One reply was to issue the 'talk' command in the
following format: 
		 talk <whoever> | tee <filename>
and your talk session would be captured in the file <filename>.

It is then fun to simply: cat <filename>
and watch your whole talk session be recreated.  However, it is 
nearly impossible to read and since <filename> contains all the
control characters from your session, it is a pain to read other-
wise.

A friend of mine wrote this neat little c program called 
'scat' (for slow cat) which will display the talk session
or other text file in reduced speed. Just specify the length
of the delay.  The default is 30.

Hope this helps someone.

------------------------>cut here<------------------------------
/*
 *
 *	scat - written by gordon.edwards@atlantaga.ncr.com
 *
 *	This short program displays the contents of a file with delays
 *	after each line.  
 *
 *	Invoke with the filename and optional delay on the command line.
 *
 *	Example:
 *
 *		scat filename or
 *		scat filename 40
 *
 *	If no delay is specified then 30 is used as the default.
 */

#include <stdio.h>

main(argc, argv)
int argc;
char *argv[];
{
	int c, delay, i;
	FILE *fopen(), *fp;

	if (argc < 2)
	{
		printf("usage: %s filename [delay]\n", argv[0]);
		exit(-1);
	}

	if ((fp = fopen(argv[1], "r")) == NULL)
	{
		printf("%s: Can't open file %s\n", argv[0], argv[1]);
		exit(-1);
	}

	if (argc < 3)
		delay = 30*1000;
	else
	{
		sscanf(argv[2], "%d", &i);
		delay = i * 1000;
	}

	while ((c = getc(fp)) != EOF)
	{
		printf("%c", c);
		for (i = 0; i < delay; i++)
			;
	}

	fclose(fp);
}
-- 



=============================================================================

boyd@prl.dec.com (Boyd Roberts) (05/07/91)

In article <1991May7.000521.28186@athena.cs.uga.edu>, greg@athena.cs.uga.edu (Greg Whitlock) writes:
> 
> 		for (i = 0; i < delay; i++)
> 			;
> 

You cannot be serious.  I think your `friend' should man sleep(3).


Boyd Roberts			boyd@prl.dec.com

``When the going gets wierd, the weird turn pro...''

weimer@garden.ssd.kodak.com (Gary Weimer (253-7796)) (05/07/91)

In article <1991May7.084631.10183@prl.dec.com>, boyd@prl.dec.com (Boyd
Roberts) writes:
|> In article <1991May7.000521.28186@athena.cs.uga.edu>,
greg@athena.cs.uga.edu (Greg Whitlock) writes:
|> > 		for (i = 0; i < delay; i++)
|> > 			;
|> You cannot be serious.  I think your `friend' should man sleep(3).

Mmmm, my man page doesn't tell me how to sleep for less than 1 second...

weimer@ssd.kodak.com ( Gary Weimer )

jmason@gpu.utcs.utoronto.ca (Jamie Mason) (05/07/91)

In article <1991May7.000521.28186@athena.cs.uga.edu> greg@athena.cs.uga.edu (Greg Whitlock) writes:

>------------------------>cut here<------------------------------
>/*
> *
> *	scat - written by gordon.edwards@atlantaga.ncr.com
> *
> *	This short program displays the contents of a file with delays
> *	after each line.  
                            .
                            .
                            .
>	while ((c = getc(fp)) != EOF)
>	{
>		printf("%c", c);
>		for (i = 0; i < delay; i++)
>			;
>	}

	Do I see a *BUSY WAIT*?!?  On a multi-user system like Unix?
*OUCH*!  How about using usleep?

Jamie  ...  Segmentation fault (core dumped)
Written On  Tuesday, May 7, 1991  at  11:57:25am EDT

sef@kithrup.COM (Sean Eric Fagan) (05/09/91)

In article <1991May7.102219.25557@ssd.kodak.com> weimer@ssd.kodak.com writes:
>Mmmm, my man page doesn't tell me how to sleep for less than 1 second...

SunOS:  usleep()
Xenix:  nap() (note also present in SysVr3.2 and later)
SysVr3.[01]:  use poll(); this might not be present in your version of
	SysVr3.[01]
SysVr2.x:  use read on a tty device, with min=1 time=<x>, where <x> is the
	number of 1/10ths of a second you wish to delay
4.[23]BSD:  use select() (similar to poll() above, but more portable)

All of thse are (or should be 8-)) documented.  The problem is that, except
for usleep() and nap(), none of them was intended to be used soley as a
sleep-call.

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

metzger@watson.ibm.com (Perry E. Metzger) (05/09/91)

In article <1991May7.102219.25557@ssd.kodak.com> weimer@ssd.kodak.com writes:
>In article <1991May7.084631.10183@prl.dec.com>, boyd@prl.dec.com (Boyd
>Roberts) writes:
>|> In article <1991May7.000521.28186@athena.cs.uga.edu>,
>greg@athena.cs.uga.edu (Greg Whitlock) writes:
>|> > 		for (i = 0; i < delay; i++)
>|> > 			;
>|> You cannot be serious.  I think your `friend' should man sleep(3).
>
>Mmmm, my man page doesn't tell me how to sleep for less than 1 second...

Check out usleep, or, if you don't have it and are on a BSD system,
write your own using select with a timeout and no file descriptors. Or
use the getitimer/setitimer facility if somehow you don't have the
rest but you have them. All these let you nap for less than a second.

Really, there is ABSOLUTELY NO EXCUSE for busy waiting on a
timesharing system. Its obnoxious because it wastes the cycles other
people could be getting work done during.

Perry

brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/09/91)

In article <1991May8.194940.13610@watson.ibm.com> metzger@watson.ibm.com (Perry E. Metzger) writes:
> >|> > 		for (i = 0; i < delay; i++)
> >|> > 			;
> Really, there is ABSOLUTELY NO EXCUSE for busy waiting on a
> timesharing system.

There would be if you had a really, really smart compiler that detected
loops of the above form, timed 100 runs to see how long each loop took,
and stuck in an appropriate usleep() or select() or nap() or poll() for
that machine.

:-)

---Dan

mkaminsk@cvbnet.prime.com (mailhost) (05/09/91)

From article <azK/EJXR7ndok@idunno.Princeton.EDU>, by subbarao@phoenix.Princeton.EDU (Kartik Subbarao):
> In article <1991May7.102219.25557@ssd.kodak.com> weimer@ssd.kodak.com writes:
>>
>>In article <1991May7.084631.10183@prl.dec.com>, boyd@prl.dec.com (Boyd
>>Roberts) writes:
>>|> In article <1991May7.000521.28186@athena.cs.uga.edu>,
>>greg@athena.cs.uga.edu (Greg Whitlock) writes:
>>|> > 		for (i = 0; i < delay; i++)
>>|> > 			;
> You should man usleep(3).

Actually usleep(3) is going away in System V Release 4 (SVr4)
so you can use select(2):

    #include <stdio.h>
    #include <sys/types.h>
    #include <sys/time.h>

    struct timeval      timeout;

    timeout.tv_sec = 0;
    timeout.tv_usec = number_of_microseconds;

    /* call select for it's timeout feature */
    select(1, NULL, NULL, NULL, &timeout);

Of course you may sleep a lot longer than you want -
do to whatever else is happening on the system.

Mark B. Kaminsky   mkaminsk@cvbnet.prime.com
Computervision/Prime Computer, Bedford, Massachusetts, USA

tchrist@convex.COM (Tom Christiansen) (05/09/91)

From the keyboard of brnstnd@kramden.acf.nyu.edu (Dan Bernstein):
:In article <1991May8.194940.13610@watson.ibm.com> metzger@watson.ibm.com (Perry E. Metzger) writes:
:> >|> > 		for (i = 0; i < delay; i++)
:> >|> > 			;
:> Really, there is ABSOLUTELY NO EXCUSE for busy waiting on a
:> timesharing system.
:
:There would be if you had a really, really smart compiler that detected
:loops of the above form, timed 100 runs to see how long each loop took,
:and stuck in an appropriate usleep() or select() or nap() or poll() for
:that machine. :-)

Really smart compilers optimize the whole loop away anyway. :-(

--tom
--
Tom Christiansen		tchrist@convex.com	convex!tchrist
		"So much mail, so little time." 

natha@hal.com (Nathaniel Ingersol) (05/09/91)

In article <1489@cvbnetPrime.COM> mkaminsk@cvbnet.prime.com (mailhost) writes:
:
:Actually usleep(3) is going away in System V Release 4 (SVr4)
:so you can use select(2):
:
:    #include <stdio.h>
:    #include <sys/types.h>
:    #include <sys/time.h>
:
:    struct timeval      timeout;
:
:    timeout.tv_sec = 0;
:    timeout.tv_usec = number_of_microseconds;
:
:    /* call select for it's timeout feature */
:    select(1, NULL, NULL, NULL, &timeout);
:

Am I missing something here, or why can't you just make a usleep out
of setitimer?  You could even use ITIMER_REAL.

N

pfalstad@phoenix.princeton.edu (Paul Falstad) (05/10/91)

natha@hal.com (Nathaniel Ingersol) wrote:
>In article <1489@cvbnetPrime.COM> mkaminsk@cvbnet.prime.com (mailhost) writes:
>:
>:Actually usleep(3) is going away in System V Release 4 (SVr4)
>:so you can use select(2):
>:
>:    #include <stdio.h>
>:    #include <sys/types.h>
>:    #include <sys/time.h>
>:
>:    struct timeval      timeout;
>:
>:    timeout.tv_sec = 0;
>:    timeout.tv_usec = number_of_microseconds;
>:
>:    /* call select for it's timeout feature */
>:    select(1, NULL, NULL, NULL, &timeout);
>:
>
>Am I missing something here, or why can't you just make a usleep out
>of setitimer?  You could even use ITIMER_REAL.

You could just do this, yes.

---
#include <sys/time.h>
#include <signal.h>
#include <stdio.h>

int handler(){;} /* needed to make pause() work */

usleep(unsigned usec) {
   struct itimerval ix;

   ix.it_value.tv_sec = 0;
   ix.it_value.tv_usec = usec;
   ix.it_interval.tv_sec = 0;
   ix.it_interval.tv_usec = 0;
   signal(SIGALRM,handler);
   setitimer(ITIMER_REAL,&ix,NULL);
   pause();
   signal(SIGALRM,SIG_DFL);
}
---

Looks harder to me.  :-)

--
              Paul Falstad  pfalstad@phoenix.princeton.edu
         And on the roads, too, vicious gangs of KEEP LEFT signs!
     If Princeton knew my opinions, they'd have expelled me long ago.

lh@aega84.UUCP (L. Hirschbiegel) (05/10/91)

In article <azK/EJXR7ndok@idunno.Princeton.EDU> subbarao@phoenix.Princeton.EDU (Kartik Subbarao) writes:
>>greg@athena.cs.uga.edu (Greg Whitlock) writes:
>>|> > 		for (i = 0; i < delay; i++)
>>|> > 			;
>>|> You cannot be serious.  I think your `friend' should man sleep(3).
>>
>>Mmmm, my man page doesn't tell me how to sleep for less than 1 second...
>>weimer@ssd.kodak.com ( Gary Weimer )
>
>You should man usleep(3).
>		-Kartik

Mmmm, my SYSV man doesn't tell me what this is good for... :-)

====================================================================
L. Hirschbiegel, AEG Produktionsautomatisierung, Frankfurt (Germany)
unido!aega84!lh                                      -49-69-66414316
====================================================================

guy@auspex.auspex.com (Guy Harris) (05/11/91)

>SunOS:  usleep()

Welcome to the club - the club, that is, of folks who think "usleep()"
is a SunOS-ism.  Dunno how people get into that club; perhaps the first
UNIX system on which they see "usleep()" is a SunOS system.

"usleep()" first appeared in 4.3BSD; SunOS picked it up from there.

>SysVr3.[01]:  use poll(); this might not be present in your version of
>	SysVr3.[01]

What versions of S5R3.[01] deleted "poll()"?

>4.[23]BSD:  use select() (similar to poll() above, but more portable)

4.3BSD-and-later: use "usleep()".

sef@kithrup.COM (Sean Eric Fagan) (05/11/91)

In article <7739@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>SunOS:  usleep()
>Welcome to the club - the club, that is, of folks who think "usleep()"
>is a SunOS-ism.  Dunno how people get into that club; perhaps the first
>UNIX system on which they see "usleep()" is a SunOS system.
>"usleep()" first appeared in 4.3BSD; SunOS picked it up from there.

Ok.  I never got to play with a 4.3BSD system until a couple of years ago,
and, even then, there were quite a few modifications made locally.

>>SysVr3.[01]:  use poll(); this might not be present in your version of
>>	SysVr3.[01]
>What versions of S5R3.[01] deleted "poll()"?

The version of SysVr3.0 for teh 3B15 that CSU Northridge got when I was
there did not have STREAMS, and, therefore, didn't have poll().  (And, yeah,
I checked:  it didn't have poll().)

I don't know if that was a weird release, or if it was standard.  I am
fairly certain that STREAMS were standard for 3.1 and later.

>>4.[23]BSD:  use select() (similar to poll() above, but more portable)
>4.3BSD-and-later: use "usleep()".

Ok.  It is better than select(), or at least more intuitive and obvious what
you have to do 8-).

-- 
Sean Eric Fagan  | "I made the universe, but please don't blame me for it;
sef@kithrup.COM  |  I had a bellyache at the time."
-----------------+           -- The Turtle (Stephen King, _It_)
Any opinions expressed are my own, and generally unpopular with others.

pauld@stowe.cs.washington.edu (Paul Barton-Davis) (05/11/91)

In article <7739@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>>SunOS:  usleep()
>

>>SysVr3.[01]:  use poll(); this might not be present in your version of
>>	SysVr3.[01]
>
>What versions of S5R3.[01] deleted "poll()"?

Install Streams ? no
Install foobar ? ....

V/386 doesn't get streams by default - you have to install it as
an "extra". If you don't have streams, you don't have poll().
-- 
Paul Barton-Davis <pauld@cs.washington.edu> UW Computer Science Lab	 

"People cannot cooperate towards common goals if they are forced to
 compete with each other in order to guarantee their own survival."

guy@auspex.auspex.com (Guy Harris) (05/13/91)

 >The version of SysVr3.0 for teh 3B15 that CSU Northridge got when I was
 >there did not have STREAMS, and, therefore, didn't have poll().  (And, yeah,
 >I checked:  it didn't have poll().)
 >
 >I don't know if that was a weird release, or if it was standard.  I am
 >fairly certain that STREAMS were standard for 3.1 and later.

I am completely certain that STREAMS were standard for 3.0 on the 3B2;
perhaps the folks who did the 3B15 version left them out for some reason
(if so, that's a strong argument for forcing UNIX ports for various
platforms to share as much of the source tree as possible, to force them
to be as similar as possible).

guy@auspex.auspex.com (Guy Harris) (05/13/91)

>:Actually usleep(3) is going away in System V Release 4 (SVr4)
>:so you can use select(2):
>
>Am I missing something here, or why can't you just make a usleep out
>of setitimer?  You could even use ITIMER_REAL.

Funny, that's just what Berkeley did when they did "usleep()" in the
first place....

And yes, you could do that in S5R4; in fact, that's probably what the
"usleep()" in the BSD compatibility package in S5R4 (see "UNIX(R) System
V Release 4 BSD/XENIX(R) Compatibility Guide) does (in fact, they may
well just have lifted the BSD code...).

I don't know what "usleep(3) is going away in S5R4" means; it wasn't
*in* any S5 releases prior to that, so it's not as if S5R4 got rid of
it.  It's not in the "mainstream" C library, but the manual referred to
in the previous paragraph indicates that it's in the BSD compatibility
code.