HDTenEightyP/NetNews huggingface dataset:
From: phil@ux1.cso.uiuc.edu (Phil Howard)
Newsgroups: comp.unix.programmer
Subject: Re: non-blocking hostname resolving
Date: 14 Apr 92 20:27:41 GMT
Organization: University of Illinois at Urbana

barmar@think.com (Barry Margolin) writes:

>>Does anyone have any code, or can point me to any, which can be integrated
>>into a program to allow doing a non-blocking hostname resolve so that other
>>activities can continue even if the DNS lookup is taking some time?
>
>Fork a subprocess that calls gethostbyname() and use some interprocess
>communication mechanism to send the resulting address back to the original
>process.
>
>If you have threads, that would be even better than a subprocess.

Oops... I didn't explain well enough.  I specifically need to do this in a
single process, since some platforms I want to use do not have fork() and
do not support multiple processing.  Wouldn't it be nice if every system
in the world were forced to have every feature?  Well maybe not.  Threads
won't do it unless the scope of blocking is by thread, and that is not
guaranteed, either.

The solution seems to be around select().  But I'd have to deal with the
DNS data myself instead of letting gethostbyname() to deal with it.
Newsgroups: comp.unix.programmer
From: phil@ux1.cso.uiuc.edu (Phil Howard)
Subject: non-blocking hostname resolving
Organization: University of Illinois at Urbana
Date: Mon, 13 Apr 1992 20:07:30 GMT

Does anyone have any code, or can point me to any, which can be integrated
into a program to allow doing a non-blocking hostname resolve so that other
activities can continue even if the DNS lookup is taking some time?  The
only lookup needed is to get the A-records for a given hostname (the client
will be doing FTP connections from the IP addresses it gets).
From: tasos@cs.bu.edu (Anastasios Kotsikonas)
Newsgroups: comp.unix.programmer
Subject: getting system load
Date: 9 Apr 92 13:38:40 GMT
Reply-To: tasos@cs.bu.edu (Anastasios Kotsikonas,student)
Organization: Computer Science Department, Boston University, Boston, MA, USA


My understanding is that system load is obtained from /dev/[kp]mem,
most likely from /dev/kmem. Is there a portable way of getting the
system load w/o having to modify the code?

Thanks,

Tasos
--
--
Tasos Kotsikonas |   tasos@cs.bu.edu    | Work : Advanced Visual Systems
Ex BU Country	 |                      | email: tasos@avs.com
Club Member.	 |                      | Duties: none
Newsgroups: comp.unix.programmer
From: bmcgowan@alias.com (Brian MacGowan)
Subject: Two Questions
Organization: Alias Research, Inc., Toronto ON Canada
Date: Mon, 13 Apr 1992 15:31:21 GMT

Hi, I am new to C programming and I 2 hopefully simple questions.
1) How can I simulate the find command. I need to search a directory and all of
   its subdirectories for various filenames.

2) Using curses if I have more data than can fit in a window, can I scroll the
   text up and down.

Any help with these 2 problems would be most appreciated.

Thanks

- Brian MacGowan, Alias Research Inc, Toronto - bmcgowan@alias.com
From: guy@Auspex.COM (Guy Harris)
Newsgroups: comp.unix.programmer
Subject: Re: How to write the ANSI C time functions
Date: 15 Apr 92 22:00:23 GMT
Organization: Auspex Systems, Santa Clara

>But I thought that's what UTC is: an atomic clock that advances
>by one every second, with leap seconds added in so that it
>(nearly) matches mean solar time.

It is - but atomic time is, at least as I see it, an atomic clock that
advances by one every second and does nothing else; no leap seconds, no
nothing.

Few, if any, UNIX systems arrange that the clock value returned by
"time()" twitch on a leap second (and those that do should be taken out
and shot), so "time()" is best thought of as an atomic clock, not UTC.

(Or, perhaps better, as an *approximation* to an atomic clock, rather
than as an *approximation* to UTC; *vide infra*.)

