I am writing a framework that other developers will write plug-ins
for.  I would like for one of the features of the framework to be to
intercept all text written to stdout/stderr and prepend timestamps on
each line.

I would like for this to work for all the printf-line functions
(fprintf, etc...) as well as C++ I/O streams (cout and cerr).

The key here is that I would like to get these timestamps on the lines
of text written to stdout/stderr without requiring any code
change/recompilation of the plug-ins.

Also, the target platform is linux.

Any ideas?  Thanks!

nobody@nowhere.com said:

> I am writing a framework that other developers will write plug-ins
> for.  I would like for one of the features of the framework to be to
> intercept all text written to stdout/stderr and prepend timestamps on
> each line.

Maybe you could just shove it through a pipe, something along these lines:

#include <stdio.h>
#include <time.h>

void printtime(FILE *fp)
{
  char thetime[32] = "Unknown time and date";
  time_t tt = time(NULL);
  struct tm *ptm = localtime(&tt);
  if(ptm != NULL)
  {
    strftime(thetime, sizeof thetime, "%Y/%m/%d %H:%M:%S | ", ptm);
  }
  fputs(thetime, fp);
}


int main(void)
{
  int ch = 0;
  int lookahead = 0;
  lookahead = getchar();
  if(lookahead != EOF)
  {
    printtime(stdout);
    ungetc(lookahead, stdin);
  }

  while((ch = getchar()) != EOF)
  {
    putchar(ch);

    if(ch == '\n')
    {
      lookahead = getchar();
      if(lookahead != EOF)
      {
        printtime(stdout);
        ungetc(lookahead, stdin);
      }
    }
  }
  return 0;
}


-- 
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

nobody@nowhere.com wrote:
>I am writing a framework that other developers will write plug-ins
>for.  I would like for one of the features of the framework to be to
>intercept all text written to stdout/stderr and prepend timestamps on
>each line.
>I would like for this to work for all the printf-line functions
>(fprintf, etc...) as well as C++ I/O streams (cout and cerr).
>The key here is that I would like to get these timestamps on the lines
>of text written to stdout/stderr without requiring any code
>change/recompilation of the plug-ins.
>Also, the target platform is linux.
>Any ideas?  Thanks!

This is a slow day, as proven by
 (1) Me having only five ideas so far, and
 (2) Nobody else jumping on the wagon to tell
     you that this is not doable in C / off
     topic in comp.lang.c, etc.

In any case, this is what I can think of:

(A) Do not do it, at least not that way. Choose
one of the several logging services / libraries
available for Linux, make it a *documented*
part of the framework and tell people to use it
instead of the standard output streams.

(B) Do not do it, at least not that way. Create
your own versions of printf & family (with
different names,) that will add the timestamps,
make them a *documented* part of the framework
and tell people to use them instead of the
standard output streams.

(C) If you have control of the environment in
which the programs run, redirect stdout and stderr
into a separate process that will add the
timestamps before displaying the output.

(D) It may be possible to create your own
version of printf & family and force the programs
to use those by linking them ahead of the standard
libraries. (I do not recall if the standard Linux
linker will allow you to do this, while being
somehow tolerant of multiple definitions, etc.)
This may have undesirable side effects if other
code from the libraries also uses your functions.

(E) Create your own versions of the functions,
(like (B) but with the same names.) Modify the
source code of the standard C library to give
printf & friends new names. Link your programs
with the modified version of the library.

If I was responsible for this decision in one
of the projects I'm working on, I'll chose
either (A) or (B).

Hope this helps,

On Sat, 07 Jan 2006 09:42:13 -0500, Roberto Waltman
<usenet@rwaltman.net> wrote:

> (2) Nobody else jumping on the wagon to tell
>     you that this is not doable in C / off
>     topic in comp.lang.c, etc.

Thank you for your response.  I appreciate the suggestions.

What about my question was off-topic for this newsgroup?  And which
newsgroup do you suggest would have been more appropriate?

