Linux-Development-Apps Digest #461, Volume #7 Sat, 9 Jun 01 14:13:25 EDT
Contents:
Re: Matt Blaze's CFS on Linux - readdir problem. ("Binesh Bannerjee")
Need simple LINUX C/C++ serial port/socket application ("Greg Pace")
Re: stdout troubles (Juergen Heinzl)
Re: threads, signals and C++ class (Juergen Heinzl)
Re: Current alternatives to StarOffice? (Grant Edwards)
Re: Programming Tutorial (Victor Wagner)
Re: Help with lpr + apsfilter (Lew Pitcher)
Re: stdout troubles (Kaz Kylheku)
POSIX Realtime extensions (Shane D'Arcy)
Re: develop app for Gnome ("jacob navia")
----------------------------------------------------------------------------
From: "Binesh Bannerjee" <[EMAIL PROTECTED]>
Crossposted-To:
comp.os.linux.security,comp.os.linux.misc,comp.os.linux.development.system
Subject: Re: Matt Blaze's CFS on Linux - readdir problem.
Date: 8 Jun 2001 21:34:32 GMT
In comp.os.linux.security Kevin Buhr <[EMAIL PROTECTED]> wrote:
Thanks, this was most helpful... I unfortunately have the whole CFS
source all torn apart now, and have ripped through the code,
ANSIfied everything, and gotten it to compile without any warnings
now... (Well, maybe not really unfortunately)... I've made the changes
you said, when I finally run it, I guess we'll see what happens...
Have you done much with cattach -l ? Do you know how that works?
I noticed some interesting _other_ problems with cattach -l...
But, maybe it's just a more radical version of the same problem...
Basically, with cattach -l after I add enough directory entries,
the _entire_ directory becomes invisible... (There still there, just
ls or find, whatever won't find them, but you can cd to the directories,
vi files etc.)
Second question regards cfs_adm.c
The file defines
typedef struct svc_req *SR;
and later defines
cfsstat *admproc_attach_2(ap, rp)
cfs_attachargs *ap;
SR *rp;
while in admproto.h theres a declaration for
extern cfsstat * admproc_attach_2_svc(cfs_attachargs *, struct svc_req *);
(I understand that the _2 in the cfs_adm.c, and cfs_nfs.c need to be
changed to _2_svc because of Linux rpcgen...) But, is the definition
still wrong, because SR *rp effectively becomes struct svc_req **rp?)
Still plugging away, anyhow tho...
Binesh
: It's a kernel/C-library bug that's difficult to fix completely. The C
: library does some fancy double-buffering in getdents(2) and so must
: occassionally lseek on directories behind the scenes. When reading
: from NFS filesystems whose files have large (>0x8000000) NFS cookies,
: it will occassionally issue directory lseeks to negative offsets
: without checking for an error return value. This is highly dependent
: on internal C library buffer sizes, and will result in silently
: disappearing files that vary from application to application. For
: NFSv2, you can fix this particular problem by having the C library
: llseek in this situation; for NFSv3---where the cookies are 64 bits,
: it'll still be broken
: Note that this isn't normally a data-destroying bug---your files are
: still there; it's just that some applications won't "see" some files.
: "rm -rf" might give you a mysterious "directory not empty"; or after a
: "mv * elsewhere", you might be surprised to discover the current
: directory is still full of files that were missed on the first pass.
: There's more on this in a "linux-kernel" thread with subject:
: negative NFS cookies: bad C library or bad kernel?
: dated December 2, 2000.
: The easiest fix is to modify CFS to use small NFS cookies. CFS
: actually uses small host-endian cookies that, on little-endian
: architectures, become large cookies in NFS space. This isn't a CFS
: *bug*: cookies are supposed to be arbitrary. However, it just happens
: to tickle this Linux bug, and we can "fix" it by having CFS convert
: cookie values to network byte order.
: I've enclosed a patch against Debian CFS 1.3.3-9; it will apply
: against vanilla CFS 1.3.3 with some fuzz. Note that this modification
: won't introduce any compatibility problems with existing or new CFS
: directories---it only changes the values of the temporary cookies
: passed between the CFS server and the kernel, not anything to do with
: the CFS storage format. As always, test on a trash CFS directory
: before trying it on your pr0n collection or anti-government tract
: archive.
: Kevin <[EMAIL PROTECTED]>
: * * *
: diff -ru cfs-1.3.3/cfs_nfs.c cfs-1.3.3-new/cfs_nfs.c
: --- cfs-1.3.3/cfs_nfs.c Wed Jun 6 00:37:40 2001
: +++ cfs-1.3.3-new/cfs_nfs.c Wed Jun 6 00:34:34 2001
: @@ -873,7 +873,7 @@
: ne=0;
: prev= &ret.readdirres_u.reply.entries;
: *prev=NULL;
: - bcopy(ap->cookie,&cookie,sizeof(cookie));
: + cookie = ntohl(*(unsigned long*)(ap->cookie));
: eof=TRUE;
:
: key=keyof(h);
: @@ -910,7 +910,7 @@
: else if (strcmp(s,"..")==0) /* parent */
: entrytab[ne].fileid=fhpid(h);
: else entrytab[ne].fileid=dent->d_fileno;
: - bcopy(&cookie,entrytab[ne].cookie,sizeof(long));
: + *(unsigned long*)entrytab[ne].cookie = htonl(cookie);
: *prev = &entrytab[ne];
: prev = &entrytab[ne].nextentry;
: entrytab[ne].nextentry=NULL;
: @@ -1127,7 +1127,7 @@
: ne=0;
: prev= &ret.readdirres_u.reply.entries;
: *prev=NULL;
: - bcopy(ap->cookie,&cookie,sizeof(long));
: + cookie = ntohl(*(unsigned long*)(ap->cookie));
: eof=1;
:
: ret.status=NFS_OK;
: @@ -1146,7 +1146,7 @@
: else entrytab[ne].fileid=dent->d_fileno;
: cookie=dent->d_reclen; /* may not work everywhere */
: *prev = &entrytab[ne];
: - bcopy(&cookie,entrytab[ne].cookie,sizeof(long));
: + *(unsigned long*)entrytab[ne].cookie = htonl(cookie);
: prev = &entrytab[ne].nextentry;
: entrytab[ne].nextentry=NULL;
: ne++;
------------------------------
From: "Greg Pace" <[EMAIL PROTECTED]>
Subject: Need simple LINUX C/C++ serial port/socket application
Date: Fri, 08 Jun 2001 22:09:07 GMT
Need simple LINUX C/C++ serial port/socket application developed. I work
for NuVox Communications (Senior Director - Network Planning) and my IT
department is tied up. Anyone wishing to make a few bucks? Need quick
turnaround. Here is the app:
An SMDI (simplified message desk interface)ASYNC RS232 link between a voice
switch (DMS100) and a voice mail platform (Boston Communications) will be
routed/terminated via two (2) TTY ports on a LINUX PC. ASYNC data coming
from the switch (tty port 1) will simply be echoed to the voice mail
platform (tty port 2). I ask for a non-blocking read approach (return from
read immediately on receipt of each byte of data). Also this data path must
take priority. When data appears on tty port 1 it needs to be immediately
echoed to tty port 2. The converse flow is much less time sensitive. In
addition, when a preselected UNIX signal is received, the app will log all
data transactions to a file (overwrite not append). A subsequent receipt of
this UNIX signal stops the logging.
In the opposite direction, the data received from the voice mail platform
(tty port 2) must be analyzed before being passed. The message format will
be:
OP:MWI xxxxxxxxxx![CNTRL D]
or
RMV:MWI xxxxxxxxxx![CNTRL D]
where xxxxxxxxxx is a telephone number. The first 6 digits of the telephone
number must be compared to entries in a flat file (that can be loaded at
execution time into a MAP object or a linked list). The flat file will
contain two (2) fields per record. The first will be a six digit number
(compare to string) followed by an IP address. This list will be relatively
small (300 entries or less). If no match is found the data message from
port 2 will be echoed to port 1.
If a match results, the message needs to be sent to that IP address via a
socket connection. The device at the other end (8 possible IP addresses)
will be a like LINUX PC.
These 8 remote PCs will require simplified companion applications. Each of
these PCs will be connected to a single SMDI link from a remote DMS100. The
application will pull messages off the socket and echo them to the SMDI
terminated tty port.
I need to own the source, also.
Greg
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: stdout troubles
Date: Fri, 08 Jun 2001 22:32:07 GMT
In article <[EMAIL PROTECTED]>, Clifton T. Sharp Jr. wrote:
>On May 17 I wrote asking for help on a program I wrote that loses stdout
>after a SIGINT. I've made no progress since then.
>
>The other day I started troubleshooting leafnode, which hangs on occasion
>for no apparent reason. By adding printf() statements, I've determined
>it's hanging on an 'fflush(stdout)'; it executes the printf() preceding,
>but never the printf() following, that statement.
[-]
I´ve never had or heard about anything that would sound like your problem
and since this means lots of systems, kernels and hardware variations
it sounds to me like a bug. Either a common one in leafnode and your
application or one in one of the libraries both are using.
If you can reproduce it with leafnode, then try a ...
strace -f -o /tmp/output leafnode ...
... to start with to see what the last system calls are. I'd a problem
with just one application once after a libc upgrade and found finally
out it was a bug in just this libc release. Sometimes you are just
really really lucky 8-)
[-]
Ta',
Juergen
--
\ Real name : Juergen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: [EMAIL PROTECTED] (Juergen Heinzl)
Subject: Re: threads, signals and C++ class
Date: Fri, 08 Jun 2001 22:32:08 GMT
In article <[EMAIL PROTECTED]>, Etienne
Maitre wrote:
>Hello,
>I have a little (pure rethoric, in fact it's big) problem. Here is the point:
>I must have a class which should contain 2 methods:
[-]
Fine.
> - one must be a thread and run continously
[-]
Not so fine.
> - the other must be a signal handler called regularly by the main
[-]
Not so fine either.
>I create my instance, call the thread, everything work fine except that in my
>main, the signal SIGALRM is never received until the thread is finished!
>And for sure, the specs are: "MyEmbThread is implemented by a third party and
>can contain loops" meaning that I can't ask the "3rd party" to put sleeps every
>time...
>I tryed with LinuxThread and C++ Threads libs...same problem. And I can't
>multiply my sig handlers to embedded them in my class.
[-]
See some literature as the pretty much only safe way is to create
a thread that does nothing but waiting for signals. In addition C++
does know nothing about signals or threads, so there're more issues
to consider. I think your whole approach is bound to fail already,
sorry and in short ...
C++ + threads + signals == headache
...
[-]
Two bugs already. It must be declared as extern "C" and calling std::cout
in a signal handler is a big no no, too. Yes, it may work without using
extern "C" and no, it still was, is and will be wrong and I'm not going
to argue about it.
>void MyHandler(int iSig)
>{
> std::cout << "MyHandler" << std::endl;
> pYama->SigHandler();
>}
[-]
Juergen
--
\ Real name : Juergen Heinzl \ no flames /
\ EMail Private : [EMAIL PROTECTED] \ send money instead /
------------------------------
From: [EMAIL PROTECTED] (Grant Edwards)
Subject: Re: Current alternatives to StarOffice?
Date: Fri, 08 Jun 2001 22:58:56 GMT
On 7 Jun 2001 22:47:01 GMT, Larry Ebbitt <[EMAIL PROTECTED]> wrote:
>>> > Also, there once was a Linux-compatible office suite whose name
>>> > started with an A - I'm mind-cramping on it right now.
>>>
>>> Applixware. I use it and I'm pretty happy with it.
>>
>> How about a URL; it's obviously not
>> http://www.applix.com/flash.asp
www.applixware.com (redricts to) www.vistasource.com
>All I can think of is www.smartbeak.com, which is a support page.
>I'm sure it will get where you need to go.
I'm pretty sure there are links from www.linux.org et al.
--
Grant Edwards grante Yow! PEGGY FLEMMING is
at stealing BASKET BALLS to
visi.com feed the babies in VERMONT.
------------------------------
From: [EMAIL PROTECTED] (Victor Wagner)
Subject: Re: Programming Tutorial
Date: 8 Jun 2001 23:00:16 +0400
ThanhVu Nguyen <[EMAIL PROTECTED]> wrote:
: hi,
: I cam from a Windows programming (mfc) background and want to try
: programming in linx. It seems to me that tcl/tk is one of the most popular
It's rather wrong. It is one of easiest, yes. But most novice
programmers are scared away from it, becouse they want to program
on C/C++ and do not understand advantages of high-level scripting
languages as Tcl or Python, or even Perl (which is uglieset language
around sinse COBOL) which are best supported by Tk toolkit.
Note also that Tcl is language, and Tk is graphic toolkit
: one for X. Is there any online tutorial for it ? Or any good book
: recommendation ?
Book: Practical programming of Tcl/Tk by Brent Welch. Now third edition
is out.
Online resources: manual pages on your system. Either Tcl language
commands or Tcl/Tk API procedures have their own manual pages.
Most Linux distriburion install them as 3tcl or 3tk section, while when
you are building tcl from sources, they would be in l section.
See also comp.lang.tcl newsgroup. Original author of language, John
Ousterhout, as well as Brent Welch, Jeff Hobbs and the rest of current
development team hang around there.
When you first post question to this newsgroup, robot would reply
to you by E-Mail and send you bunch of useful URLs.
There is also a very lengthly Tcl FAQ which concerned primarily with
existing apps and libraries, and there is Tcl-Wiki which is interactive
site full of useful recipes.
One of main advantages of Tcl/Tk is that it is good crossplatform
solution. You can run same program on Unix, on Windows and on MacOS
without recompiling (becouse it is scripted). Up to 8.0 charset
conversion
was required, but now when all internal data representation is Unicode,
you can avoid it with some effort and run exactly same script on all
platforms sharing it via samba.
: thanks for all inputs
--
: How would you disambiguate these situations?
By shooting the person who did the latter.
-- Larry Wall in <[EMAIL PROTECTED]>
------------------------------
From: Lew Pitcher <[EMAIL PROTECTED]>
Subject: Re: Help with lpr + apsfilter
Date: Sat, 09 Jun 2001 05:44:04 GMT
Mayan wrote:
>
> I have recently installed lpr and apsfilter, but none of the word
> processors are able to print.
> NEdit for instance gives me the following error:
> "lpr: cannot access printcap"
Sounds like the /etc/printcap file isn't readable by lpr.
Run the
'ls -l /etc/printcap'
command and see what it's set up as.
Here's mine...
~ $ ls -l /etc/printcap
-rw-r--r-- 1 root root 1315 Mar 30 20:32 /etc/printcap
> Can someone help trouble shoot this problem? I am new to UN*X.
>
> I am using Debian 2.2 on a Intel machine.
>
> Thanks in advance.
--
Lew Pitcher
Master Codewright and JOAT-in-training
Registered Linux User #112576
------------------------------
From: [EMAIL PROTECTED] (Kaz Kylheku)
Subject: Re: stdout troubles
Reply-To: [EMAIL PROTECTED]
Date: Sat, 09 Jun 2001 07:30:56 GMT
On Fri, 08 Jun 2001 12:58:47 -0500, Clifton T. Sharp Jr. <[EMAIL PROTECTED]>
wrote:
>On May 17 I wrote asking for help on a program I wrote that loses stdout
>after a SIGINT. I've made no progress since then.
>
>The other day I started troubleshooting leafnode, which hangs on occasion
>for no apparent reason. By adding printf() statements, I've determined
>it's hanging on an 'fflush(stdout)'; it executes the printf() preceding,
>but never the printf() following, that statement.
You didn't do something undefined, like call stdio functions from a signal
handler?
If you suspect that it hangs in the kernel, did you try doing a system call
trace with strace? Did you try running the program in a debugger and then
break it and examine the call stack to see where it is stuck? What is the CPU
usage when the program is stuck?
------------------------------
From: [EMAIL PROTECTED] (Shane D'Arcy)
Subject: POSIX Realtime extensions
Date: Sat, 9 Jun 2001 14:50:03 +0000 (UTC)
Hi,
Can anyone explain how I can get the POSIX realtime extensions library
in full. I want to use named semaphores among other things, and the
sem_open() function fails with error ENOSYS, which as far as I know,
means that it is not implemented, but it is declared in the semaphore.h
header file. Do I have to rebuild the Kernel and set some flag to add
the extra functions to librt library?=3D20
Kind regards
Shane
--
Posted from [194.125.101.251]
via Mailgate.ORG Server - http://www.Mailgate.ORG
------------------------------
From: "jacob navia" <[EMAIL PROTECTED]>
Subject: Re: develop app for Gnome
Date: Sat, 9 Jun 2001 18:59:02 +0200
"Matthew Smith" <[EMAIL PROTECTED]> wrote in message
news:9foo6k$uk8$[EMAIL PROTECTED]...
> Anjuta was described in LXFmag (www.linuxformat.co.uk)
> as 'KDevelop for Gnome'
> anjuta.sourceforge.net
>
> quote from mag
> '. . lots of promise. . .interface could do with a little polish. .
> debugger has exceptional features'
Yes, a lot of promise, but nothing at all in terms of delivery. The "IDE"
doesn't have any feature that really makes for an integrated development
environment:
o makefile generation: none
o dependencies: none
o go to definition: no
It crashes constantly. The debugger is a joke, displaying (for instance)
random values for floating point numbers. The breakpoints arne't set at the
line you set them, and most of the time do not work, etc. Nothing works!
------------------------------
** 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
******************************