>And I thought that's what NTP is for: to receive a time standard
>from one of the broadcast atomic clocks, convert it to bits, and
>send it through the net.  It may not count as being connected to
>an atomic clock, but it's close since you're guaranteed the correct
>time within a certain amount of error.

Well, feel free to call me fussy, but I'd rather not call it "atomic
time" rather than "an approximation to atomic time" unless it's really
truly running directly off an atomic clock.  Many machines have
high-resolution timers, and many of them have the OS really attempt to
provide that resolution when you call "gettimeofday()" if the machine
has it (or an equivalent); that's fine enough resolution that I'd be
disinclined to call it "atomic time" unless it really is synced against
an atomic clock (and besides, those systems *also* tend to add in extra
microseconds to ensure that no two calls to "gettimeofday()" return the
same value unless you reset the clock). 

NTP's probably good enough for most purposes (and I suspect anybody who
needs more may well be best advised not to use UNIX, or at least not to
use most versions of UNIX) but, as I said, I'm a bit fussy here (having
worked on Suns not running NTP in the past, where it's a matter of being
off by seconds or even minutes, not milliseconds or microseconds :-)).
From: rrybacki@ringer.cs.utsa.edu (Richard M. Rybacki)
Newsgroups: comp.unix.programmer
Subject: Re: Which pipe sent SIGPIPE w/o trying to write to it??
Date: 10 Apr 92 14:06:11 GMT
Organization: University of Texas at San Antonio

In article <92100.170337PJS100T@ODUVM.BITNET> PJS100T@ODUVM.BITNET (Pam Skillman) writes:
>Here's the situation:  I've got several pipes to several different processes
>and I receive a SIGPIPE.  I don't want to try to write anything to each of
>these pipes as some of the processes are running tools and such and I don't
>want anything I send interpreted by them.  Is there a way to do this??  A
>type of polling without having to write??  Thanks in advance!!
>
>Pam Skillman
>Old Dominion University
>Computer Services
>Technical Support Group

A socket which has been closed at the remote end will be make ready to
read on the local end, and the read will return a count of zero bytes.
After receiving the SIGPIPE, you could do a select so see which fds are
ready to read from.  Those which have zero bytes have been closed at the
remote end.  For each fd retunred by select, you could do something like:

	if (ioctl(fd, FIONREAD, &bytes) == -1 || bytes == 0)
		...

-- 
Richard M. Rybacki                |     Happiness = Reality - Expectations
rrybacki@ringer.cs.utsa.edu       |     -- Click & Clack, The Tappet Brothers
From: sium@syma.sussex.ac.uk (Siu Mak)
Newsgroups: comp.unix.programmer
Subject: Re: recursively moving to directories
Date: 13 Apr 92 19:29:07 GMT
Organization: University of Sussex at Brighton

Do find a new one !
If you do it in the shell, it is a bit of time wasting.
But if you want to practice programming, do think a little bit more.
It is really easy !
It is similar to recursively deleting backup files in directories.
Xref: sparky comp.unix.programmer:2256 comp.unix.admin:2709
From: l1ngo@copper.denver.colorado.edu (Swift)
Newsgroups: comp.unix.programmer,comp.unix.admin
Subject: logging outgoing telnet sessions to catch 'hackers'
Date: 6 Apr 92 23:38:14 GMT
Followup-To: comp.unix.programmer
Organization: University of Colorado at Denver

We're running Dynix on a Sequent S81 and are considering methods of
logging outgoing telnet sessions. We can log which sites connect to
ours (by putting tcp_wrapper between inetd and the server daemons), but
we're trying to determine the best way to log users connections
to other hosts. Frequently, another site might report incidences of
possible hacking from our site and we'd like to know who's doing it.

Some options I've considered:
0. Modifying the kernel. Not possible without the source.
1. Modifying telnet to log sessions. This can be easily circumvented by
 getting the source and recompiling though.
2. Monitoring output from 'netstat' and 'who'. This seems 'kludgy.'
3. Peeking into the kernel. I have very little experience with this and
 am not sure what method to use. I have heard of mmap(), but the manual
 pages are insufficient. Does anyone have an example or a reference?