nobody@nowhere.com wrote:
> I am writing a framework that other developers will write plug-ins
> for.  I would like for one of the features of the framework to be to
> intercept all text written to stdout/stderr and prepend timestamps on
> each line.
>
> I would like for this to work for all the printf-line functions
> (fprintf, etc...) as well as C++ I/O streams (cout and cerr).
>
> The key here is that I would like to get these timestamps on the lines
> of text written to stdout/stderr without requiring any code
> change/recompilation of the plug-ins.
>
> Also, the target platform is linux.
>
> Any ideas?  Thanks!

Write a program that creates a pipe, redirect I/O (dup) and fork to the
plug-in?.

Kind regards.

>>I am writing a framework that other developers will write plug-ins
>>for.  I would like for one of the features of the framework to be to
>>intercept all text written to stdout/stderr and prepend timestamps on
>>each line.

In general, C does not "automatically do".
You have to write code to do that.

Interception generally requires a football or wiretapping equipment.
Or, in the case of output streams, you can pipe it through something
that adds the timestamps.

>>I would like for this to work for all the printf-line functions
>>(fprintf, etc...) as well as C++ I/O streams (cout and cerr).
>>The key here is that I would like to get these timestamps on the lines
>>of text written to stdout/stderr without requiring any code
>>change/recompilation of the plug-ins.
>>Also, the target platform is linux.
>>Any ideas?  Thanks!
>
>This is a slow day, as proven by
> (1) Me having only five ideas so far, and
> (2) Nobody else jumping on the wagon to tell
>     you that this is not doable in C / off
>     topic in comp.lang.c, etc.
>
>In any case, this is what I can think of:
>
>(A) Do not do it, at least not that way. Choose
>one of the several logging services / libraries
>available for Linux, make it a *documented*
>part of the framework and tell people to use it
>instead of the standard output streams.

>(B) Do not do it, at least not that way. Create
>your own versions of printf & family (with
>different names,) that will add the timestamps,
>make them a *documented* part of the framework
>and tell people to use them instead of the
>standard output streams.

You might look at the documented interface for syslog (whether
or not you actually use syslog).  It's not exactly the same
interface as printf(), but you might find some of the features
useful.

>(C) If you have control of the environment in
>which the programs run, redirect stdout and stderr
>into a separate process that will add the
>timestamps before displaying the output.
>
>(D) It may be possible to create your own
>version of printf & family and force the programs
>to use those by linking them ahead of the standard
>libraries. (I do not recall if the standard Linux
>linker will allow you to do this, while being
>somehow tolerant of multiple definitions, etc.)
>This may have undesirable side effects if other
>code from the libraries also uses your functions.

This may have undesireable side effects on your code.
A module that does something like:
	sprintf(filename, "%s/.%src", getenv("HOME"), "foo");
and then opens said file might start producing messages like:
Jan  6  13:18:32 Error opening file "Jan  6 13:18:31 /home/george/.foorrc": file not found.  sprintf() *is* part of the printf() family, right?

>(E) Create your own versions of the functions,
>(like (B) but with the same names.) Modify the
>source code of the standard C library to give
>printf & friends new names. Link your programs
>with the modified version of the library.

Ditto with evil effects on sprintf().

>If I was responsible for this decision in one
>of the projects I'm working on, I'll chose
>either (A) or (B).

I agree.

						Gordon L. Burditt

nobody@nowhere.com wrote:
> I am writing a framework that other developers will write plug-ins
> for.  I would like for one of the features of the framework to be to
> intercept all text written to stdout/stderr and prepend timestamps on
> each line.
>
> I would like for this to work for all the printf-line functions
> (fprintf, etc...) as well as C++ I/O streams (cout and cerr).
>
> The key here is that I would like to get these timestamps on the lines
> of text written to stdout/stderr without requiring any code
> change/recompilation of the plug-ins.
>
> Also, the target platform is linux.
>
> Any ideas?  Thanks!

Write a program that redirect I/O (dup) and fork to the plug-in?.

Kind regards.

nobody@nowhere.com wrote:
> I am writing a framework that other developers will write plug-ins
> for.  I would like for one of the features of the framework to be to
> intercept all text written to stdout/stderr and prepend timestamps on
> each line.
>
> I would like for this to work for all the printf-line functions
> (fprintf, etc...) as well as C++ I/O streams (cout and cerr).
>
> The key here is that I would like to get these timestamps on the lines
> of text written to stdout/stderr without requiring any code
> change/recompilation of the plug-ins.
>
> Also, the target platform is linux.
>
> Any ideas?  Thanks!

