HDTenEightyP/NetNews huggingface dataset:
From: aroll@gucis.cit.gu.edu.au (Ashley Roll)
Subject: expanding ~'s in a directory name.
Organization: Griffith University, Brisbane, Australia.
Date: Wed, 29 Jul 92 01:26:29 GMT

I have a program that I'm writing in C in the UNIX environment and I have come
to a part where I need to get a directory name that the program will change 
into. 

My problem is how do I expand ~'s. I want to expand then the way that csh does.

Has anyone written or got code that will do this that I can use? Or is there
a library function that will do this.

Thanks in advance...

Cheers,
Ashley Roll.


-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
  Ashley Roll - aroll@gucis.cit.gu.edu.au   Griffith University, Australia
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
Lie: a very poor substitute for the truth, but the only one discovered to date.
                                   - Unknown.

                        - - - - - - - - - - - - - -
  The thoughts, ideas and opinions expressed herein are my own and as such  
    are completly correct, I will however respect your right to be wrong. 
-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-
From: jmp@moscom.UUCP (Joe Palumbos)
Newsgroups: comp.unix.programmer
Subject: Controlling Terminal question
Date: 28 Jul 92 19:04:27 GMT
Organization: Moscom Corp., Pittsford, NY
X-Newsreader: Tin 1.1 PL3

I have a program that replaces getty:  it conditions a port, then
waits for input for a login.  

It works ok if I start my own executable program, but if I try to
fork & exec 'su -<usr>' to allow a standard login from that port, I 
get the following message on the port:

	Reset tty pgrp from <parent-pid> to <child-pid>

If I ignore SIGHUP, I get this 'reset' msg about 24 times, then
the child (su) dies.

if I trap SIGHUP & write a debug-msg to a file, I get the message
2 times, and the child (su) runs on the port, but the parent dies
('Hangup'), after the debug-msg is written.  

	- I'm running on SunOS 4.1.2
	- The port is not configured to run getty.  
	- To dissociate the child from the parent, before 
	  the exec() call, I do the following:
		- close fd 0,1 & 2.
		- call setsid() to start a new session w this port as 
			the controlling term.
		- open the port 2x for std in/out
		- dup stdout for stderr
	- I condition the port with standard stty settings 