Thanks in advance,
Lin
Newsgroups: comp.unix.programmer
From: kevin@cfctech.cfc.com (Kevin Darcy)
Subject: A Lesson to be Learned (was Re: How to do a filesystem link to a file of which I only have an fd?)
Organization: Chrysler Financial Corp., Southfield, MI
Date: Tue, 7 Apr 1992 21:19:11 GMT

---

From: federico@heinz.in-berlin.de (Federico Heinz)
Date: 2 Apr 92 13:27:37 GMT

"...there's this ``insanely great'' feature of the NeXT environment that 
 allows mapping a file into memory, which would greatly reduce the complexity 
 of my code. The caveat: I must have the file's name in order to map it, but 
 I don't know the name.

"No sweat, I think: just use fstat() to get the file's inode number, and ask  
 the file system to make a link to it under a name I like (let's assume I know  
 is on the same device), and voila, there's a file I can map... only I haven't  
 found any way to set up a link to a particular inode..."

---

From: jfw@ksr.com (John F. Woods)
Date: 2 Apr 92 21:20:37 GMT

"The answer is that you cannot do this (in general)."

---

From: byer@adobe.com (Scott Byer)
Date: 3 Apr 92 00:16:24 GMT

"Search the NextDev docs for map_fd:

"#include <mach.h>

"kern_return_t map_fd(int fd, vm_offset_t offset, vm_offset_t *address,  
 boolean_t find_space, vm_size_t size)"

---

From: jml@taco.visus.com (Jim Large)
Date: 4 Apr 92 01:37:17 GMT

"Fire up DigitalLibrarian and search the NeXT Developer docs for "map_fd".
 It does exactly what you want."

--

Moral of the story: us Unix generalists shouldn't make hasty assumptions 
about SPECIFIC implementations of modern Unix and Unix-like OSes. The 
environments out there today are richer and more developer-friendly than they 
were say 5 or 10 years ago. Live and learn...

								- Kevin
From: shandon@cats.ucsc.edu (Timothy Daniel Kolar)
Newsgroups: comp.unix.programmer
Subject: Re: ethics of logging telnet destinations (was Re: logging outgoing...)
Date: 15 Apr 92 20:11:54 GMT
Organization: University of California, Santa Cruz

In article <1992Apr15.190205.2111@ircam.fr>, francis@ircam.fr (Joseph Francis) writes:

|> The long-distance carrier companies log all long-distance calls, and
|> your local calls are logged locally, for purposes of accounting. For
|> purposes of criminal investigation the records may be subpoenaed; this
|> doesn't mean that the records are as a matter of course handed over to
|> the police, or that they were originally created for this purpose.

I don't believe anyone suggested that the logs would be looked at, or
handed over to anyone, until a problem existed.  The original purpose
of the phone logs is irrelevant--if the phone company suddenly decides
to stop charging, I will lay you very good odds that the accounting
will stay installed.  (I would also question if monetary accounting
was all they had in mind in the first place, but that's a whole other
bag of worms)

|> I don't envision many "problems" with outbound telnets that must
|> be monitored.

I think this may be the heart of the disagreement.  There is a 
sizeable problem with outbound net connections: to put it bluntly,
why would anyone risk breaking into a local system, when they can
make anonymous attacks on systems across the net?

This leads to the reasonable idea that you only start tracking telnets
when someone at another site reports an attack from your site.  However,
if you trust your system administrator (and you had better) then having
logs that aren't looked at until a problem arises is about the same thing.

|> Also, the safety of user's data is most easily secured with backups...

	Safety also entails protecting the information from 
unauthorized access (ironically, backups make that harder instead of
easier).  

-Tim Kolar
(speaking for himself)
Newsgroups: comp.unix.programmer
From: Ray.Nickson@comp.vuw.ac.nz (Ray Nickson)
Subject: Re: Dynamic loading under MORE/bsd
Organization: Victoria University of Wellington, Wellington, New Zealand
Distribution: comp
Date: Thu, 9 Apr 1992 21:48:39 GMT