Your program could create a pipe, redirect I/O (dup) and fork to the
plug-in?.

Kind regards.

nobody@nowhere.com wrote:
> I am writing a framework that other developers will write plug-ins
> for.  I would like for one of the features of the framework to be to
> intercept all text written to stdout/stderr and prepend timestamps on
> each line.
>
> I would like for this to work for all the printf-line functions
> (fprintf, etc...) as well as C++ I/O streams (cout and cerr).
>
> The key here is that I would like to get these timestamps on the lines
> of text written to stdout/stderr without requiring any code
> change/recompilation of the plug-ins.
>
> Also, the target platform is linux.
>
> Any ideas?  Thanks!

Write a program that redirect I/O (dup) and fork to the plug-in?.

Kind regards.

nobody@nowhere.com wrote:
> I am writing a framework that other developers will write plug-ins
> for.  I would like for one of the features of the framework to be to
> intercept all text written to stdout/stderr and prepend timestamps on
> each line.
>
> I would like for this to work for all the printf-line functions
> (fprintf, etc...) as well as C++ I/O streams (cout and cerr).
>
> The key here is that I would like to get these timestamps on the lines
> of text written to stdout/stderr without requiring any code
> change/recompilation of the plug-ins.
>
> Also, the target platform is linux.
>
> Any ideas?  Thanks!

Create a pipe, fork to plug-in and redirect I/O?

Kind regards.

nobody@nowhere.com wrote:
> I am writing a framework that other developers will write plug-ins
> for.  I would like for one of the features of the framework to be to
> intercept all text written to stdout/stderr and prepend timestamps on
> each line.
>
> I would like for this to work for all the printf-line functions
> (fprintf, etc...) as well as C++ I/O streams (cout and cerr).
>
> The key here is that I would like to get these timestamps on the lines
> of text written to stdout/stderr without requiring any code
> change/recompilation of the plug-ins.
>
> Also, the target platform is linux.
>
> Any ideas?  Thanks!

Create a pipe, fork to plug-in and redirect I/O?

Kind regards.

Roberto Waltman wrote:
> nobody@nowhere.com wrote:
> >I am writing a framework that other developers will write plug-ins
> >for.  I would like for one of the features of the framework to be to
> >intercept all text written to stdout/stderr and prepend timestamps on
> >each line.
> >I would like for this to work for all the printf-line functions
> >(fprintf, etc...) as well as C++ I/O streams (cout and cerr).
> >The key here is that I would like to get these timestamps on the lines
> >of text written to stdout/stderr without requiring any code
> >change/recompilation of the plug-ins.
> >Also, the target platform is linux.
> >Any ideas?  Thanks!
>
> This is a slow day, as proven by
>  (1) Me having only five ideas so far, and
>  (2) Nobody else jumping on the wagon to tell
>      you that this is not doable in C / off
>      topic in comp.lang.c, etc.
>
> In any case, this is what I can think of:
>
> (A) Do not do it, at least not that way. Choose
> one of the several logging services / libraries
> available for Linux, make it a *documented*
> part of the framework and tell people to use it
> instead of the standard output streams.
>
> (B) Do not do it, at least not that way. Create
> your own versions of printf & family (with
> different names,) that will add the timestamps,
> make them a *documented* part of the framework
> and tell people to use them instead of the
> standard output streams.
>
> (C) If you have control of the environment in
> which the programs run, redirect stdout and stderr
> into a separate process that will add the
> timestamps before displaying the output.
>
> (D) It may be possible to create your own
> version of printf & family and force the programs
> to use those by linking them ahead of the standard
> libraries. (I do not recall if the standard Linux
> linker will allow you to do this, while being
> somehow tolerant of multiple definitions, etc.)
> This may have undesirable side effects if other
> code from the libraries also uses your functions.

Off Topic:
    The GNU linker has a --wrap option that allows you to wrap symbols