Is there something else I need to do to remove the terminal from
the process-group of the parent?  Any help will be appreciated.
-- 
Joe Palumbos	jmp@moscom.com		{rit,tropix,ur-valhalla}!moscom!jmp
Newsgroups: comp.unix.programmer,comp.unix.questions
From: Ross Ridge <ross@zooid.guild.org>
Subject: Re: Need (today's date + [1-7] days)
Organization: ZOOiD BBS
Date: Tue, 21 Jul 1992 05:27:06 GMT
Keywords: date

dejesus@archimedes.nwc.navy.mil (Francisco X DeJesus) writes:
>I realize that date/time-related questions are common here, so no flames
>if this has been asked before...
>
>If I can get today's date in a shell script or C program, how can I find
>out the dates of the next week? For example, if I know today is
>"Wed Dec 30 1992", how can I have the program now that the next seven days
>are going to be "Thu Dec 31 1992", "Fri Jan 1 1993", etc (taking the
>case in which both month and year could change).

In C something like:

	int
	main(argc, argv) 
	int argc;
	char **argv; {
		long now, time(), atol();

		now = time((long *)0);
		if (argc == 2) {
			now += atol(argv[1]) * 60L * 60L * 24L;
		}

		puts(ctime(&now));

		return  0;
	}

If you call this programme "foo", then "foo 3" will print out what
the time and date will be three days from now in the same format
as the date command.  The key thing here is that Unix time is
kept as the number of seconds since midnight Jan 1 1970 GMT, and
so it's easy to do arithmetic like adding a day.

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //
Newsgroups: comp.unix.programmer
From: bill@Celestial.COM (Bill Campbell)
Subject: Re: pipe CC to more
Organization: Celestial Software, Mercer Island, WA
Date: Fri, 24 Jul 1992 05:59:30 GMT

In <1029@alsys1.aecom.yu.edu> reiner@medusa.bioc.aecom.yu.edu (Peter D. Reiner) writes:

:To prevent the hundreds of CC errors from scrolling off the screen,
:I have tried to pipe it to more, with no effect.
:Can anyone advise? (ATT unix)

Assuming /bin/sh or /bin/ksh

cc $CFLAGS tmp.c 2>&1 | less #less is > more :-)

In the csh
cc $CFLAGS tmp.c |& less #less is > more :-)

Bill
-- 
INTERNET:  bill@Celestial.COM   Bill Campbell; Celestial Software
UUCP:   ...!thebes!camco!bill   6641 East Mercer Way
             uunet!camco!bill   Mercer Island, WA 98040; (206) 947-5591
SPEED COSTS MONEY -- HOW FAST DO YOU WANT TO GO?
From: Frank@mindlink.bc.ca (Frank I. Reiter)
Newsgroups: comp.unix.programmer
Subject: TCP/IP connections, how does the blocking work?
Date: 24 Jul 92 14:13:58 GMT
Organization: MIND LINK! - British Columbia, Canada
Distribution: world

I am considering moving relatively large amounts of data from a fast
originating process on one machine, to a relatively slow receiving process on
another machine via sockets.

If the originating process attempts to write a few megabytes more than the
receiving process has read, will it block, what causes it to block, and how far
ahead is it likely to get before it does block?

I want to make sure I will not be placing undo stress on the receiving machine
by causing it to try to buffer data not yet read by the process it is intended
for.  Can the receiving machine cause the sending machine to cause the sending
process to block?

Frank.
--
___________________________________________________________________
Frank I. Reiter                Internet: Frank@mindlink.bc.ca
MIND LINK! Communications Corp. Surrey, British Columbia, Canada
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.programmer
Subject: Re: TCP/IP connections, how does the blocking work?
Date: 24 Jul 1992 17:03:31 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: world
NNTP-Posting-Host: telecaster.think.com

In article <13700@mindlink.bc.ca> Frank@mindlink.bc.ca (Frank I. Reiter) writes:
>If the originating process attempts to write a few megabytes more than the
>receiving process has read, will it block, what causes it to block, and how far
>ahead is it likely to get before it does block?
>
>I want to make sure I will not be placing undo stress on the receiving machine
>by causing it to try to buffer data not yet read by the process it is intended
>for.  Can the receiving machine cause the sending machine to cause the sending
>process to block?

The simple answer is "yes".  With properly functioning TCP/IP
implementations, you don't have to worry about the sender sending faster
than the receiver can handle.

The receiving machine provides a "window" to the sender, which is (to
simplify greatly) the amount of data it may send before waiting for an
acknowledgement.  If the receiving machine is buffering data that the
process hasn't yet read, it will normally reduce the window and stop
acknowledging, to tell the sender not to send any more.  When room in the
buffers becomes available it will open the window and the sender can start
again.

On the sending machine, when it has reached the limit specified by the
window, the kernel will start buffering data locally.  When these kernel
buffers fill up, the sending process will be blocked.

-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.unix.programmer
From: sstakoff@csfb1.fir.fbc.com (Stuart Stakoff)
Subject: Signal handlers and longjmp() 
Keywords: signal longjmp setjmp
Reply-To: uunet!csfb1!sstakoff
Organization: First Boston Corporation
Date: Fri, 31 Jul 1992 02:00:47 GMT


I am having the following signal handler problem:

I want to do some fairly elaborate stuff when a SIGSEGV is detected.  I
don't want to do a lot of processing within the signal handler itself, so
I am using setjmp/longjmp.  For example:

jmp_buf env;

main()
{


  signal(SIGSEGV,handler);

  if (setjmp(env)) {
    do_stuff();
  }
}

handler()
{
  signal(SIGSEGV,SIG_DFL);   // This doesn't seem to have any effect
  
  // Get out of signal handler context and do whatever processing
  // needs to be done for this signal
  longjmp(env,1);
}

do_stuff()
{

  ... handle the signal

  ???? I now want the default handler to be called!
}

------------------------------------------------------------

With the above code, when a SEGV is generated, my do_stuff()
routine is called.  I can't seem to get the default signal handler
to be called.  My goal is to handle the signal in my own way and then
have the normal core dump occur.  I have tried playing around
with sigsetmask and sigprocmask but have had no luck.  I would
appreciate any help.

Thanks in advance.  

Please send replies via email.  I will post a followup.

-- 


   +-------------------------------------------------------------------+
   |   Stuart A. Stakoff           |      sstakoff@csfb1.fir.fbc.com   |
   |   First Boston Corporation    |      uunet!csfb1!sstakoff         |
   |   (212)909-4926               |      (212)688-0913 - FAX          |
   +-------------------------------------------------------------------+

Newsgroups: comp.unix.programmer
From: bbobak@undergrad.math.waterloo.edu (Brad Bobak)
Subject: Re: I am stumped on this one!!!
Organization: University of Waterloo
Date: Fri, 24 Jul 1992 23:43:51 GMT

In article <1992Jul24.204944.18516@cbfsb.cb.att.com> rajeev@cbnewsf.cb.att.com (rajeev.dolas) writes:
>
>Hello all,
>
>	I have included a function from my code which doesn't work on a Sun
>	(690 w/ 4.1.2) but works on an Amdahl and I can't figure out why. 
>	I am seeking help from the net after spending considerable amount of
>	time trying to debug this. I appreciate your help.
>
>	Thanks in advance.
>
>	Raj Dolas
>	raj@qsun.att.com
>
>
>
>#include <stdio.h>
>
>/* I have deleted lots of stuff to keep it simple for netters */
>parse_conf(f2)
>int f2;
>{
>
>	char fname[80], ch, cmp[80];
>	char pars_wbuf[128];
>	char *pbuf;
>	char *cp_line;
>	char *tmp_line;
>	char *var, *getenv();
>	int comp, he;
>	int parse_ret;
>	int fd;
>	FILE *fp1, *fp2;
>
>	strcpy(fname, "/qsun/h5/raj/progs/acs/config/Star3/072392");
>
>	umask(0);
>	umask(066);
>	if((fp1 = fopen(fname, "w")) == NULL) 
>	{
>		if((fp1 = fopen(fname, "w+")) == NULL)
>		printf("Cannot open fp1 in parse_conf()\n");
>		return(-78);
>	}
>
>	/** f2 was opened in another function with "w" and data was written */
>	if((fp2 = fdopen(f2, "r")) == NULL)
>	{
>		printf("Cannot open fp2 in parse_conf()\n");
>		return(-78);
>	}
>
>	/* As data was written to this file before, I must do a fseek */
>	if((he = fseek(fp2, 0L, 0)) < 0)
>	{
>		printf("fseek error in parse_conf()\n");
>		return(-78);
>	}
>
>	/* str_comp is my function which returns -1 if match is not found */
>	while((fgets(pars_wbuf, 80, fp2) != NULL) &&
>		((parse_ret = str_comp(cmp, pars_wbuf)) != 0))
>	{
>		pars_wbuf[strlen(pars_wbuf)] = '\0';
>		pbuf = pars_wbuf;
>		cp_line = (char *)malloc(sizeof(strlen(pars_wbuf)));


 You're allocing the sizeof an int, which is likely four bytes.
 You also forgot to alloc space for the '\0'. Try it again with:

	cp_line = (char*)malloc(sizeof(strlen(pars_wbuf) + 1));

>		strcpy(cp_line, "\0");
>		tmp_line = cp_line;
>
>		if((comp = line_comp(pars_wbuf)) == 0)
>			;
>		else 
>		{
>			/* Traverse thru pbuf, skip "
>			while(*pbuf != '\0')
>			{
>				if(*pbuf != 0x0D)
>				{
>					/* I was writing a char at a time to
>					   the file before. This part works
>					   on Amdahl but not on a sun.	*/
>
>					/**
>					ch = *pbuf;
>					fprintf(stdout, "%c", ch); 
>					if((he = putc(ch, fp1)) < 0)
>					{
>					     printf("pars_conf: Write error\n");
>						return(-13);
>					}
>					**/
>
>					/* Now I save it to a buffer */
>					*cp_line++ = *pbuf;
>				}
>				*pbuf++;
>			}
>			/* If I do a fputs to stdout, it works fine */
>			/**
>			fputs(tmp_line, stdout);
>			fflush(stdout);
>			**/
>
>			/* dbxtool shows the following error on this instr -
>			 signal SEGV in malloc at 0xf773634
>			 malloc+0x150:	st	%o0, [%15]
>			 */
>			fputs(tmp_line, fp1);
>		}
>		free(cp_line);
>	}
>	
>	fclose(fp1);
>
>	
>	if(fname)
>		free(*fname);
>	
>	if(parse_ret != 0)
>		return(-89);
>
>}
>
>
>