In article <1992Apr9.104924.5834@cs.tu-berlin.de> net@cs.tu-berlin.de (Oliver Laumann) writes:

   I'm not sure if this solves your problem [...] 
   [Y]our program's `break' gets altered between the sbrk(0) and the
   call to the linker. [...]

You've identified a problem, but not mine.  I confess I was very lazy
in posting this fragment --- thank you for pointing it out.  The
_real_ code (which isn't mine) doesn't do the naughty things I did,
and still fails.  Here's a `corrected' tryld, which succeeds and fails
in the same way as the other.  I've added assert()s to check that the
break hasn't been moved and that the system calls don't fail.

#include <stdio.h>
#include <a.out.h>
#include <assert.h>
#include <sys/file.h>
#include <sys/types.h>

extern char *sbrk(int);

int 
main (int argc, char *argv[])
{
  char *codeptr, *codeptr1;
  char cmd[1024];
  int od, status, cc;
  struct exec header;
  int size;
  int (*funcp)();
  
  codeptr = sbrk(0);
  assert (codeptr != (char *)-1);
  
  sprintf (cmd, "ld -N -A %s -e %s -T %lx -o ext.o %s", 
           argv[0], argv[2], codeptr, argv[1]);
  status = system (cmd);
  assert (status == 0);
  
  od = open ("ext.o", O_RDONLY);
  assert (od != -1);
  
  cc = read (od, &header, sizeof(header));
  assert (cc == sizeof(header));
  
  size = header.a_text;
  funcp = (int(*)())(header.a_entry);
  
  codeptr1 = sbrk (size);
  assert (codeptr == codeptr1);

  status = lseek (od, N_TXTOFF(header), L_SET);
  assert (status != -1);
  
  cc = read (od, codeptr, size);
  assert (cc == size);
  
  close (od);

#ifdef HACKIT
  sleep (1);
#endif

  printf ("got %d\n", (*funcp)());
}
Newsgroups: comp.unix.programmer,comp.lang.c,comp.std.c
From: jik@athena.mit.edu (Jonathan I. Kamens)
Subject: Re: Re : non-blocking accept()
Organization: Massachusetts Institute of Technology
Date: Fri, 10 Apr 1992 13:43:51 GMT

In article <92100.172140PJS100T@ODUVM.BITNET> PJS100T@ODUVM.BITNET (Pam Skillman) writes:

   Another alternative provided in 4.3BSD is the select system call.  This is
   the preferred method (I believe).

I do not see why it would be classified as the "preferred" method.  If
you wish to write your program in a way that makes select() the best
tool for the job, then you can use select().  If, on the other hand,
you wish to write the program in a way that makes it more appropriate
to use non-blocking I/O on the server socket and pay attention to
EWOULDBLOCK, then you can do that.  Neither is "preferred," and each
is more appropriate in some situations.

In any case, what you neglected to mention in your posting is that if
a programmer DOES want to use select(2) to determine if a server
socket has a pending connection ready to be accept(2)ed, then he/she
should select the socket for read, and select will indicate that it is
ready to be read if there are pending connections.

-- 
Jonathan Kamens						jik@MIT.Edu
MIT Information Systems/Athena		    Moderator, news.answers
    (Send correspondence related to the news.answers newsgroup
	{and ONLY correspondence related to the newsgroup}
		 to news-answers-request@MIT.Edu.)
Newsgroups: comp.unix.programmer,comp.lang.c
From: subbarao@phoenix.Princeton.EDU (Kartik Subbarao)
Newsgroups: comp.unix.programmer
Subject: Re: a pipe problem
Date: 13 Apr 92 22:44:59 GMT
Organization: putchar('I'); for (i = 0; i < 3; i++) putchar('E');

In article <1992Apr13.005506.16138@daimi.aau.dk> pjunold@daimi.aau.dk (Peter Joachim Unold) writes:
>I have a program that starts a process A which sends data to it's child B by
>a pipe. Process A reads it's input from filedescriptor 0. However sometimes
>I want Process B to send data to it's parrent A. It's important that this data
>also should be be read from the same fd as used for stdin. Here's how it looks:
>
>what I'm really trying to do is to make a pipe that looks like:
>
>keyboard->--|
>            ------->-----parent 
>child---->--|
>
>Is this possible at all? I've tried various variants of pipe, close and dup
>without finding a solution. I hope someone can help me out of this one.

It's not as "easy" as you might like. Writing to file descriptor 0 does not 
write to the "read" end of the terminal. To simulate keyboard input, you
have to use something like the TIOCSTI ioctl(). But that's a kludge. I'd
rather explain a cleaner way to do it right from your diagram.

What you want to do is to have the parent be able to read from 2 different
file descriptors: 0, and the read end of a pipe that the child writes to.

To simplify things, instead of making 2 pipes, one that the parent writes
to and the child reads from, and another that the child writes to and the
parent reads from, let's simply create a socketpair. socketpair() gives us
2 connected sockets that can be either written to or read from. If I write
to s[0], I can read what I just wrote in s[1]. Likewise, if I wrote to
s[1], I can read what I just wrote in s[0].

Now, the picture is like this:

keyboard----->[parent]<------------->[child]
                         socketpair 

At any time, the parent could get input from either the keyboard or the
socketpair. We need to use select() to multiplex between the two. 

Here's some sample code that does this, with no error checking:

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

main()
{
	int n, s[2], maxfds;
	fd_set fdset;
	char buf[1024];

	maxfds = getdtablesize();	 
	socketpair(PF_UNIX, SOCK_STREAM, 0, s);
	FD_ZERO(&fdset); /* initialize the set to be empty */
	
	if (! fork()) { /* child */
		sleep(2);	
		write(s[1], "foo\n", 4); sleep(2);
		write(s[1], "zoof\n", 5); sleep(3);
		write(s[1], "test\n", 5);
		exit(0);
	}

	while (1) {
		FD_SET(0, &fdset); FD_SET(s[0], &fdset);
		/* set the file descriptors that we want to check */
		
		select(maxfds, &fdset, NULL, NULL, NULL);
	
		if (FD_ISSET(0, &fdset)) { /* something from tty */
			n = read(0, buf, sizeof buf);
			write(1, buf, n);
		}	
		if (FD_ISSET(s[0], &fdset)) { /* something from socket */
			n = read(s[0], buf, sizeof buf);
			write(1, buf, n);
		}
	}
}
Xref: sparky comp.unix.programmer:2269 comp.unix.internals:1073
From: wayne@jahangir.UUCP (wayne)
Newsgroups: comp.unix.programmer,comp.unix.internals
Subject: Broadcast, how?
Keywords: UDP Broadcast?
Date: 7 Apr 92 19:51:34 GMT
Followup-To: poster
Organization: MDC, NYC



     I am confused as to how to get a server to
broadcast to n clients useing UDP. I would 
greatly appreciate it if anyone could
provide me with a code fragment for doing this.




    Thanks 

    -- Wayne
From: jik@athena.mit.edu (Jonathan I. Kamens)
Newsgroups: comp.unix.programmer
Subject: Re: non-blocking accept()
Date: 9 Apr 92 22:49:44 GMT
	<1992Apr9.173021.12838@Princeton.EDU>
Organization: Massachusetts Institute of Technology

In article <1992Apr9.173021.12838@Princeton.EDU> subbarao@phoenix.Princeton.EDU (Kartik Subbarao) writes:

   Use fcntl on the socket. 

	   fcntl(s, F_SETFL, FNDELAY);

No.  This blows away any flags that were already set on the socket.
You have to get the flags, OR in FNDELAY, and set the flags to the
result.  See the example I already posted today.

-- 
Jonathan Kamens						jik@MIT.Edu
MIT Information Systems/Athena		    Moderator, news.answers
    (Send correspondence related to the news.answers newsgroup
	{and ONLY correspondence related to the newsgroup}
		 to news-answers-request@MIT.Edu.)
Xref: sparky comp.unix.programmer:2368 comp.admin.policy:727
From: chip@eniac.seas.upenn.edu (Charles H. Buchholtz)
Newsgroups: comp.unix.programmer,comp.admin.policy
Subject: Re: logging outgoing telnet sessions to catch 'hackers' (summary)
Date: 14 Apr 92 14:13:21 GMT
Followup-To: comp.admin.policy
Organization: University of Pennsylvania

Followups sent to comp.admin.policy; this is no longer a Unix
programming issue.  I hope I left in enough context for new people.

spm2d@topaz.cs.Virginia.EDU (Steven P. Miale) writes:
>l1ngo@copper.denver.colorado.edu (Swift) writes:
>>Let me clarify this. I only intended to log which hosts a user connects to.
>>Usually, this is all that's needed to find a hacker (at the very least, it
>>narrows down the list of "suspects").
>
>I don't believe that is any of your business. Where someone telnets to,
>who they send mail to, etc., should not be logged. Your plan sounds
>an awful lot like "Big Brother" to me.