through __wrap_SYMBOL.  In this case, you could define __wrap_printf as
your version of printf and prepend the timestamp to the format string.
I have used this feature to force memory allocation routines to use
Matlab's memory allocation routines in Matlab MEX files in the past.
The nice part about the wrap option is that even for libraries where
all you have are compiled libraries/etc even those symbols get wrapped
to your routine.  I do however agree with the other posters that the
preferable solution would be tell developers who are writing plugins to
use your custom printf or fprintf routines.  The benefit about that
solution is you're not using system-dependent features and hence more
portable.

As for other newsgroups that would be more on-topic, for linux you can
try comp.unix.programmer or possibly comp.os.linux.development.apps.

>
> (E) Create your own versions of the functions,
> (like (B) but with the same names.) Modify the
> source code of the standard C library to give
> printf & friends new names. Link your programs
> with the modified version of the library.
>
> If I was responsible for this decision in one
> of the projects I'm working on, I'll chose
> either (A) or (B).
> 
> Hope this helps,

Roberto Waltman wrote:
> nobody@nowhere.com wrote:
> >I am writing a framework that other developers will write plug-ins
> >for.  I would like for one of the features of the framework to be to
> >intercept all text written to stdout/stderr and prepend timestamps on
> >each line.
> >I would like for this to work for all the printf-line functions
> >(fprintf, etc...) as well as C++ I/O streams (cout and cerr).
> >The key here is that I would like to get these timestamps on the lines
> >of text written to stdout/stderr without requiring any code
> >change/recompilation of the plug-ins.
> >Also, the target platform is linux.
> >Any ideas?  Thanks!
>
> This is a slow day, as proven by
>  (1) Me having only five ideas so far, and
>  (2) Nobody else jumping on the wagon to tell
>      you that this is not doable in C / off
>      topic in comp.lang.c, etc.
>
> In any case, this is what I can think of:
>
> (A) Do not do it, at least not that way. Choose
> one of the several logging services / libraries
> available for Linux, make it a *documented*
> part of the framework and tell people to use it
> instead of the standard output streams.
>
> (B) Do not do it, at least not that way. Create
> your own versions of printf & family (with
> different names,) that will add the timestamps,
> make them a *documented* part of the framework
> and tell people to use them instead of the
> standard output streams.
>
> (C) If you have control of the environment in
> which the programs run, redirect stdout and stderr
> into a separate process that will add the
> timestamps before displaying the output.
>
> (D) It may be possible to create your own
> version of printf & family and force the programs
> to use those by linking them ahead of the standard
> libraries. (I do not recall if the standard Linux
> linker will allow you to do this, while being
> somehow tolerant of multiple definitions, etc.)
> This may have undesirable side effects if other
> code from the libraries also uses your functions.

Off Topic:
    The GNU linker has a --wrap option that allows you to wrap symbols
through __wrap_SYMBOL.  In this case, you could define __wrap_printf as
your version of printf and prepend the timestamp to the format string.
I have used this feature to force memory allocation routines to use
Matlab's memory allocation routines in Matlab MEX files in the past.
The nice part about the wrap option is that even for libraries where
all you have are compiled libraries/etc even those symbols get wrapped
to your routine.  I do however agree with the other posters that the
preferable solution would be tell developers who are writing plugins to
use your custom printf or fprintf routines.  The benefit about that
solution is you're not using system-dependent features and hence more
portable.

As for other newsgroups that would be more on-topic, for linux you can
try comp.unix.programmer or possibly comp.os.linux.development.apps.

>
> (E) Create your own versions of the functions,
> (like (B) but with the same names.) Modify the
> source code of the standard C library to give
> printf & friends new names. Link your programs
> with the modified version of the library.
>
> If I was responsible for this decision in one
> of the projects I'm working on, I'll chose
> either (A) or (B).
> 
> Hope this helps,

Gordon Burditt wrote:
>>>I am writing a framework that other developers will write plug-ins
>>>for.  I would like for one of the features of the framework to be to
>>>intercept all text written to stdout/stderr and prepend timestamps on
>>>each line.


Create a pipe, fork and dup stdio?

Kind regards.