Xref: sparky comp.unix.programmer:3868 comp.unix.internals:1595
From: urlichs@smurf.sub.org (Matthias Urlichs)
Newsgroups: comp.unix.programmer
Subject: Re: named pipes (was: Finger and .plan, .project)
Date: 27 Jul 1992 12:28:30 +0200
Organization: University of Karlsruhe, FRG
NNTP-Posting-Host: 127.0.0.1
Keywords: named pipes, fopen, popen, .plan, .profile, .signature

In comp.unix.internals, article <1992Jul26.165838.1278@news.eng.convex.com>,
  tchrist@pixel.convex.COM (Tom Christiansen) writes:
< 
<     $ diff (tail file1) (tail file2)
< 
< which sometimes is implemented using temporary named pipes, or sometimes
< with the /dev/fd stuff if you're lucky enough to have it.  I'm not 
< sure why on systems without either you couldn't use a regular temp file.
< 
End of file. You'd have to wait for both tail processes to finish before you
could start the diff. That doesn't really make sense because you want to wait
for the file to be closed, not for the processes to end. These two conditions
are somewhat unrelated.

You could probably create the temp files, mandatory-lock them, and then 
exec the tail processes. If the diff waits for the lock correctly (that's why
the lock has to be mandatory) you have a workable lockout.