We log sendmail, rlogin, and telnet connections, but I don't know who
my users send mail to, etc.  I don't look in those logs for the same
reason that I don't look through people's home directories or read
their mail.  Yes, I have the root password, yes I *could* invade
people's privacy, but I'm a professional and I don't.  If you don't
trust the people with root to respect your privacy (or at least to
respect the policies of your site concerning privacy), then fire your
SysAdmin and get one that you can trust.

We do use those logs.  For instance, when I get a message from a
SysAdmin from another site who says, "someone cracked an account on
our machine last night, they logged in to foobar.cc.bigschool.edu as
fnord at 1:26AM", I can grep through the logs and determine which
account on my machine was used.

By using grep and awk on these log files, I can get the information I
need to "protect and serve" my customers, with minimal invasion of
their privacy.  My job is to provide the services that my customers
want, and most of them want their accounts to be secure.


Charles H. Buchholtz       Systems Programmer     chip@seas.upenn.edu
	      School of Engineering and Applied Science
		      University of Pennsylvania
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.programmer
Subject: Re: non-blocking hostname resolving
Date: 14 Apr 1992 05:28:57 GMT
Organization: Thinking Machines Corporation, Cambridge MA, USA
NNTP-Posting-Host: gandalf.think.com

In article <1992Apr13.200730.10483@ux1.cso.uiuc.edu> phil@ux1.cso.uiuc.edu (Phil Howard) writes:
>Does anyone have any code, or can point me to any, which can be integrated
>into a program to allow doing a non-blocking hostname resolve so that other
>activities can continue even if the DNS lookup is taking some time?

