Linux-Development-Apps Digest #413, Volume #7 Thu, 17 May 01 22:13:12 EDT
Contents:
Re: Obtaining the full path name of a file? (Timur Tabi)
Re: SIGSEGV is not blocking (Steve Kirkendall)
Re: A linuxthreads C++ object question (Daniel Barron)
Re: A linuxthreads C++ object question (David Konerding)
help: getting headers working (David. E. Goble)
Re: A linuxthreads C++ object question ("Neil Butterworth")
Re: A linuxthreads C++ object question ("Neil Butterworth")
Re: Obtaining the full path name of a file? (Robert Nichols)
Re: A linuxthreads C++ object question (Kaz Kylheku)
Re: A linuxthreads C++ object question (Kaz Kylheku)
Re: Obtaining the full path name of a file? (Troy Loveday)
Re: A linuxthreads C++ object question (Kaz Kylheku)
Re: sleep() and gtk_label_set_text() (Greg Copeland)
Re: A linuxthreads C++ object question ("Neil Butterworth")
Re: socket() problem (Greg Copeland)
----------------------------------------------------------------------------
From: Timur Tabi <[EMAIL PROTECTED]>
Subject: Re: Obtaining the full path name of a file?
Date: Thu, 17 May 2001 18:26:20 -0500
Juergen Heinzl wrote:
>
> Yup, okay, then dirname(3) would give you the path and you'd
> follow the directory and once there getcwd() is going to do
> the job, easy.
I can't find dirname anywhere. "man 3 dirname" gives me an error, and a
search in /usr/include for "dirname" turns up nothing meaningful.
--
Timur Tabi
Remove "nospam_" from email address before sending reply
Interactive Silicon - http://www.interactivesi.com
------------------------------
From: Steve Kirkendall <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Crossposted-To: comp.os.linux.development.system,comp.programming.threads
Subject: Re: SIGSEGV is not blocking
Date: Thu, 17 May 2001 16:50:44 -0700
"Michael J. Saletnik" wrote:
>
> David Schwartz <[EMAIL PROTECTED]> writes:
>
> > You say it ought to "work". What do you mean? What behavior would
> > constitute working? You have left no reasonable thing for the
> > implementation to do.
>
> If I explicitly block the SIGSEGV from being delivered, I would not
> expect the process still to terminate on a SIGSEGV.
As I understand it, "blocking" only means you can't get one SIGSEGV
while executing the handler function for an earlier SIGSEGV. Outside
of the handler function, the signal can still arrive.
Try a plain old "signal(SIGSEGV, SIG_IGN)" call instead. You'll still
have the issue of undefined behavior after ignoring a segmentation
violation, but at least it'll still be doing... something.
------------------------------
From: Daniel Barron <[EMAIL PROTECTED]>
Subject: Re: A linuxthreads C++ object question
Date: Fri, 18 May 2001 00:18:34 +0100
In message <[EMAIL PROTECTED]>
"Neil Butterworth" <[EMAIL PROTECTED]> wrote:
[snip]
>
> Any given object can only be created by one thread, and you can't pass a
> reference or pointer to it off to another thread until all constructors
> have completed (unless you are mad enough to spin off threads in a
> constructor) - so there is no contention.
But if I'm not passing it or a reference to it to another thread, then there
is no problem creating two objects of the same type at the same time in two
threads as long as the object type does not include static-data?
> >
> > lock objectmutex;
> > object myobject;
> > unlock objectmutex;
> >
> > Talk about asking for deadlock! Is this really true? I can't believe its
> > sooo ficle or messy!
>
> No, it isn't, except in pathological situations.
Isn't what? True or asking for deadlock?
>
> NeilB
>
>
>
>
>
--
Daniel Barron - use [at jadeb.com] for personal replys.
------------------------------
From: [EMAIL PROTECTED] (David Konerding)
Subject: Re: A linuxthreads C++ object question
Date: 17 May 2001 23:13:01 GMT
Reply-To: [EMAIL PROTECTED]
On Thu, 17 May 2001 20:15:11 +0100, Neil Butterworth <[EMAIL PROTECTED]>
wrote:
>> > then you
>> >> can happily use all the standard library objects and methods on those
>> > objects
>> >> from multiple threads simultaneously with no fear of race conditions.
>> > Internally
>> >> these libraries protect access to volatile variables and code regions
>> >> using locks, mutexes, and semaphoes (typically just mutexs).
>> >
>> > I am not aware of _any_ STL implementation that guarantees this degree
> of
>> > thread-safety. Certainly, none of these do:
>> >
>> > STLport
>>
>> STLport-4.1b6 does. At least, a cursory grep of the software shows many
> header and code
>> files use mutexes to protect critical sections.
>
> The following is taken from the STL website describing thread-safety:
>
><quote>
> - simultaneous read access to the same container from within separate
> threads is safe;
> - simultaneous access to distinct containers (not shared between threads) is
> safe;
> - user must provide synchronization for all accesses if any thread may
> modify shared container.
> </quote>
>
> This shows that STLport does _not_ provide the level of safety that you
> claim it does.
Right. The above behavior of STLport is due to its use of the SGI STL library
and only then when you use shared containers. What I meant was that the base
standard libray (strings, streams, streambufs, etc) are protected in STLport.
I would have thought the STL components to be as well, but apparently they aren't.
I don't use the model of sharing containers between threads. I'm pretty certain
that the user can use all the standard library except for STL without worrying--
if that's not true, then I've got to get rid of a certain basic assumption I'm making.
I certainly would not want to have to do a lock or mutex around every string I
construct
or stream I access.
Dave
------------------------------
From: goble@gtech (David. E. Goble)
Crossposted-To: alt.linux,aus.computers.linux,comp.os.linux.setup
Subject: help: getting headers working
Date: Fri, 18 May 2001 00:17:22 GMT
Reply-To: goble@gtech
Hi All;
I hope some one can help me :< I have redhat 6.2 server installed.
I have tried to use gcc to write some programs in C. I managed to get
a simple hello world program to compile and run. But its giving me
problems with "external"(?) headers.
ie;
Tried to compile testlibpq.cc from the postgresql docs.
Gcc gives the following error;
testlibpq.cc:8:libpq-fe.h No such file or directory
When I change testlibpq.cc with;
#include "/usr/include/pgsql/libpq-fe.h"
Gcc produces;
testlibpq.cc:In function 'int main()':
testlibpq.cc:98:'IT' undeclared (first use this function)
testlibpq.cc:98:(each undeclared identifier is reported only once
testlibpq.cc:98:for each function it apppears in.)
testlibpq.cc:98:prase error before ';'
testlibpq.cc:103:confused by earlier errors, bailing out
My .bash_profile has the lines
PATH=$PATH:$HOME/bin:/usr/include/:/usr/include/pqsql/
export PATH
------------------------------
From: "Neil Butterworth" <[EMAIL PROTECTED]>
Subject: Re: A linuxthreads C++ object question
Date: Fri, 18 May 2001 01:24:27 +0100
"Daniel Barron" <[EMAIL PROTECTED]> wrote
in message news:[EMAIL PROTECTED]...
> In message <[EMAIL PROTECTED]>
> "Neil Butterworth" <[EMAIL PROTECTED]> wrote:
> [snip]
> >
> > Any given object can only be created by one thread, and you can't pass a
> > reference or pointer to it off to another thread until all constructors
> > have completed (unless you are mad enough to spin off threads in a
> > constructor) - so there is no contention.
>
> But if I'm not passing it or a reference to it to another thread, then
there
> is no problem creating two objects of the same type at the same time in
two
> threads as long as the object type does not include static-data?
Correct. Even if they did share static data, you would only have a problem
if you depended on it during construction, which I must admit is a fairly
common idiom :-(
NeilB
------------------------------
From: "Neil Butterworth" <[EMAIL PROTECTED]>
Subject: Re: A linuxthreads C++ object question
Date: Fri, 18 May 2001 01:33:14 +0100
"David Konerding" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 17 May 2001 20:15:11 +0100, Neil Butterworth
<[EMAIL PROTECTED]> wrote:
> >> > then you
> >> >> can happily use all the standard library objects and methods on
those
> >> > objects
> >> >> from multiple threads simultaneously with no fear of race
conditions.
> >> > Internally
> >> >> these libraries protect access to volatile variables and code
regions
> >> >> using locks, mutexes, and semaphoes (typically just mutexs).
> >> >
> >> > I am not aware of _any_ STL implementation that guarantees this
degree
> > of
> >> > thread-safety. Certainly, none of these do:
> >> >
> >> > STLport
> >>
> >> STLport-4.1b6 does. At least, a cursory grep of the software shows
many
> > header and code
> >> files use mutexes to protect critical sections.
> >
> > The following is taken from the STL website describing thread-safety:
> >
> ><quote>
> > - simultaneous read access to the same container from within separate
> > threads is safe;
> > - simultaneous access to distinct containers (not shared between
threads) is
> > safe;
> > - user must provide synchronization for all accesses if any thread may
> > modify shared container.
> > </quote>
> >
> > This shows that STLport does _not_ provide the level of safety that you
> > claim it does.
>
> Right. The above behavior of STLport is due to its use of the SGI STL
library
> and only then when you use shared containers.
You mean the stream library?
> What I meant was that the base
> standard libray (strings, streams, streambufs, etc) are protected in
STLport.
Not in the way you seem to think they are. See the SGI site for their thread
safety guarantee, which is more or less identical to the abreviated STLport
version I posted.
> I would have thought the STL components to be as well, but apparently they
aren't.
> I don't use the model of sharing containers between threads.
But this is very common. Having an input queue which multiple service
threads access is the way that almost all server apps are written. And if
you have such a an architecture, you need to protect the queue with some
sort of lock.
> I'm pretty certain
> that the user can use all the standard library except for STL without
worrying--
> if that's not true, then I've got to get rid of a certain basic assumption
I'm making.
Yes, you do. The guarantee I posted (basically, if a container is modified
in any way by a method, that method cannot be called safely ON THE SAME
OBJECT from multiple threads) is common to all Standard C++ Library
implementations that I'm aware of.
> I certainly would not want to have to do a lock or mutex around every
string I construct
> or stream I access.
But you don't! That's not what I or the library suppliers are saying at all.
Read the STLport guarantee again. It doesn't mention construction at all.
OTOH, if you have multiple threads accessing the same stream, then you _do_
have a potential problem.
NeilB
------------------------------
From: [EMAIL PROTECTED] (Robert Nichols)
Subject: Re: Obtaining the full path name of a file?
Date: Fri, 18 May 2001 00:45:28 GMT
In article <[EMAIL PROTECTED]>,
Timur Tabi <[EMAIL PROTECTED]> wrote:
:I have an application that takes a list of filenames on the
:command-line. How do I expand these filenames into their full path
:name?
:
:For example, assume the current directory is /usr/local/bin. Then,
:
:ssh -> /usr/local/bin/ssh
:../man/whatis -> /usr/local/man/whatis
:/boot/vmlinux -> /boot/vmlinux
:../../boot/vmlinunx -> /boot/vmlinux
:
:I need to do this from C.
AFAIK there is no standard function that does the whole job for you.
You start by prepending the result from getcwd(3) and a "/" character to
any argument that does not begin with "/". That's enough to give you a
valid path unless you are current deep enough in a directory tree to run
into problems with maximum path length.** If you want to get rid of any
embedded "../" elements you'll have to do that processing yourself.
**Yes, it's possible to have a file for which the pathname beginning
from "/" is too long to be valid. Such a file can only be referenced
from an intermediate CWD.
--
Bob Nichols [EMAIL PROTECTED]
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: A linuxthreads C++ object question
Reply-To: [EMAIL PROTECTED]
Date: Fri, 18 May 2001 01:31:16 GMT
On Thu, 17 May 2001 21:31:03 +0100, Daniel Barron
<[EMAIL PROTECTED]> wrote:
>In message <[EMAIL PROTECTED]>
> [EMAIL PROTECTED] (Kaz Kylheku) wrote:
>[snip]
>> that some kinds of C++ objects contain data which are not directly visible
>> to the programmer, such as vtable pointers, type informations and so on.
>> Such fields are set up as an object is constructed. The best rule to follow
>> is to avoid accessing an object from multiple threads until it is fully
>> constructed, and after just before its destruction has begun. This
>> rule is required because there is no satisfactory way to protect this
>> invisible data against concurrent access, other than total abstinence.
>
>But this is utterly ludicrus! Multithreaded apps must have loads and loads
>of mutexes for every object creation:
>
>lock objectmutex;
>object myobject;
>unlock objectmutex;
This mutex is useless, because (presumably) this occurs in a statement
block, and so the object is created in automatic storage. Since each
thread has its own automatic storage, the object isn't shared.
However, you do need some exclusion mechanism for block scope static
objects in C++, e.g:
{
static myclass obj;
}
The code generated by g++ uses a hidden flag which indicates whether the object
was constructed. The hidden flag is tested each time the block is executed and
if it is false, the object is constructed and the flag is set to true.
Normally, you don't have to worry about construction at all. Just don't
cause and object to be shared by threads until its constructor completes,
and make sure that no other thread is using it before destroying it.
This ensures that the internal setup and cleanup is performed by just one
thread.
>Talk >> of one object from multiple threads. Then, that object's non-static data
>> members must be properly guarded against concurrent access.
>
>object data is non-static by default right?
Unless you use the static keyword in the declaration of a member, it is
non-static. So each instance of the object has its own copy of that member.
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: A linuxthreads C++ object question
Reply-To: [EMAIL PROTECTED]
Date: Fri, 18 May 2001 01:36:22 GMT
On Thu, 17 May 2001 22:40:54 +0100, Neil Butterworth
<[EMAIL PROTECTED]> wrote:
>Any given object can only be created by one thread, and you can't pass a
>reference or pointer to it off to another thread until all constructors have
>completed (unless you are mad enough to spin off threads in a constructor) -
Of course you can pass a reference to another thread before the constructors
have completed! For example, the constructor could register that object into
some data structure, which is traversed by another thread to retrieve a pointer
to the object and use it. Oops.
This is a mistake which could easily arise in a naive implementation of the
Observer design pattern. Never allow an object's constructor to register it to
receive notifications which could occur before the object is fully constructed.
Some compilers have a helpful warning which can help you find such errors;
they can diagnose whenever the expression ``this'' appears in the body
of a constructor, or among the member initializers.
(I find that a little stringent, because I do in fact like to assemble
aggregates in constructors, just not let threads loose into those aggregates
until they are ready).
------------------------------
From: Troy Loveday <[EMAIL PROTECTED]>
Subject: Re: Obtaining the full path name of a file?
Date: 18 May 2001 01:18:41 GMT
Timur Tabi <[EMAIL PROTECTED]> wrote:
>I have an application that takes a list of filenames on the
>command-line. How do I expand these filenames into their full path
>name?
>For example, assume the current directory is /usr/local/bin. Then,
>ssh -> /usr/local/bin/ssh
>../man/whatis -> /usr/local/man/whatis
>/boot/vmlinux -> /boot/vmlinux
>../../boot/vmlinunx -> /boot/vmlinux
>I need to do this from C.
Since you asked in a Linux newsgroup, the Linux-specific answer is:
realpath(3)
--
Troy Loveday e-mail: <[EMAIL PROTECTED]>
ASIC Product Development / DTM vox: (214) 480-1497
Texas Instruments, Inc. fax: (214) 480-2356
Dallas, Texas "Don't Tread On Me!"
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: A linuxthreads C++ object question
Reply-To: [EMAIL PROTECTED]
Date: Fri, 18 May 2001 01:41:57 GMT
On Fri, 18 May 2001 00:18:34 +0100, Daniel Barron
<[EMAIL PROTECTED]> wrote:
>In message <[EMAIL PROTECTED]>
> "Neil Butterworth" <[EMAIL PROTECTED]> wrote:
>[snip]
>>
>> Any given object can only be created by one thread, and you can't pass a
>> reference or pointer to it off to another thread until all constructors
>> have completed (unless you are mad enough to spin off threads in a
>> constructor) - so there is no contention.
>
>But if I'm not passing it or a reference to it to another thread, then there
>is no problem creating two objects of the same type at the same time in two
>threads as long as the object type does not include static-data?
As long as none of the methods of that object access static data which can be
modified concurrently. (There is nothing wrong with accessing read-only static
data without protection).
If the methods operate only on that object instance, and no other data,
then it should be safe.
Of course, the C++ standard doesn't say anything about threads, so what
works and what does not is still up to your compiler ultimately.
There is a de facto safe subset of C++ for multithreading. It's not written
down anywhere, but it simply follows from understanding how typical compilers
do things.
The same applies to C.
An ISO conforming C compiler could implement the passing and returning of
structs using a static buffer. So a program using using these language
features would then not be thread safe. In fact some C compilers very long ago
did it this way when struct passing was first introduced into the language
(informally, by compiler writers).
However, experience with compilers tells us that it's not done this way,
and that nobody in their right mind would make a compiler like that if
it was intended for concurrent programming.
------------------------------
Subject: Re: sleep() and gtk_label_set_text()
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 17 May 2001 20:51:06 -0500
I'm not really a GTK guy, but the problem is rather obvious as it
is common to many event drive GUI toolkits. What happens is, when
you issue the label function, you've really requested it to be
drawn. It doesn't mean that it has been drawn. What would normally
happen is that once your callback function (dispatched event) has
completed, and the main gtk loop is running again, it would perform
the needed refreshes. This type of implementation is normally picked
because it is a great way to optimize screen changes, doing so in a
single refresh in many cases.
So, back to your problem. There are a couple of ways to do this. One
way is to find the refresh function and explicately call it prior to
hitting your sleep. While this may work, I think you'll find that it
has some odd side effects. First, if your application is sleeping
inside of a dispatched event, the idle loop is no longer running. This
means that should the screen need a refresh (say a region was dirtied)
for the period that it is sleeping, it would be unable to, however,
your basic desire would be addressed. The second, and I think more
correct way, is to create a timer callback and register the timer
function within your initial callback function. You'd also want to
track the status that the game is at an end. Then, when your timer
has expired, you can reset the end-game flag which means that they
are free to start a new game and you can erase your display as
needed. Of course, another and very simple option would be to
either use a status line to spit forth this info and/or create a
new dialog (which you many want to tie into the timer) which
presents the information to the user.
Hope this helps.
Enjoy,
Greg
Paul Oliver <[EMAIL PROTECTED]> writes:
> I'm using gtk to make a hangman game. When the user clicks the final
> letter, I want the game to show the word (using gtk_label_set_text)
> then pause long enough so that the user can read it. I thought I'd
> just call a sleep(1) afterwards to do this.
>
> However, it seems to sleep before the word is changed, no matter where
> I put it. For example:
>
> ... guess several letters, now one is left before word is solved
> 1. click on letter
> 2. game sleeps for 1 second
> 3. button depresses, label changes.
>
> I'm guessing this has to do with the pipeline and threads or something,
> but I'm just not sure how to approach the problem. Any pointers? My
> code for the function that shows the hangman word is below.
>
> Thanks!
>
> void setShownWord(gchar* word) {
> gchar newWord[MAXWORDLEN * 2] = "";
> gint cnt;
>
> /* stretch out and capitalize */
> for (cnt=0; cnt<strlen(word); cnt++) {
> newWord[cnt*2] = toupper(word[cnt]);
> newWord[(cnt * 2) +1] = ' ';
> }
> /* end the word */
> newWord[strlen(word)*2] = '\0';
>
> g_print("\nSetting the shown word");
> gtk_label_set_text (pc.lblWord, newWord);
> g_print("\nJust set the shown word");
> sleep(1);
>
> }
>
>
> --
> ==========================================================================
> Paul Oliver [EMAIL PROTECTED]
> http://www.paultastic.com
> ==========================================================================
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
From: "Neil Butterworth" <[EMAIL PROTECTED]>
Subject: Re: A linuxthreads C++ object question
Date: Fri, 18 May 2001 02:58:44 +0100
"Kaz Kylheku" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]...
> On Thu, 17 May 2001 22:40:54 +0100, Neil Butterworth
> <[EMAIL PROTECTED]> wrote:
> >Any given object can only be created by one thread, and you can't pass a
> >reference or pointer to it off to another thread until all constructors
have
> >completed (unless you are mad enough to spin off threads in a
constructor) -
>
> Of course you can pass a reference to another thread before the
constructors
> have completed! For example, the constructor could register that object
into
> some data structure, which is traversed by another thread to retrieve a
pointer
> to the object and use it. Oops.
Well, it shouldn't :-) I have to say I've never designed anything that does
something so stupid - a constructor should _not_ have knowledge of the
context it is being used in, any more than any C++ (or C function) should.
> This is a mistake which could easily arise in a naive implementation of
the
> Observer design pattern. Never allow an object's constructor to register
it to
> receive notifications which could occur before the object is fully
constructed.
> Some compilers have a helpful warning which can help you find such errors;
> they can diagnose whenever the expression ``this'' appears in the body
> of a constructor, or among the member initializers.
It would be naive, and it would be a problem. But we can't expect locking
mechanisms to protect us from being idiots!
NeilB
------------------------------
Subject: Re: socket() problem
From: Greg Copeland <[EMAIL PROTECTED]>
Date: 17 May 2001 21:06:56 -0500
This type of problem is very common. You've coded it, IMOHO, as if your
are expecting the stream to function like datagrams. Streams function like
streams and NOT datagrams. If you are using streams, you should ONLY do
on or more of the following:
o Include some type of message length indicator.
o Send *AND* receive *ONLY* fixed length messages; implicately (data
driven) or explicately (all messages are this size).
o Perform all reads using two variables. One to track how much you've
received and the second to track how much you received in the last
read. It's possible to get implied values depending on how you've
implemented, however, the method is the same. e.g.
while( totalRead < readSize ) {
lastRead = recv( s, &buffer[totalRead], ... ) ;
if( lastRead != -1 ) totalRead += lastRead ;
else {
// red alert!
}
}
Likewise, you'll loop until you get an error of the total amount that
you are expecting has been read. Once you hit your expected data
length, then you know you have a completed datagram. Likewise, you
also know for sure that your buffer stays in a known state at all
times, unless you've hit an error. At which time, you may still
be able to make some deterministic assumption depending on the error.
Enjoy,
Greg
"Ryan Pfenninger" <[EMAIL PROTECTED]> writes:
> I am having a problem reading from a server. I can write this using
> fsockopen() in PHP and it works perfectly, but when I write it in C the last
> bit of data that should be returned and printed to the screen gets cut off
> prematurely. I've been messing with the recv() and while() loop functions
> with no luck. The code im using is below: Any suggestions would be highly
> appreciated.
>
>
> #include<sys/socket.h>
> #include<sys/types.h>
> #include<netinet/in.h>
> #include<unistd.h>
> #include<stdlib.h>
> #include<stdio.h>
>
> main(int argc,char *argv[]) {
> int create_socket;
> int bufsize = 1024;
> char *buffer = malloc(bufsize);
> struct sockaddr_in address;
>
> printf("\x1B[2J");
>
> if ((create_socket = socket(AF_INET,SOCK_STREAM,0)) > 0) printf("The
> Socket was created\n");
>
> address.sin_family = AF_INET;
> address.sin_port = htons(6199);
> inet_pton(AF_INET,argv[1],&address.sin_addr);
>
> if (connect(create_socket,(struct sockaddr *)&address,sizeof(address)) ==
> 0)
> printf("The connection was accepted with the server
> %s...\n",inet_ntoa(address.sin_addr));
>
> printf("Message to send: ");
> fgets(buffer,256,stdin);
> send(create_socket, buffer, bufsize, 0);
>
> while (recv(create_socket, buffer, bufsize, 0) > 0) {
> printf("Message recieved: %s\n",buffer);
> }
>
> close(create_socket);
> }
>
>
--
Greg Copeland, Principal Consultant
Copeland Computer Consulting
==================================================
PGP/GPG Key at http://www.keyserver.net
DE5E 6F1D 0B51 6758 A5D7 7DFE D785 A386 BD11 4FCD
==================================================
------------------------------
** FOR YOUR REFERENCE **
The service address, to which questions about the list itself and requests
to be added to or deleted from it should be directed, is:
Internet: [EMAIL PROTECTED]
You can send mail to the entire list by posting to the
comp.os.linux.development.apps newsgroup.
Linux may be obtained via one of these FTP sites:
ftp.funet.fi pub/Linux
tsx-11.mit.edu pub/linux
sunsite.unc.edu pub/Linux
End of Linux-Development-Apps Digest
******************************