Are there any systems with mandatory locking but without either named
pipes, unix-domain stream sockets, ptys, or ... well, anything else that
could do the job?

< Named pipes also used when someone wants a program to intercept I/O calls,
< allowing a file to produce more interesting output.  This is the case when
< people replace their dot-plan with a pipe, for instance.

Or their .signature. ;-)

< Furthermore, I believe that under both Plan9 and SunOS that you can have a 
< filesystem type that does the right thing, so if people did this:
< 
<     ln -s ~/.plan /plans/$USER
< 
< Then have /plans be a special filesystem type that triggers invocation
< of the right code.
< 
I don't know about SunOS, but Plan 9 can do it.
You don't even need the symlink, just mount your personal signature server
over your home directory.

< What programs would break drastically if we changed the library fopen()
< call to either accept "rx"/"wx" to indicate a popen(), or else for the
< sake of transparency, to have it stat() the file and check for the execute
< bit?  (Should we to do it for open() as well?  Probably.)  Certainly editors
< would prefer the former solution, but most general purpose programs the
< latter one.
< 
Ugh. I'd include almost every development tool. Or take cp for instance --
do you still want to be able to copy executable files?  ;-)

-- 
If you happen to be one of the fretful minority who can do creative work,
never force an idea; you'll abort it if you do. Be patient and you'll give
birth to it when the time is ripe. Learn to wait.
                -- Lazarus Long
-- 
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.programmer
From: reed@eagle.agps.lanl.gov (Reed_Kevin)
Subject: Curses Doesn't Use Terminal Features?????
News-Software: VAX/VMS VNEWS 1.41    
Organization: Los Alamos National Laboratory, Mech. and Elec. Eng
Date: Wed, 29 Jul 1992 17:42:00 GMT