Fork a subprocess that calls gethostbyname() and use some interprocess
communication mechanism to send the resulting address back to the original
process.

If you have threads, that would be even better than a subprocess.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar
Newsgroups: comp.unix.programmer
From: fyl@ssc.wa.com (Phil Hughes)
Newsgroups: comp.unix.programmer
Subject: Re: Korn Shell
Date: 14 Apr 92 20:53:09 GMT
Organization: SSC, Inc., Seattle, WA

In article <1992Apr08.123522.6876@bcsl.uucp> newman@bcsl.uucp (Robert Newman  Programmer) writes:

>Could anyone direct me in the direction of locating some books or
>documentation on programming within the Korn shell.

The classic book is _The Kornshell Command and Programming Language_ by
Morris Bolsky and David Korn (Prentice Hall, 1989).

SSC has a reference card out on the Korn Shell.  This is a 20-sided fan
fold card.

>Is it the same as the csh shell?

Not at all.  Think of it as the Bourne Shell with a cleanup and then with
the functionality of C-shell history.  Command-wise it is upward
compatible with the Bourne Shell.  History is quite different from C-shell
and allows in-line editing in either an emacs-like or vi-like mode.  Quite
nice and easier to use than C-shell once you get used to it.

-- 
Phil Hughes, SSC, Inc. P.O. Box 55549, Seattle, WA 98155  (206)FOR-UNIX
     uunet!nwnexus!ssc!fyl or fyl@ssc.wa.com            (206)527-3385
Newsgroups: comp.unix.programmer