In article <RZbwf.201860$yg1.108971@twister.auna.com>,
tmp123  <tmp123@menta.net> wrote:
>Gordon Burditt wrote:
>>>>I am writing a framework that other developers will write plug-ins
>>>>for.  I would like for one of the features of the framework to be to
>>>>intercept all text written to stdout/stderr and prepend timestamps on
>>>>each line.
>
>
>Create a pipe, fork and dup stdio?

Yes, of course (obviously), but (as always):

Not portable.  Can't discuss it here.  Blah, blah, blah.

Kenny McCormack wrote:
> In article <RZbwf.201860$yg1.108971@twister.auna.com>,
> tmp123  <tmp123@menta.net> wrote:
> >Gordon Burditt wrote:
> >>>>I am writing a framework that other developers will write plug-ins
> >>>>for.  I would like for one of the features of the framework to be to
> >>>>intercept all text written to stdout/stderr and prepend timestamps on
> >>>>each line.
> >
> >
> >Create a pipe, fork and dup stdio?
>
> Yes, of course (obviously), but (as always):
>
> Not portable.  Can't discuss it here.  Blah, blah, blah.


Are you taken "pipe"... like function names or like concepts?

Kind regards.

Kenny McCormack wrote:
> In article <RZbwf.201860$yg1.108971@twister.auna.com>,
> tmp123  <tmp123@menta.net> wrote:
> >Gordon Burditt wrote:
> >>>>I am writing a framework that other developers will write plug-ins
> >>>>for.  I would like for one of the features of the framework to be to
> >>>>intercept all text written to stdout/stderr and prepend timestamps on
> >>>>each line.
> >
> >
> >Create a pipe, fork and dup stdio?
>
> Yes, of course (obviously), but (as always):
>
> Not portable.  Can't discuss it here.  Blah, blah, blah.

Are you taken "pipe"... like function names or like concepts?

Kind regards.

Kenny McCormack ha escrito:

> In article <RZbwf.201860$yg1.108971@twister.auna.com>,
> tmp123  <tmp123@menta.net> wrote:
> >Gordon Burditt wrote:
> >>>>I am writing a framework that other developers will write plug-ins
> >>>>for.  I would like for one of the features of the framework to be to
> >>>>intercept all text written to stdout/stderr and prepend timestamps on
> >>>>each line.
> >
> >
> >Create a pipe, fork and dup stdio?
>
> Yes, of course (obviously), but (as always):
>
> Not portable.  Can't discuss it here.  Blah, blah, blah.

Are you taken "pipe"... like function names or like concepts?

Kind regards.

tmp123 wrote:
> Gordon Burditt wrote:

Please leave in the attributions for the text you are acutally quoting. 
I don't believe Gordon Burditt wrote any of the below.

>>>> I am writing a framework that other developers will write plug-ins
>>>> for.  I would like for one of the features of the framework to be to
>>>> intercept all text written to stdout/stderr and prepend timestamps on
>>>> each line.
> 
> Create a pipe, fork and dup stdio?

That is completely non-portable and won't work with a number of very 
common platforms, since they don't support what you are suggesting. 
What, in the post, suggests that a platform that supports such things is 
being used? Even if functions of those names do exist they might have 
different semantics.

Also, why are you so determined to give people off topic answers without 
even having the curtsey to state that they are platform specific and 
should be discussed else where?
-- 
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Flash Gordon wrote:
> [...]
> What, in the post, suggests that a platform that supports such things is 
> being used? [...]

     The next-to-last line, perhaps?

-- 
Eric Sosman
esosman@acm-dot-org.invalid

Eric Sosman wrote:
> Flash Gordon wrote:
>> [...]
>> What, in the post, suggests that a platform that supports such things 
>> is being used? [...]
> 
>     The next-to-last line, perhaps?

I must have missed that (and can't verify as you've snipped that bit and 
hunting it down is not worth the effort), but tmp123 should still have 
stated it was making a non-C-standard solution.
-- 
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Flash Gordon wrote:
> tmp123 wrote:
>
> Please leave in the attributions for the text you are acutally quoting.
> I don't believe Gordon Burditt wrote any of the below.

My apologize to Mr.Burditt, cut&paste mistake. Sorry.

