why doesn't grep count 2 commas


echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | grep -c ,
1

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f1
Kích thước máy xay cỏ

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f2
giá máy thế nào

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f3
phụ tùng máy mua ở đâu

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 16:10, fxkl47BF@protonmail.com wrote:

why doesn't grep count 2 commas

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | grep -c ,
1

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f1
Kích thước máy xay cỏ

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f2
giá máy thế nào

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f3
phụ tùng máy mua ở đâu

Grep's -c option counts the *lines* which match. You only inputted one line, and grep said one line was found which matched *,*
--
John

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Jan 19, 2024 at 07:10:51AM +0000, fxkl47BF@protonmail.com wrote:

why doesn't grep count 2 commas

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | grep -c ,
1

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f1
Kích thước máy xay cỏ

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f2
giá máy thế nào

echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | cut -d, -f3
phụ tùng máy mua ở đâu

It is in the man page:

-c, --count
Suppress normal output; instead print a count of matching lines
for each input file. With the -v, --invert-match option (see
below), count non-matching lines.

It counts matching lines. You gave it one line.

If you want to go character-wise, tr might fit the bill (e.g. do a tr -c
to remove everything except comma, then measure the resulting string's
length).

Of course, if you have something else than shell+utils there might be
more efficient ways.

Cheers
--
t

-----BEGIN PGP SIGNATURE-----

iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZaosIQAKCRAFyCz1etHa RgGAAJ9x9nRMFKu7X5MDooJXFKeud/n9wQCfXQmFlEIKWKZA8x2lYcACTt0wuOw=
=Gh7k
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

fxkl47BF@protonmail.com wrote:

why doesn't grep count 2 commas
echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' |
grep -c ,
1

Happens with much simpler text too:
$ echo ',,,' | grep -c ','
1

The man page explains it:

-c, --count
Suppress normal output; instead print a count of matching lines
for each input file. With the -v, --invert-match option (see
below), count non-matching lines. (-c is specified by POSIX.)

Note that it counts lines, not characters.

Counting characters by grep seems somewhat tricky:
https://www.unix.com/shell-programming-and-scripting/128033-grep-command-count-characters.html

An answer to this question
https://stackoverflow.com/questions/16679369/count-occurrences-of-a-char-in-a-string-using-bash
proposes
echo "referee" | tr -cd 'e' | wc -c

$ echo ',,,' | tr -cd ',' | wc -c
3
$ echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | tr -cd ',' | wc -c
2