I was using some code t that uses Curses, and I was curious how
it preformed a scroll.  I slowed the vt220 terminal I was using
down to 300baud and watched what happened when I called scroll()
To my amazement, it completely rewrote the entire screen, rather
then sending the escape sequence to cause the terminal to scroll.
Does curses really generate all this extra noise on the network
or did I observe something else?  Included is the code I used to
test it.

#include	<curses.h>
main()
{
	int	i;
	
	initscr();
	scrollok(stdscr,TRUE);
	for(i=0;i<10;i++) {
		printw("Greetings\n\r");
		printw("all you people\n\r");
		printw("out there in netland\n\r");
		printw("Are we having fun yet?\n\r");
	}
	refresh();
	scroll(stdscr);
	printw("Yes, we are!\n\r");
	refresh();
	endwin();
}


Thanks, email responses to me, I post a summary if anyone is interested.

Kevin Reed
Los Alamos National Laboratory
reed@eagle.agps.lanl.gov
From: basile@soleilserma.cea.fr (Basile STARYNKEVITCH)
Newsgroups: comp.unix.programmer
Subject: Re: Wanted: preemptive threads within a UNIX process
Keywords: threads lightweight processes libraries
Date: 30 Jul 92 15:37:34 GMT
Reply-To: basile@soleil.serma.cea.fr (Basile STARYNKEVITCH)
Organization: Commissariat a l Energie Atomique

In article <Bs5Itn.Dr@logware.de>, beha@logware.de (Berthold Hienger) writes:
|> 
|> We are in desperate search for a C++ library providing us with classes for preemptive
|> multitasking within an UNIX process (preemptive scheduling of lightweight processes).
To: beha@logware.de (Berthold Hienger)
Reply-To: basile@soleil.serma.cea.fr (Basile STARYNKEVITCH)
Subject: Re: Wanted: preemptive threads within a UNIX process



**
NIHCL is A Class library writen by Gorlen at the National Institute of
Health (USA). It is available from ftp (NIHCLversion3). Gorlen has also
written a book on object programming in C++ using NIHCL.

NIHCL contains a sort of meta-class facility for C++ (ie NIHCL CLasses
are described by explicit C++ objects) and many utilities classes (much
as in Smalltalk). It contains also a thread class (called Proc in
NIH).

Some small parts of NIHCL are system-, machine-, and compiler-
dependent. NIH does run on Sun4, SunOS4.1, with SunC++2.1 (if
i remember correctly) [all sophisticated system calls are system
dependent. The thread class is machine dependent. The NIHCL sort of
meta-class facility is also compiler- dependent].

I did not use intensively NIHCL but read some part of the book and some
part of the sources. Both are very interesting. My personal wish would
be that C++ language be changed for better support of NIHCL like stuff.

-- 
Basile STARYNKEVITCH
Commissariat a l Energie Atomique
DRN/DMT/SERMA * C.E. Saclay bat.470 * 91191 GIF/YVETTE CEDEX * France
fax: (33) 1- 69.08.23.81;    phone: (33) 1- 69.08.40.66
email: basile@soleil.serma.cea.fr;  homephone: (33) 1- 46.65.45.53
N.B. Any opinions expressed here are solely mine, and not of my organization.
N.B. Les opinions exprimees ici me sont personnelles et n engagent pas le CEA.
Newsgroups: comp.unix.programmer,comp.unix.sysv386
From: larry@gator.rn.com (Larry Snyder)
Subject: Re: I/O of login shell
Organization: The Gator Public Access Unix Site - 219-289-3745
Distribution: usa
Date: Fri, 31 Jul 1992 10:53:48 GMT

erica@wariat.org (Lady of the BitMode) writes:

>When a person logins into a unix system the system must first:
>1) spawn a getty from teriminal

why use getty with SVR4 when you have ttymon?