>
> >>>> I am writing a framework that other developers will write plug-ins
> >>>> for.  I would like for one of the features of the framework to be to
> >>>> intercept all text written to stdout/stderr and prepend timestamps on
> >>>> each line.
> >
> > Create a pipe, fork and dup stdio?
>
> That is completely non-portable and won't work with a number of very
> common platforms, since they don't support what you are suggesting.
> What, in the post, suggests that a platform that supports such things is
> being used? Even if functions of those names do exist they might have
> different semantics.
>
> Also, why are you so determined to give people off topic answers without
> even having the curtsey to state that they are platform specific and
> should be discussed else where?

Why do you take the answer like function names and not like concepts?.

tmp123 <tmp123@menta.net> writes:
> Create a pipe, fork and dup stdio?

Plumbing and silverware are outside the scope of the standard.

DES
-- 
Dag-Erling Sm�rgrav - des@des.no

tmp123 wrote:
> Flash Gordon wrote:
>> tmp123 wrote:

<snip>

>>> Create a pipe, fork and dup stdio?
>> That is completely non-portable and won't work with a number of very
>> common platforms, since they don't support what you are suggesting.
>> What, in the post, suggests that a platform that supports such things is
>> being used? Even if functions of those names do exist they might have
>> different semantics.
>>
>> Also, why are you so determined to give people off topic answers without
>> even having the curtsey to state that they are platform specific and
>> should be discussed else where?
> 
> Why do you take the answer like function names and not like concepts?.

Since dup is not a word nor a concept defined in the C standard the only 
obvious interpretation is that it is the name of a function. In any 
case, the C standard does not have the concepts of forking processes, 
creating pipes or duplicating low level file handles, so it would still 
be off topic even if you clearly meant the concepts that POSIX 
implements using those functions, and thus should still include a 
redirection to another group.

Also, why have you now posted that response something like half a dozen 
times? Are you trying to be annoying?
-- 
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Flash Gordon <spam@flash-gordon.me.uk> wrote:

> tmp123 wrote:

[ Well, _what_ he wrote is unimportant to this post, really, only _that_
  he, and a couple of other Googlites, multi-posted this morning. ]

> Also, why have you now posted that response something like half a dozen 
> times? Are you trying to be annoying?

It looks like Google Broken Beta Groups is playing silly buggers. Again.
In a new and creatively broken way.

Richard

Flash Gordon wrote:
> Also, why have you now posted that response something like half a dozen
> times? Are you trying to be annoying?


As Mr. Bos said, problems on my interface with google. Sorry for the
overload. I will stop posting until solved.

Richard Bos wrote:
> Flash Gordon <spam@flash-gordon.me.uk> wrote:
> 
>> tmp123 wrote:
> 
> [ Well, _what_ he wrote is unimportant to this post, really, only _that_
>   he, and a couple of other Googlites, multi-posted this morning. ]
> 
>> Also, why have you now posted that response something like half a dozen 
>> times? Are you trying to be annoying?
> 
> It looks like Google Broken Beta Groups is playing silly buggers. Again.
> In a new and creatively broken way.

In that case, apologies to those unfortunate enough to be using Google 
who I have complained at where it is Google messing up rather than the 
poster. I suggest those using Google complain to Google and/or use a 
real news reader (or even Outlook Express) instead of the broken Google 
interface.
-- 
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

tmp123 wrote:
>
.... snip ...
> 
> Write a program that creates a pipe, redirect I/O (dup) and fork
> to the plug-in?.

We don't really need to have 6 copies of your off-topic post. 
Pipes are used for smoking, forks are used for eating, dup may be 
describing you and your inability to stay on topic, and I cannot 
really categorize plug-in.  They all have nothing to do with the C 
language.

The 6 copies may be partly googles fault, but the content changed 
slightly in some of them, so I consider you to be at fault.

-- 
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
  "show options" at the top of the article, then click on the
  "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

Flash Gordon wrote:

> Eric Sosman wrote:
> 
>> Flash Gordon wrote:
>>
>>> [...]
>>> What, in the post, suggests that a platform that supports such things 
>>> is being used? [...]
>>
>>
>>     The next-to-last line, perhaps?
> 
> 
> I must have missed that (and can't verify as you've snipped that bit and 
> hunting it down is not worth the effort), but tmp123 should still have 
> stated it was making a non-C-standard solution.

     No; tmp123 snipped that bit.

     And if you think it's "not worth the effort" to fact-check