(I hope i did not quote something that's against the code of conduct. :))


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Jan 19, 2024 at 09:25:14AM +0100, Thomas Schmitt wrote:

fxkl47BF@protonmail.com wrote:

why doesn't grep count 2 commas
echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' |
grep -c ,
1

Here's my way:

$ echo 'Kích thước máy xay cỏ, giá máy thế nào , phụ tùng máy mua ở đâu' | fold -w1 | grep -c ,
2



-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEEDXVee01gWrPIdWPRwgRAue7sYQMFAmWqWhAACgkQwgRAue7s YQPp6Q//dK5FXcsKgqLKzkGtVpxIKmj68xRRAE/MQO0FDwAQJE5EoYEPaYqw5tbs G5VAvsiZRopBAvqQBzciy5z4d+2jwZ5OD0xv7cBFfoUbtfUVIlPNETcgSBYLPDvN 8zTSYT/atGKX2SVJCPcC7sgOK9Gel5C4eaq7/yuUHjiA9SEk0xpH/J6YnIv/B8tV Ggfi8/ywCTQCVTFznWiR1u3q1T1pU+IhsQnBT/irRODQduzRj97NGEzGO6AqJ18c K0dxCfNz6Ql7JUFuEofUQw+D6aP7sB5zwNQePsHgbjBxszuKb0uBhAwgVRXAiaNg bAx1RJPKBEOxGAdvUt49KkwcS5Wmhlqyf20ACwySWj8uSHy07zsWD/pbA/Pr3dpd 3gURBw9t8h1kn8up+0rvFd2DRV8xEF/VHa3Pjt67UNa8gLbjFLa/tPQCsds0w8P7 gYGCPTifxazHcZAkgttaYN6ZcpfbTKD53MlcsKRWHQN3Snkw0ZEiF9qvQC6NfBx8 eEzv/LHNQPd7A5oVvNJ4LxW/418Iw2earyXHK7oonHQXs7Cxf8P2xMnS2L0qdKot Y20FTkI6PZwxCO8O122N7NU5+ZYCNtyPlz3sMnJU1YvIPfqPjE0ZHWNSOPYIImeT 62THzlzFZRrGCGPmDj3lV78cGgU32Hg8UofGcADVGfMSWByXnSw=
=CGgR
-----END PGP SIGNATURE-----

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Jan 19, 2024 at 09:25:14AM +0100, Thomas Schmitt wrote:

An answer to this question
https://stackoverflow.com/questions/16679369/count-occurrences-of-a-char-in-a-string-using-bash
proposes
echo "referee" | tr -cd 'e' | wc -c

$ echo ',,,' | tr -cd ',' | wc -c
3

That's one way, and it's sh-compatible.

If you actually want to do it in *bash* as the URL suggests, you can
take advantages of bash's extra features, to avoid forking two new
programs plus a subshell.

unicorn:~$ string="apple,banana,cherry,date"
unicorn:~$ commas=${string//[!,]/}
unicorn:~$ echo "${#commas}"
3

In this case, I'm using the ${varname//old/new} expansion to remove
everything that isn't a comma.

But at this point, we have to wonder what the *actual* goal is. They
wanted to count the number of commas... why, exactly? Are they going
to split the input string into a list of substrings? If so, just do
that in the first place.

unicorn:~$ IFS=, read -ra list <<< "$string,"
unicorn:~$ declare -p list
declare -a list=([0]="apple" [1]="banana" [2]="cherry" [3]="date")

To understand why I added an extra comma at the end of the input
string, see <https://mywiki.wooledge.org/BashPitfalls#pf47>.

This approach needs adjustment if the input string may contain
newlines. So, please state the actual goal up front, in full, and
include a worst-case-scenario example.

Finally, if the input is actually a CSV (Comma-Separated Values)
file, which may contain fields with commas *inside* them, then none
of these approaches work. You need an actual CSV parser to handle
these files properly.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi,

Greg Wooledge wrote:

unicorn:~$ string="apple,banana,cherry,date"
unicorn:~$ commas=${string//[!,]/}
unicorn:~$ echo "${#commas}"
3

Always astonishing what a good bashism can do.

But at this point, we have to wonder what the *actual* goal is.

Up to now we only know about the astonishment of fxkl47BF@protonmail.com
that grep -c does not count characters.

For a more complicated use case i would write a little C program where
i'd be in control of every single bit of throughput.
(Ok, C causes scars on the programmer's self esteem. But what does not
kill me makes me just stronger. I'm a vim user.)


Have a nice day :)

Thomas

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 19 Jan 2024, Thomas Schmitt wrote:

Hi,

Greg Wooledge wrote:

unicorn:~$ string="apple,banana,cherry,date"
unicorn:~$ commas=${string//[!,]/}
unicorn:~$ echo "${#commas}"
3

Always astonishing what a good bashism can do.

But at this point, we have to wonder what the *actual* goal is.

to exclude phrases with commas for seperate examination

Up to now we only know about the astonishment of fxkl47BF@protonmail.com
that grep -c does not count characters.

i DID know that
that brain cell was offline at the moment
it needed a reminder to refresh the connection

For a more complicated use case i would write a little C program where
i'd be in control of every single bit of throughput.
(Ok, C causes scars on the programmer's self esteem. But what does not
kill me makes me just stronger. I'm a vim user.)

vi is the only way to go
i programmed c on hp/ux for 20+ years
had a room full of k200's
that was a lifetime ago

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, Jan 19, 2024 at 03:30:17PM +0000, fxkl47BF@protonmail.com wrote:

But at this point, we have to wonder what the *actual* goal is.

to exclude phrases with commas for seperate examination

Parsing natural language text is going to be tricky. I can only talk
about English, and not about whatever language your text is actually
written in.

Let's look at a few example English sentences:

Good morning, John.

I went to the store with Mary, Paul, Susan and Ralph.

I won, and you lost.

The bear, who was hungry, looked for food.

Oh, that's interesting.

These are five different examples of comma usage in English. Do you
happen to know in advance that your text will *only* contain samples
that use the fourth style above? Let's assume this. Let's then form
a template:

STUFF, ASIDE, MORE STUFF, ASIDE, STILL MORE STUFF.

I.e. given a sentence which conforms to expectation, we should see
an even number of commas (is *THIS* why you were counting them??) and
we should extract the ASIDEs from in between the first and second, then
the third and fourth, and so on.

So... uh, I guess my next question is: are you *pre-filtering* the
sentences and keeping only the ones which have an even number of
commas? Or have you already *done* that, and now you're asking how
to extract the ASIDEs?

I really don't think I'd try this with shell scripts. The tools just
aren't designed for this. You really want tools that are custom built
for natural language processing, or a language that lets you run
through a large string character by character in a fast, efficient
way (C comes to mind) if you're trying to build your tools from the
ground up.

The "obvious" algorithm for extracting the ASIDEs would be use a
simple finite state machine, and march through the sentence
character by character. When you encounter a comma, change state.
Otherwise, if you're in the "ASIDE" state, copy the character to your
output buffer. When you leave the "ASIDE" state, terminate the current
output buffer and move to the next one. That's how I'd do it in C.
Add whitespace trimming and so on.

Also note that breaking a piece of natural language text *into*
sentences in the first place is extraordinarily difficult. If you
haven't already got a way to do that, you're probably screwed.
Seriously, asking the debian-user list how to count the number of
commas in a text file is *not* a good sign if you're dealing with a masters-degree-level problem in natural language analysis.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Greg Wooledge <greg@wooledge.org> wrote:

I won, and you lost

There shouldn't be a comma in that sentence, in English. There is in
the closely related expression "I won, you lost."

I really don't think I'd try this with shell scripts. The tools just
aren't designed for this. You really want tools that are custom built
for natural language processing, or a language that lets you run
through a large string character by character in a fast, efficient
way (C comes to mind) if you're trying to build your tools from the
ground up.

At the risk of being seen as old-fashioned, but as a user of both
languages, I think Perl is a much better choice than C for string
processing. But whatever the OP knows is likely the best choice in the
short term.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri, 19 Jan 2024, Greg Wooledge wrote:

On Fri, Jan 19, 2024 at 03:30:17PM +0000, fxkl47BF@protonmail.com wrote:

But at this point, we have to wonder what the *actual* goal is.

to exclude phrases with commas for seperate examination

Parsing natural language text is going to be tricky. I can only talk
about English, and not about whatever language your text is actually
written in.

Let's look at a few example English sentences:

Good morning, John.

I went to the store with Mary, Paul, Susan and Ralph.

I won, and you lost.

The bear, who was hungry, looked for food.

Oh, that's interesting.

These are five different examples of comma usage in English. Do you
happen to know in advance that your text will *only* contain samples
that use the fourth style above? Let's assume this. Let's then form
a template:

STUFF, ASIDE, MORE STUFF, ASIDE, STILL MORE STUFF.

I.e. given a sentence which conforms to expectation, we should see
an even number of commas (is *THIS* why you were counting them??) and
we should extract the ASIDEs from in between the first and second, then
the third and fourth, and so on.

So... uh, I guess my next question is: are you *pre-filtering* the
sentences and keeping only the ones which have an even number of
commas? Or have you already *done* that, and now you're asking how
to extract the ASIDEs?

I really don't think I'd try this with shell scripts. The tools just
aren't designed for this. You really want tools that are custom built
for natural language processing, or a language that lets you run
through a large string character by character in a fast, efficient
way (C comes to mind) if you're trying to build your tools from the
ground up.

The "obvious" algorithm for extracting the ASIDEs would be use a
simple finite state machine, and march through the sentence
character by character. When you encounter a comma, change state.
Otherwise, if you're in the "ASIDE" state, copy the character to your
output buffer. When you leave the "ASIDE" state, terminate the current output buffer and move to the next one. That's how I'd do it in C.
Add whitespace trimming and so on.

Also note that breaking a piece of natural language text *into*
sentences in the first place is extraordinarily difficult. If you
haven't already got a way to do that, you're probably screwed.
Seriously, asking the debian-user list how to count the number of
commas in a text file is *not* a good sign if you're dealing with a masters-degree-level problem in natural language analysis.

certain characters give the interpreter a hard time
i'll just process what is easy for the interpreter
then work on the rest

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

debian-user@howorth.org.uk writes:

There shouldn't be a comma in that sentence, in English. There is in
the closely related expression "I won, you lost."

The program has to be able to deal with bad writing.

At the risk of being seen as old-fashioned, but as a user of both
languages, I think Perl is a much better choice than C for string
processing.

Use SPITBOL.
--
John Hasler
john@sugarbit.com
Elmwood, WI USA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote:

Greg Wooledge <greg@wooledge.org> wrote:

I won, and you lost

There shouldn't be a comma in that sentence, in English. There is in
the closely related expression "I won, you lost."

That's rather proscriptive. "I won and you lost." and
"I won, and you lost." are two different sentences.

The first is a more neutral statement of fact. The
second carries an implication of triumphalism or
mockery: many speakers would expect a swoop upwards
in intonation on "won", a pause, and a steep drop
between "you" and "lost"; kinda like:

-⭜ ·¯⭝

if that works in your font.

What you lose (sorry) in "I won, you lost." is the
anacrusis, the ·, which many would pronounce "ən",
as in ənyeeoo. Without it, I'd be inclined to write
"I won. You lost." (similar intonation).

Disclaimer: my choice of intonation was to illustrate
one difference. There are many more ways of saying
all of those sentences.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 19/01/2024 23:02, David Wright wrote:

On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote:

Greg Wooledge <greg@wooledge.org> wrote:

I won, and you lost

There shouldn't be a comma in that sentence, in English. There is in
the closely related expression "I won, you lost."

Anything other than this *accurate* statement would have led to a caning
in my grammar school in the late '40s. :-)

Peter HB

That's rather proscriptive. "I won and you lost." and
"I won, and you lost." are two different sentences.

The first is a more neutral statement of fact. The
second carries an implication of triumphalism or
mockery: many speakers would expect a swoop upwards
in intonation on "won", a pause, and a steep drop
between "you" and "lost"; kinda like:

-⭜ ·¯⭝

if that works in your font.

What you lose (sorry) in "I won, you lost." is the
anacrusis, the ·, which many would pronounce "ən",
as in ənyeeoo. Without it, I'd be inclined to write
"I won. You lost." (similar intonation).

Disclaimer: my choice of intonation was to illustrate
one difference. There are many more ways of saying
all of those sentences.

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/19/24 21:48, Nicholas Geovanis wrote:

On Fri, Jan 19, 2024, 2:07 PM Thomas Schmitt <scdbackup@gmx.net <mailto:scdbackup@gmx.net>> wrote:

.....

(Ok, C causes scars on the programmer's self esteem. But what does not
kill me makes me just stronger. I'm a vim user.)

OK I'll mention that to my psychiatrist :-)
But the C programmers I knew were either really nice guys if they wrote
C on unix, or real toads if they wrote C for DOS/Windows. YMMV

Have a nice day :)

Thomas

Back in my Amiga days 25-35 years ago, I did my stuff in SAS-C or ARexx
and compiled the ARexx too. ARexx actually had wrappers for every call
Amigados had. Absolutely nothing you could not do in ARexx. Amigados
did not have a cron so we wrote one in ARexx and gave it away. Jim Hines
and I wrote the first tv stations web page ever, dedicated a dialup line
so folks could read the teleprompter text on their home computers. It
was a wild west in those days. Now everybody had a web page but me.


Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/19/24 21:48, Nicholas Geovanis wrote:

On Fri, Jan 19, 2024, 2:07 PM Thomas Schmitt <scdbackup@gmx.net <mailto:scdbackup@gmx.net>> wrote:

.....

(Ok, C causes scars on the programmer's self esteem. But what does not
kill me makes me just stronger. I'm a vim user.)

OK I'll mention that to my psychiatrist :-)
But the C programmers I knew were either really nice guys if they wrote
C on unix, or real toads if they wrote C for DOS/Windows. YMMV

I took one look at a dos c-compiler and ran for the hills. Never ever
saw such a busted language interface. Totally, absolutely unusable using
the K&R manual for reference.

Have a nice day :)

Thomas

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-01-19, David Wright <deblis@lionunicorn.co.uk> wrote:

On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote:

Greg Wooledge <greg@wooledge.org> wrote:

I won, and you lost

There shouldn't be a comma in that sentence, in English. There is in
the closely related expression "I won, you lost."

That's rather proscriptive. "I won and you lost." and
"I won, and you lost." are two different sentences.

AFAIK, "you lost" is an independent clause and should be separated from
the independent clause that precedes it with a comma before the
coordinating conjunction.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, Jan 20, 2024 at 05:09:58PM -0000, Curt wrote:

On 2024-01-19, David Wright <deblis@lionunicorn.co.uk> wrote:

On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote:

Greg Wooledge <greg@wooledge.org> wrote:

I won, and you lost

There shouldn't be a comma in that sentence, in English. There is in
the closely related expression "I won, you lost."

That's rather proscriptive. "I won and you lost." and
"I won, and you lost." are two different sentences.

AFAIK, "you lost" is an independent clause and should be separated from
the independent clause that precedes it with a comma before the
coordinating conjunction.

Regardless of which grammar rules are right, wrong, or optional, the point
of this is that parsing natural language text is *stupidly difficult*.
A person who has to ask why "grep -c" doesn't count the number of commas
in a single line of text probably isn't able to take on this quest.

Any serious inquiries about natural language parsing should be directed
to an appropriate artificial intelligence mailing list instead of this one.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-01-20, Greg Wooledge <greg@wooledge.org> wrote:

Regardless of which grammar rules are right, wrong, or optional, the point
of this is that parsing natural language text is *stupidly difficult*.
A person who has to ask why "grep -c" doesn't count the number of commas
in a single line of text probably isn't able to take on this quest.

I can see why parsing natural language may be difficult, but not why
counting commas should be particularly difficult.

Any serious inquiries about natural language parsing should be directed
to an appropriate artificial intelligence mailing list instead of this one.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat, 20 Jan 2024, Greg Wooledge wrote:

On Sat, Jan 20, 2024 at 05:09:58PM -0000, Curt wrote:

On 2024-01-19, David Wright <deblis@lionunicorn.co.uk> wrote:

On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote: >>>> Greg Wooledge <greg@wooledge.org> wrote:

I won, and you lost

There shouldn't be a comma in that sentence, in English. There is in
the closely related expression "I won, you lost."

That's rather proscriptive. "I won and you lost." and
"I won, and you lost." are two different sentences.

AFAIK, "you lost" is an independent clause and should be separated from
the independent clause that precedes it with a comma before the
coordinating conjunction.

Regardless of which grammar rules are right, wrong, or optional, the point
of this is that parsing natural language text is *stupidly difficult*.
A person who has to ask why "grep -c" doesn't count the number of commas
in a single line of text probably isn't able to take on this quest.

Any serious inquiries about natural language parsing should be directed
to an appropriate artificial intelligence mailing list instead of this one.

mr wooledge makes a valid point
if an ignorant person such as myself tries to parse his advice i get
unless you're a super brilliant egghead you shouldn't bother to try

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sat 20 Jan 2024 at 17:09:58 (-0000), Curt wrote:

On 2024-01-19, David Wright <deblis@lionunicorn.co.uk> wrote:

On Fri 19 Jan 2024 at 17:25:10 (+0000), debian-user@howorth.org.uk wrote:

Greg Wooledge <greg@wooledge.org> wrote:

I won, and you lost

There shouldn't be a comma in that sentence, in English. There is in
the closely related expression "I won, you lost."

That's rather proscriptive. "I won and you lost." and
"I won, and you lost." are two different sentences.

AFAIK, "you lost" is an independent clause and should be separated from
the independent clause that precedes it with a comma before the
coordinating conjunction.

✁✁✁✁

Definition of Coordinating Conjunctions

Coordinating conjunctions join grammatically similar elements
(two nouns, two verbs, two modifiers, two independent clauses):

and
or
nor
so
but
for
yet

How to punctuate coordinating conjunctions

When a coordinating conjunction joins two independent clauses,
a comma is used before the coordinating conjunction
(unless the two independent clauses are very short).

✃✃✃✃

https://writing.wisc.edu/handbook/grammarpunct/coordconj/

Cheers,
David.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Friday 19 January 2024 09:48:01 pm Nicholas Geovanis wrote:

On Fri, Jan 19, 2024, 2:07 PM Thomas Schmitt <scdbackup@gmx.net> wrote:

.....

(Ok, C causes scars on the programmer's self esteem. But what does not

kill me makes me just stronger. I'm a vim user.)

OK I'll mention that to my psychiatrist :-)
But the C programmers I knew were either really nice guys if they wrote C
on unix, or real toads if they wrote C for DOS/Windows. YMMV

Where does that leave those of us that wrote c for CP/M? :-)

--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, �a critter that can
be killed but can't be tamed. �--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James M Dakin

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/20/24 15:40, Roy J. Tellason, Sr. wrote:

On Friday 19 January 2024 09:48:01 pm Nicholas Geovanis wrote:

On Fri, Jan 19, 2024, 2:07 PM Thomas Schmitt <scdbackup@gmx.net> wrote:

.....

(Ok, C causes scars on the programmer's self esteem. But what does not

kill me makes me just stronger. I'm a vim user.)

OK I'll mention that to my psychiatrist :-)
But the C programmers I knew were either really nice guys if they wrote C
on unix, or real toads if they wrote C for DOS/Windows. YMMV

Where does that leave those of us that wrote c for CP/M? :-)

Excellent question Roy. Can we add os9 and amigados to that list? And
I'll claim we got the job done in half the time and 1/4 of the bugs than
the pc guy's could do it. os9 C was exactly the first k&r without the
bit twiddling and Jeff cooper's SAS/C 6.51 was C89 or better 5 years
before the C-89 book by K&R. And ARexx beat them both.

Take care ny friend.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Roy J. Tellason writes:

Where does that leave those of us that wrote c for CP/M?

Or for MTS?
--
John Hasler
john@sugarbit.com
Elmwood, WI USA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Roy J. Tellason writes:

Where does that leave those of us that wrote c for CP/M?

I wrote:

Or for MTS?

Gene writes:

That, i've not heard of John, please expand.

Michigan Terminal System. A multi-user OS running on the Amdahl 470V/6
at the University of Michigan.
--
John Hasler
john@sugarbit.com
Elmwood, WI USA

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/20/24 19:02, John Hasler wrote:

Roy J. Tellason writes:

Where does that leave those of us that wrote c for CP/M?

Or for MTS?

That, i've not heard of John, please expand.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 1/20/24 19:28, John Hasler wrote:

Roy J. Tellason writes:

Where does that leave those of us that wrote c for CP/M?

I wrote:

Or for MTS?

Gene writes:

That, i've not heard of John, please expand.

Michigan Terminal System. A multi-user OS running on the Amdahl 470V/6
at the University of Michigan.

Thanks John. I have heard of Amdahl, but it was decades ago.

Cheers, Gene Heskett.
--
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author, 1940)
If we desire respect for the law, we must first make the law respectable.
- Louis D. Brandeis

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Sun Jan 21 10:12:00 2024 John Hasler <john@sugarbit.com> wrote:

Roy J. Tellason writes:

Where does that leave those of us that wrote c for CP/M?

I wrote:

Or for MTS?

Gene writes:

That, i've not heard of John, please expand.

Michigan Terminal System. A multi-user OS running on the Amdahl
470V/6 at the University of Michigan.

It goes back well before that (or even C, for that matter).
At the end of 1968, when I was a freshman at the University
of B.C., they replaced their IBM 7044 with a 360/67.
It ran MTS from day one.

I've never programmed C on a mainframe. It sounds weird.

--
/~\ Charlie Gibbs | You can't save the earth
\ / <cgibbs@kltpzyxm.invalid> | unless you're willing to
X I'm really at ac.dekanfrus | make other people sacrifice.
/ \ if you read it the right way. | -- Dogbert the green consultant

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)