Automatically prepend all stdout/stderr output with timestamp?

[nobody]

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!

[Richard Heathfield]

no****@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)

[Roberto Waltman]

no****@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,

[nospam]

On Sat, 07 Jan 2006 09:42:13 -0500, Roberto Waltman
<us****@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?

[Gordon Burditt]

>>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

[tmp123]

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.

[Kenny McCormack]

In article <RZ*********************@twister.auna.com>,
tmp123 <tm****@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.

[Flash Gordon]

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.

[Eric Sosman]

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
es*****@acm-dot-org.invalid

[Flash Gordon]

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.

[tmp123]

no****@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.

[tmp123]

no****@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.

[tmp123]

no****@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.

[Chris Hulbert]

Roberto Waltman wrote:

no****@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,

[tmp123]

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]

no****@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.

[tmp123]

Kenny McCormack wrote:

In article <RZ*********************@twister.auna.com>,
tmp123 <tm****@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.

[Dag-Erling Smørgrav]

tmp123 <tm****@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 - de*@des.no

[tmp123]

Kenny McCormack wrote:

In article <RZ*********************@twister.auna.com>,
tmp123 <tm****@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.

[Chris Hulbert]

Roberto Waltman wrote:

no****@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,

[tmp123]

no****@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.

[tmp123]

Kenny McCormack ha escrito:

In article <RZ*********************@twister.auna.com>,
tmp123 <tm****@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]

no****@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.

[Flash Gordon]

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.

[Richard Bos]

Flash Gordon <sp**@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

[tmp123]

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.

[Flash Gordon]

Richard Bos wrote:

Flash Gordon <sp**@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.

[Chuck F.]

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/>

[Eric Sosman]

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
es*****@acm-dot-org.invalid

[Chuck F.]

Flash Gordon wrote:

Richard Bos wrote:

Flash Gordon <sp**@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/>

[Nelu]

On 2006-01-09, Chuck F. <cb********@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...)

[Flash Gordon]

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.

[Kenny McCormack]

In article <fa************@news.flash-gordon.me.uk>,
Flash Gordon <sp**@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...)

[Flash Gordon]

Nelu wrote:

On 2006-01-09, Chuck F. <cb********@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.

[Arthur J. O'Dwyer]

On Mon, 9 Jan 2006, Flash Gordon wrote:

Nelu wrote:

On 2006-01-09, Chuck F. <cb********@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

[Flash Gordon]

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.

[Default User]

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

[Flash Gordon]

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.