gomd-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gomd-devel] <DAEMON> utils.cpp file: long-awaited bug-fix is committed


From: Gian Paolo Ghilardi
Subject: [gomd-devel] <DAEMON> utils.cpp file: long-awaited bug-fix is committed
Date: Mon, 29 Dec 2003 14:34:41 +0100

Hi all.

Just committed a long-awaited bug fix. ;)
Now the output of both local and remote command execution is clean!
Checkout the CVS NOTES below for more infos about this bug and the related
fix.

Byez.

<rejected>


<< CVS NOTES >>

IN utils.cpp
(f) now we check for "new line" and "carriage return" symbols in the read
data so we can add "complete lines" to the return string list.
(f) fix in execCommandAndGetChildOutput: finally I've found the way get the
_real_ output of a process (no dirty reads, no dirty buffer, ...)


THE BUG EXPLAINED
Example: execute "get [cmd/cwc] ls /usr" and then "get [cmd/cwc] ls /" in
sequence.

Problem: previous function version returned a dirty buffer. Usually "/usr"
contains more directories/files than "/" so when you execute the second
command you got some data from the output of the first command => buffer is
not reinitialized so the buffer is "dirty".

Fix: now this behaviour can happen _no more_ as I check only the read bytes
(so I can avoid to reinitialize the buffer: I know exactly where the last
char of the new data is so I can stop at the right point!)

Why: this happened as I thougth read() call returned only "complete lines"
(strings with "\r" and/or "\n" symbols at the end). Instead read() returns
every character: chars like "\r" and "\n" are not interpreted! They are
standard chars for read call! This call reads chars 'till the
max-number-of-read-chars threshold is reached.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]