what you write ...  Sounds like a direct threat to your own
credibility, doesn't it?

-- 
Eric Sosman
esosman@acm-dot-org.invalid

Flash Gordon wrote:
> Richard Bos wrote:
>> Flash Gordon <spam@flash-gordon.me.uk> wrote:
>> 
.... snip ...
>> 
>>> Also, why have you now posted that response something like
>>> half a dozen times? Are you trying to be annoying?
>> 
>> It looks like Google Broken Beta Groups is playing silly
>> buggers. Again. In a new and creatively broken way.
> 
> In that case, apologies to those unfortunate enough to be using
> Google who I have complained at where it is Google messing up
> rather than the poster. I suggest those using Google complain to
> Google and/or use a real news reader (or even Outlook Express)
> instead of the broken Google interface.

If Google were Microsoft I would be sure they are doing this to 
harm usenet and push their own google groups.  As it is I am hard 
put to find any other motive for the foulness of their interface.

-- 
"If you want to post a followup via groups.google.com, don't use
  the broken "Reply" link at the bottom of the article.  Click on
  "show options" at the top of the article, then click on the
  "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>

Eric Sosman wrote:
> Flash Gordon wrote:
> 
>> Eric Sosman wrote:
>>
>>> Flash Gordon wrote:
>>>
>>>> [...]
>>>> What, in the post, suggests that a platform that supports such 
>>>> things is being used? [...]
>>>
>>>     The next-to-last line, perhaps?
>>
>> I must have missed that (and can't verify as you've snipped that bit 
>> and hunting it down is not worth the effort), but tmp123 should still 
>> have stated it was making a non-C-standard solution.
> 
>     No; tmp123 snipped that bit.

You snipped the entirety of what tmp123 posted, so I could not see from 
what you posted whether there was anything in the post I was responding 
to indicating that it was a system supporting Posix or Posix like 
functionality. Based on what you are saying there was nothing in his 
message to indicate this, so it seems that asking what indicated the 
platform supported such things was perfectly reasonable.

>     And if you think it's "not worth the effort" to fact-check
> what you write ...  Sounds like a direct threat to your own
> credibility, doesn't it?

I did not consider fact checking *your* post to be worth my effort, so I 
accepted based on your comment that there must have been something I had 
missed in what either you or I snipped that answered by question. If you 
think that I should not trust your posts to give a reasonable indication 
of what has been said then I don't mind putting you on a list of posters 
whose posts I should not take at face value.

On that basis that you consider me trusting your posts to be 
representative of what has gone on I have now gone back and checked what 
I have responded to in this thread. Nothing that I have responded to 
other than your post contained any indication that the OP was using a 
Posix like system. So, I will happily retract my acknowledgement that 
you might have spotted me making an error, since on this occasion I did 
not make an error in posting the query you responded to.
-- 
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

On 2006-01-09, Chuck F. <cbfalconer@yahoo.com> wrote:
> If Google were Microsoft I would be sure they are doing this to 
> harm usenet and push their own google groups.  As it is I am hard 
> put to find any other motive for the foulness of their interface.
I guess that's why it's "Google Groups BETA". I guess that's the 
difference between MS and Google :-).

-- 
Ioan - Ciprian Tandau
tandau _at_ freeshell _dot_ org (hope it's not too late)
(... and that it still works...)

In article <fao993x3sg.ln2@news.flash-gordon.me.uk>,
Flash Gordon  <spam@flash-gordon.me.uk> wrote:
....
>Also, why have you now posted that response something like half a dozen 
>times? Are you trying to be annoying?

He is learning from the best.  You guys post the same shit over and over
and over (and will still be doing so 20 years from now...)

Nelu wrote:
> On 2006-01-09, Chuck F. <cbfalconer@yahoo.com> wrote:
>> If Google were Microsoft I would be sure they are doing this to 
>> harm usenet and push their own google groups.  As it is I am hard 
>> put to find any other motive for the foulness of their interface.
> I guess that's why it's "Google Groups BETA". I guess that's the 
> difference between MS and Google :-).