-- 
Larry Snyder                                    internet: larry@gator.rn.com
4950 Estero Blvd, Ft. Myers Beach, FL            uucp: uunet!rde!nstar!larry
Newsgroups: comp.unix.programmer
From: matt@fics.uucp (Shithead II)
Subject: Re: Help! Output going everywhere...
Organization: Kvam data as
Date: Sat, 25 Jul 1992 05:00:58 GMT
Keywords: pipes, widgets, children

In article <1992Jul24.040517.3375@tc.cornell.edu> reed@theory.tc.cornell.edu writes:
>I have a X client (motif widget set being used) that spawns a number of
>childen.  Now, since I use fork(), all file descripters are copied over to
>the children.  This is fine and dandy, but what I really want is to capture
>the output (stderr & stdout) from the children in a text widget (motif) in 

>if I am hung up in an XtMainLoop call (or do I need to change to something
>else [gasp! handle my own events????])?  I thought of using a SIGIO signal
>handler, but have been unable to get this to work (then again, it's my first

I *think* the clue is to lose your XtMainLoop() (i.e. don't use it)
and use something like...

   if (XtAppPending(ac))
   {
      XtAppNextEvent(ac, &event);
      XtDispatchEvent(&event);
   }
   else
   {
      /* do the read_from_pipe_thing() */
   }

The XtAppNextEvent() blocks waiting for input so I think you want
the XtAppPending() check...This doesn't really have to been an if/else
...but whatever...

oh...and I think the signals are a no-no (I don't believe they were
designed or intended for interprocess communication...)

Matthew Kerr
Kvam data as
Nikkelveien 14, N-4300 Sandnes, Norway
Tel: + 47 4 62 37 66
Fax: + 47 4 62 39 85
Newsgroups: comp.unix.programmer
From: hpeyerl@novatel.cuc.ab.ca (Herb Peyerl)
Subject: Re: named pipes (was: Finger and .plan, .project)
Organization: none
X-Newsreader: Tin 1.1 PL3
Date: Wed, 29 Jul 1992 15:04:54 GMT

tchrist@convex.COM (Tom Christiansen) writes:
: At various times, I've wanted to have /etc/motd, my .signature, and my
: .plan and .project be hooks to programs, not regular files.  In the case

Gee.. Wouldn't it be great to have a typed file system where you could
write a type manager to perform a specific function, then assign that 
type to a file such that whenever an operation is performed on that 
file (open, read, write, stat, etc), the manager is called to perform
the operation... Oh sorry; Domain/OS already had that feature but not
enough people liked it...  :->

:     ln -s ~/.plan /plans/$USER

Wow... Another good idea that Domain/OS has had for years...

It does away with things like "5bin, 5usr" etc... you can have
/bsd4.3/[bin, usr, etc] and /sys5.3/[bin, usr, etc] and then you
can "ln -s /usr /'($SYSTYPE)'/usr"...

: What programs would break drastically if we changed the library fopen()
: call to either accept "rx"/"wx" to indicate a popen(), or else for the
: sake of transparency, to have it stat() the file and check for the execute
: bit?  (Should we to do it for open() as well?  Probably.)  Certainly editors
: would prefer the former solution, but most general purpose programs the
: latter one.

Actually, if something like this were to be attempted, then people could
have the compressed-file-type that they're always whining about... 

Though I wonder if it wouldn't be better to dig right into the filesystem
itself and create some room there??? It seems like a lot more work but
far less "kludgey".. Probably more difficult to distribute... (Not that
I understand filesystem internals all that well...)

Anyways, just some random comments... Didn't mean to whine about any-
thing... I'm still a little shell-shocked about the whole Apollo/HP
incident...

--
"I was early to finish | hpeyerl@novatel.cuc.ab.ca <Reply-To>   | I brew |
I was late to start, I | peyerlh@cuug.ab.ca                     | there- | 
might be an adult, but | #define JANITOR "Network Administrator"| fore I | 
I'm a minor at heart." |    JANITOR, NovAtel Communications Ltd.|   AM.  |
Newsgroups: comp.unix.programmer,comp.unix.questions