Although how they can simultaneously call it a Beta and not provide 
access by default to the older non-Beta interface...

BTW, is there any way to access the older interface that was not in beta?
-- 
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

On Mon, 9 Jan 2006, Flash Gordon wrote:
> Nelu wrote:
>> On 2006-01-09, Chuck F. <cbfalconer@yahoo.com> wrote:
>>> If Google were Microsoft I would be sure they are doing this to harm 
>>> usenet and push their own google groups.  As it is I am hard put to find 
>>> any other motive for the foulness of their interface.
>> I guess that's why it's "Google Groups BETA". I guess that's the 
>> difference between MS and Google :-).
>
> Although how they can simultaneously call it a Beta and not provide access
> by default to the older non-Beta interface...

   "Beta" to Google means "Version 2, but all l33t and technical-sounding."
Google Groups will never get "out of beta," any more than Google News 
will. The designation has nothing to do with "buggy." The bugs just come
with the territory.

> BTW, is there any way to access the older interface that was not in beta?

   Not since the middle of last year, no. The better version was phased
out as their translators got to it, so for a while the Turkish and Israeli
sites were still working. They've been gone for months now, though.

   The solution is /not to use Google Groups!/  It's not that hard, 
people...!

-Arthur,
preaching to the choir

Arthur J. O'Dwyer wrote:
> 
> On Mon, 9 Jan 2006, Flash Gordon wrote:

<snip>

>> BTW, is there any way to access the older interface that was not in beta?
> 
>   Not since the middle of last year, no. The better version was phased
> out as their translators got to it, so for a while the Turkish and Israeli
> sites were still working. They've been gone for months now, though.
> 
>   The solution is /not to use Google Groups!/  It's not that hard, 
> people...!

Apart from the odd bit of searching, I don't. :-)

> -Arthur,
> preaching to the choir

Indeed :-)
-- 
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.

Flash Gordon wrote:

> Arthur J. O'Dwyer wrote:

> > The solution is /not to use Google Groups!/  It's not that hard,
> > people...!
> 
> Apart from the odd bit of searching, I don't. :-)


It's easy to say, "just don't use it." However, for many people, it's
the only option. Many ISPs do not provide a newsfeed, and in certain
countries even the fairly nominal amount news.individual.net charges
can be a burden.

For many people, company restrictions on software installation or
firewalls may prevent accessing NNTP. In the early part of 2005, our
news feed was dead and other news servers could not be accessed. The IT
guy in charge of usenet was able to get a special port in the proxy
server assigned to NIN, but until that point I had to use Google.

Like it or not, Google is becoming a major part of usenet. Covering our
eyes and saying "don't use it  don't use it  don't use it  don't use
it" is not going to change that. We need to keep educating Google users
as to proper netiquette AND apply pressure to Google to become a good
citizen as well.



Brian

Default User wrote:
> Flash Gordon wrote:
> 
>> Arthur J. O'Dwyer wrote:
> 
>>> The solution is /not to use Google Groups!/  It's not that hard,
>>> people...!
>> Apart from the odd bit of searching, I don't. :-)
> 
> It's easy to say, "just don't use it." However, for many people, it's
> the only option. Many ISPs do not provide a newsfeed, and in certain
> countries even the fairly nominal amount news.individual.net charges
> can be a burden.

There are still free services if people hunt for them. Although I accept 
that most users won't.

> For many people, company restrictions on software installation or
> firewalls may prevent accessing NNTP. In the early part of 2005, our
> news feed was dead and other news servers could not be accessed. The IT
> guy in charge of usenet was able to get a special port in the proxy
> server assigned to NIN, but until that point I had to use Google.

Agreed, sometimes people are forced to use a web based interface or 
forgo Usenet access.

> Like it or not, Google is becoming a major part of usenet. Covering our
> eyes and saying "don't use it  don't use it  don't use it  don't use
> it" is not going to change that. We need to keep educating Google users
> as to proper netiquette AND apply pressure to Google to become a good
> citizen as well.

Agreed.
-- 
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.