function system() from stdlib.h

[britzkrieg]

Hi,

I had write a program for Windows OS and put the following line:

system("pause")

that use the "pause" command from DOS to pause the screen until I push
a button. How to get the same result in Linux's bash ?

thanks a lot

[Zack]

On Feb 15, 4:48 pm, "britzkrieg" <[e-mail]:

pause the screen until I push a button.

http://c-faq.com/osdep/waitforkey.html

[santosh]

britzkrieg wrote:

Hi,

I had write a program for Windows OS and put the following line:

system("pause")

that use the "pause" command from DOS to pause the screen until I push
a button. How to get the same result in Linux's bash ?

Why not use getchar() and discard the return value? It's more portable
than executing OS specific commands.

[Chris Dollin]

britzkrieg wrote:

Hi,

I had write a program for Windows OS and put the following line:

system("pause")

that use the "pause" command from DOS to pause the screen until I push
a button. How to get the same result in Linux's bash ?

Well, what /I'd/ do is do

program | more

and not bother doing anything in the code. But if you really want
to wait for a character, why not call:

void waitForRETURN(void)
{
fprintf( stderr, "press RETURN to continue:" );
fflush( stderr );
while (getchar() != '\n') {}
}

Pickier people might want to handle EOF. Prettier people might
want to parametrise with a reason message. Perfectionist people
will probably see five things wrong I won't notice until after
I post, or after my coffee.

--
Chris "problematic hedgehog" Dollin
"The path to the web becomes deeper and wider" - October Project

[santosh]

Chris Dollin wrote:

britzkrieg wrote:

Hi,

I had write a program for Windows OS and put the following line:

system("pause")

that use the "pause" command from DOS to pause the screen until I push
a button. How to get the same result in Linux's bash ?

Well, what /I'd/ do is do

program | more

and not bother doing anything in the code. But if you really want
to wait for a character, why not call:

void waitForRETURN(void)
{
fprintf( stderr, "press RETURN to continue:" );
fflush( stderr );
while (getchar() != '\n') {}
}

Is there a specific reason for doing while( ... ) {} instead of
while( ... ); other than readability? I consider the latter form to be
more readable, but I may be in the minority regarding that.

Pickier people might want to handle EOF. Prettier people might
want to parametrise with a reason message. Perfectionist people
will probably see five things wrong I won't notice until after
I post, or after my coffee.

What if stdin is already at end-of-file, when getchar() is invoked?

[Chris Dollin]

santosh wrote:

Chris Dollin wrote:

>>
void waitForRETURN(void)
{
fprintf( stderr, "press RETURN to continue:" );
fflush( stderr );
while (getchar() != '\n') {}
}

Is there a specific reason for doing while( ... ) {} instead of
while( ... ); other than readability? I consider the latter form to be
more readable, but I may be in the minority regarding that.

Readability. I find `;` to be more missable (and more likely to
be an accident) than {}. One's parsecage may vary.

>Pickier people might want to handle EOF. Prettier people might
want to parametrise with a reason message. Perfectionist people
will probably see five things wrong I won't notice until after
I post, or after my coffee.

What if stdin is already at end-of-file, when getchar() is invoked?

"Pickier people might want to handle EOF."

--
Chris "electric hedgehog" Dollin
"How am I to understand if you won't teach me?" - Trippa, /Falling/

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

santosh wrote:

Chris Dollin wrote:

[...]

void waitForRETURN(void)
{
fprintf( stderr, "press RETURN to continue:" );
fflush( stderr );
while (getchar() != '\n') {}
}

Is there a specific reason for doing while( ... ) {} instead of
while( ... ); other than readability? I consider the latter form to be
more readable, but I may be in the minority regarding that.

There are no benefits other than readability. I'm in the group that
considers {} more readable where a statement without effect is
required. Better yet to me would be a comment, with either form.

while (getchar() != '\n')
/* do nothing */ ;

while (getchar() != '\n')
{ /* do nothing */ }

Pickier people might want to handle EOF. Prettier people might
want to parametrise with a reason message. Perfectionist people
will probably see five things wrong I won't notice until after
I post, or after my coffee.

What if stdin is already at end-of-file, when getchar() is invoked?

Then it may loop forever comparing EOF to '\n' and doing nothing. It's
also possible that EOF is reached during the loop, since input is not
necessarily terminated by a newline character.

[Richard Heathfield]

santosh said:

>
Chris Dollin wrote:

<snip>

>>
void waitForRETURN(void)
{
fprintf( stderr, "press RETURN to continue:" );
fflush( stderr );
while (getchar() != '\n') {}
}

Is there a specific reason for doing while( ... ) {} instead of
while( ... ); other than readability? I consider the latter form to be
more readable, but I may be in the minority regarding that.

Obviously both forms are correct; it's a style issue. Personally, I
prefer

while(...)
{
continue;
}

which is even more verbose. But Chris's version is fine and so is yours.
Some compilers, however, will issue a diagnostic message for your
version, not because it is required but because it is helpful to
newbies who plaster semicolons all over their code in sheer
desperation, to not-quite-newbies who aren't completely sure of their
syntax rules, and even to oldbies - we all tismype occasionally.

>Pickier people might want to handle EOF. [...]

What if stdin is already at end-of-file, when getchar() is invoked?

That makes you a pickier people (which is good, and it's why Chris
specifically covered his back with all those spiky bits).

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

[santosh]

Richard Heathfield wrote:

santosh said:

Chris Dollin wrote:

<snip>

>
void waitForRETURN(void)
{
fprintf( stderr, "press RETURN to continue:" );
fflush( stderr );
while (getchar() != '\n') {}
}

Is there a specific reason for doing while( ... ) {} instead of
while( ... ); other than readability? I consider the latter form to be
more readable, but I may be in the minority regarding that.

Obviously both forms are correct; it's a style issue. Personally, I
prefer

while(...)
{
continue;
}

which is even more verbose. But Chris's version is fine and so is yours.
Some compilers, however, will issue a diagnostic message for your
version, not because it is required but because it is helpful to
newbies who plaster semicolons all over their code in sheer
desperation, to not-quite-newbies who aren't completely sure of their
syntax rules, and even to oldbies - we all tismype occasionally.

Out of curiosity, can you name a compiler that emits this diagnostic?
I haven't encountered it in gcc, even with the -Wall and -Wextra
switches.

[Richard Heathfield]

santosh said:

<snip>

>
Out of curiosity, can you name a compiler that emits this diagnostic?

[for the while(condition); construct]

Not off the top of my head, no.

I just tested it with gcc, and it doesn't seem to do this by default, by
which I mean my usual plethora of bizarre gcc switches.

I could test with Borland and Microsoft, but that would involve effort.
:-)

Maybe it was some lint or other (shrug), or maybe I'm just
disremembering. If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;

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

[Christopher Layne]

britzkrieg wrote:

Hi,

I had write a program for Windows OS and put the following line:

system("pause")

that use the "pause" command from DOS to pause the screen until I push
a button. How to get the same result in Linux's bash ?

thanks a lot

"read"

Literally:

#!/bin/bash
read -p "press enter key when ready"
<whatever else>

Now if it's a modern version of bash and you're commited to being bash
specific:

read -s -n 1 -p "press any key when ready"

Silent echo, 1 char max

[Christopher Layne]

Christopher Layne wrote:

>that use the "pause" command from DOS to pause the screen until I push
a button. How to get the same result in Linux's bash ?

thanks a lot

"read"

Literally:

Also my answer was jsut in general for bash scripts. IF you're trying to
attain the same result on both DOS/Unix platforms, follow the advice already
presented. Definitely do not use system() for this.

[britzkrieg]

Christopher Layne wrote:

#!/bin/bash
read -p "press enter key when ready"
<whatever else>

Now if it's a modern version of bash and you're commited to being bash
specific:

read -s -n 1 -p "press any key when ready"

Silent echo, 1 char max

I haven't test the Christopher's solution yet. But the getchar()
solution isn't work; I dont' know what's going on, but my program get
off without I push a button.

[Chris Dollin]

britzkrieg wrote:

I haven't test the Christopher's solution yet. But the getchar()
solution isn't work; I dont' know what's going on, but my program get
off without I push a button.

Well, we can't see your code, so we can't see what you've done
wrong.

But I /guess/ that you did some input earlier and didn't
eat all of it, so your getchar getted a char without you
having to type any more. Solution: don't leave random input
unread. (I have a small bet with my evil twin that it's your
`scanf` that's the root of the problem.)

--
Chris "fgets!" Dollin
The "good old days" used to be much better.

[CBFalconer]

Chris Dollin wrote:

santosh wrote:

.... snip ...

>>
Is there a specific reason for doing while( ... ) {} instead of
while( ... ); other than readability? I consider the latter form
to be more readable, but I may be in the minority regarding that.

Readability. I find `;` to be more missable (and more likely to
be an accident) than {}. One's parsecage may vary.

Try:

while (side_effects) continue;

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Ben Bacarisse]

Richard Heathfield <rj*@see.sig.invalidwrites:

santosh said:

<snip>

>>
Out of curiosity, can you name a compiler that emits this diagnostic?

[for the while(condition); construct]

Not off the top of my head, no.

and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>

If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;

The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;

--
Ben.

[santosh]

Ben Bacarisse wrote:

Richard Heathfield <rj*@see.sig.invalidwrites:

santosh said:

<snip>

>
Out of curiosity, can you name a compiler that emits this diagnostic?

[for the while(condition); construct]

Not off the top of my head, no.

and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>

If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;

The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;

Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

santosh wrote:

Ben Bacarisse wrote:

Richard Heathfield <rj*@see.sig.invalidwrites:

santosh said:
>
<snip>
>>
>Out of curiosity, can you name a compiler that emits this diagnostic?
>
[for the while(condition); construct]
>
Not off the top of my head, no.

and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>

If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;

The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;

Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.

The compiler must behave as if comments are gone, but that only means
they have no effect noticeable from a strictly conforming program.
They may cause other effects, including the number and types of
warnings, so long as those warnings are not required by the standard.
For a related example, at least one compiler warns for

switch (i)
{
case 0:
a();
case 1:
b();
}

but does not for

switch (i)
{
case 0:
a();
/* FALLTHROUGH */
case 1:
b();
}

(Okay, the version I'm using warns for both. That's a bug, and one
which is not present in the last official release, as far as I can
tell.)

[santosh]

Harald van Dijk wrote:

santosh wrote:

Ben Bacarisse wrote:

Richard Heathfield <rj*@see.sig.invalidwrites:
>
santosh said:

<snip>
>
Out of curiosity, can you name a compiler that emits this diagnostic?

[for the while(condition); construct]

Not off the top of my head, no.
>
and neither can I, but I can confirm the exited once. Might have been
an old Borland one.
>
<snip>
If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;
>
The one I remember shut up with a comment and I still often write:
>
while (condition) /* do nothing */;

Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.

The compiler must behave as if comments are gone, but that only means
they have no effect noticeable from a strictly conforming program.
They may cause other effects, including the number and types of
warnings, so long as those warnings are not required by the standard.

I personally think it's odd for the compiler to be influenced by
comments. I don't see why they should have any effect on code around
them.

For a related example, at least one compiler warns for
switch (i)
{
case 0:
a();
case 1:
b();
}

but does not for

switch (i)
{
case 0:
a();
/* FALLTHROUGH */
case 1:
b();
}

(Okay, the version I'm using warns for both. That's a bug, and one
which is not present in the last official release, as far as I can
tell.)

How so? If it warns at all, I'd expect it to warn for both, regardless
of the intervening comment.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

santosh wrote:

Harald van Dijk wrote:

santosh wrote:

Ben Bacarisse wrote:
Richard Heathfield <rj*@see.sig.invalidwrites:

santosh said:
>
<snip>
>>
>Out of curiosity, can you name a compiler that emits this diagnostic?
>
[for the while(condition); construct]
>
Not off the top of my head, no.

and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>
If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;

The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;
>
Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.

The compiler must behave as if comments are gone, but that only means
they have no effect noticeable from a strictly conforming program.
They may cause other effects, including the number and types of
warnings, so long as those warnings are not required by the standard.

I personally think it's odd for the compiler to be influenced by
comments. I don't see why they should have any effect on code around
them.

For cases such as the below, it's the only way I can think of that's
both readable and guaranteed not to affect the runtime behaviour of
any strictly conforming program.

For a related example, at least one compiler warns for
switch (i)
{
case 0:
a();
case 1:
b();
}

but does not for

switch (i)
{
case 0:
a();
/* FALLTHROUGH */
case 1:
b();
}

(Okay, the version I'm using warns for both. That's a bug, and one
which is not present in the last official release, as far as I can
tell.)

How so? If it warns at all, I'd expect it to warn for both, regardless
of the intervening comment.

It's a bug because the behaviour of warning only for the first code
sample is what's intended, regardless of which behaviour is better.

[Radamanthe]

santosh wrote:

Harald van Dijk wrote:

>santosh wrote:

>>Ben Bacarisse wrote:
Richard Heathfield <rj*@see.sig.invalidwrites:

santosh said:
>
<snip>
>Out of curiosity, can you name a compiler that emits this diagnostic?
[for the while(condition); construct]
>
Not off the top of my head, no.
and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>
If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;
The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;
Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.

The compiler must behave as if comments are gone, but that only means
they have no effect noticeable from a strictly conforming program.
They may cause other effects, including the number and types of
warnings, so long as those warnings are not required by the standard.

I personally think it's odd for the compiler to be influenced by
comments. I don't see why they should have any effect on code around
them.

>For a related example, at least one compiler warns for
switch (i)
{
case 0:
a();
case 1:
b();
}

but does not for

switch (i)
{
case 0:
a();
/* FALLTHROUGH */
case 1:
b();
}

(Okay, the version I'm using warns for both. That's a bug, and one
which is not present in the last official release, as far as I can
tell.)

How so? If it warns at all, I'd expect it to warn for both, regardless
of the intervening comment.

These are just warnings. Actually, this does not change the generated
code at all. I suppose the compiler decides not to warn when there is a
comment before the following case, because an experienced programmer
using this behavior of switch/case generally puts a comment there, just
to inform that the absence of the break statement is intentional (and
not an obvious bug as it is generally). Exploiting this behaviour is
very uncommon practice, so best to warn the reader.

Anyway, I don't think this is a "so wise" feature of the compiler. Lots
of people may have the habit to put comments above cases, thus
forgetting a break would almost certainly pass silently.
--
R.N.

[=?utf-8?B?SGFyYWxkIHZhbiBExLNr?=]

Radamanthe wrote:

santosh wrote:

Harald van Dijk wrote:

santosh wrote:
Ben Bacarisse wrote:
Richard Heathfield <rj*@see.sig.invalidwrites:

santosh said:

<snip>
Out of curiosity, can you name a compiler that emits this diagnostic?
[for the while(condition); construct]

Not off the top of my head, no.
and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>
If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;
The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;
Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.
The compiler must behave as if comments are gone, but that only means
they have no effect noticeable from a strictly conforming program.
They may cause other effects, including the number and types of
warnings, so long as those warnings are not required by the standard.

I personally think it's odd for the compiler to be influenced by
comments. I don't see why they should have any effect on code around
them.

For a related example, at least one compiler warns for
switch (i)
{
case 0:
a();
case 1:
b();
}

but does not for

switch (i)
{
case 0:
a();
/* FALLTHROUGH */
case 1:
b();
}

(Okay, the version I'm using warns for both. That's a bug, and one
which is not present in the last official release, as far as I can
tell.)

How so? If it warns at all, I'd expect it to warn for both, regardless
of the intervening comment.

These are just warnings. Actually, this does not change the generated
code at all. I suppose the compiler decides not to warn when there is a
comment before the following case, because an experienced programmer
using this behavior of switch/case generally puts a comment there, just
to inform that the absence of the break statement is intentional (and
not an obvious bug as it is generally). Exploiting this behaviour is
very uncommon practice, so best to warn the reader.

Anyway, I don't think this is a "so wise" feature of the compiler. Lots
of people may have the habit to put comments above cases, thus
forgetting a break would almost certainly pass silently.

Only comments containing the word FALLTHROUGH or FALLTHRU are supposed
to cause the warning to be skipped, not just any random comment.

[Richard Tobin]

In article <11*********************@a75g2000cwd.googlegroups. com>,
santosh <sa*********@gmail.comwrote:

>switch (i)
{
case 0:
a();
/* FALLTHROUGH */
case 1:
b();
}

>How so? If it warns at all, I'd expect it to warn for both, regardless
of the intervening comment.

It was traditional for "lint" to use such comments, so I'm not
surprised that a compiler does. Presumably this was one of the
intended uses of pragmas.

-- Richard

--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Radamanthe]

Harald van Dijk wrote:

Radamanthe wrote:

>santosh wrote:

>>Harald van Dijk wrote:
santosh wrote:
Ben Bacarisse wrote:
>Richard Heathfield <rj*@see.sig.invalidwrites:
>>
>>santosh said:
>>>
>><snip>
>>>Out of curiosity, can you name a compiler that emits this diagnostic?
>>[for the while(condition); construct]
>>>
>>Not off the top of my head, no.
>and neither can I, but I can confirm the exited once. Might have been
>an old Borland one.
>>
><snip>
>> If so, then I am also disremembering that one way to
>>quell the warning was to add a space: while(condition) ;
>The one I remember shut up with a comment and I still often write:
>>
> while (condition) /* do nothing */;
Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.
The compiler must behave as if comments are gone, but that only means
they have no effect noticeable from a strictly conforming program.
They may cause other effects, including the number and types of
warnings, so long as those warnings are not required by the standard.
I personally think it's odd for the compiler to be influenced by
comments. I don't see why they should have any effect on code around
them.

For a related example, at least one compiler warns for
switch (i)
{
case 0:
a();
case 1:
b();
}

but does not for

switch (i)
{
case 0:
a();
/* FALLTHROUGH */
case 1:
b();
}

(Okay, the version I'm using warns for both. That's a bug, and one
which is not present in the last official release, as far as I can
tell.)
How so? If it warns at all, I'd expect it to warn for both, regardless
of the intervening comment.

These are just warnings. Actually, this does not change the generated
code at all. I suppose the compiler decides not to warn when there is a
comment before the following case, because an experienced programmer
using this behavior of switch/case generally puts a comment there, just
to inform that the absence of the break statement is intentional (and
not an obvious bug as it is generally). Exploiting this behaviour is
very uncommon practice, so best to warn the reader.

Anyway, I don't think this is a "so wise" feature of the compiler. Lots
of people may have the habit to put comments above cases, thus
forgetting a break would almost certainly pass silently.

Only comments containing the word FALLTHROUGH or FALLTHRU are supposed
to cause the warning to be skipped, not just any random comment.

Well, ok.. this is not perfect though, and this could not be anyway. I
can't bet it won't ever happen to me to forget a break before a
commented case with "fallth(rough|thru)" inside it :) So it will
certainly happen to some people in this world. Too bad for him(her).
--
R.N.

[Keith Thompson]

"santosh" <sa*********@gmail.comwrites:

Ben Bacarisse wrote:

>Richard Heathfield <rj*@see.sig.invalidwrites:

santosh said:
<snip>

Out of curiosity, can you name a compiler that emits this diagnostic?

[for the while(condition); construct]

Not off the top of my head, no.

and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>

If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;

The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;

Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.

The standard doesn't talk about "compilation proper". Comments vanish
in translation phase 3, which is just as much part of "compilation" as
any other phase. A compiler is perfectly free to decide whether or
not to issue an optional diagnostic based on the presence or absence
(or even the contents) of a comment.

But yes, comment deletion is commonly handled in the "preprocessor",
which is often (but not always) a separate program that runs to
completion before the phase that would issue a warning about the
semicolon. And I'd be a bit surprised if a comment really did inhibit
the warning. I find the described behavior counterintuitive. (Some
versions of lint recognize specially formatted comments as
annotations).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[CBFalconer]

santosh wrote:

Ben Bacarisse wrote:

>Richard Heathfield <rj*@see.sig.invalidwrites:

.... snip ...

>>
<snip>

>> If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;

The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;

Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.

Comments are replaced by a blank.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>

"A man who is right every time is not likely to do very much."
-- Francis Crick, co-discover of DNA
"There is nothing more amazing than stupidity in action."
-- Thomas Matthews

[Keith Thompson]

CBFalconer <cb********@yahoo.comwrites:

santosh wrote:

[...]

>Interesting, seeing as, logically, comments are not supposed to be
present at compilation proper.

Comments are replaced by a blank.

And thus are not present (assuming a certain intepretation of
"compilation proper").

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Ben Bacarisse]

Keith Thompson <ks***@mib.orgwrites:

"santosh" <sa*********@gmail.comwrites:

>Ben Bacarisse wrote:

>>Richard Heathfield <rj*@see.sig.invalidwrites:
santosh said:
<snip>

Out of curiosity, can you name a compiler that emits this diagnostic?

[for the while(condition); construct]

Not off the top of my head, no.

and neither can I, but I can confirm the exited once. Might have been
an old Borland one.

<snip>
If so, then I am also disremembering that one way to
quell the warning was to add a space: while(condition) ;

The one I remember shut up with a comment and I still often write:

while (condition) /* do nothing */;

<snip>

I find the described behavior counterintuitive. (Some
versions of lint recognize specially formatted comments as
annotations).

It certainly was not lint (or similar). It is possible that this is a
false memory but the code I wrote at about that time (~10 years ago)
has a comment in every empty while.

I have tried to fond some evidence (or even the name of the compiler
concerned) and failed, so this is in danger of becoming no more than a
rumour.

--
Ben.

[jaysome]

On 16 Feb 2007 03:04:06 -0800, "santosh" <sa*********@gmail.com>
wrote:

>Richard Heathfield wrote:

>santosh said:

Chris Dollin wrote:

<snip>

>>
void waitForRETURN(void)
{
fprintf( stderr, "press RETURN to continue:" );
fflush( stderr );
while (getchar() != '\n') {}
}

Is there a specific reason for doing while( ... ) {} instead of
while( ... ); other than readability? I consider the latter form to be
more readable, but I may be in the minority regarding that.

Obviously both forms are correct; it's a style issue. Personally, I
prefer

while(...)
{
continue;
}

which is even more verbose. But Chris's version is fine and so is yours.
Some compilers, however, will issue a diagnostic message for your
version, not because it is required but because it is helpful to
newbies who plaster semicolons all over their code in sheer
desperation, to not-quite-newbies who aren't completely sure of their
syntax rules, and even to oldbies - we all tismype occasionally.

Out of curiosity, can you name a compiler that emits this diagnostic?
I haven't encountered it in gcc, even with the -Wall and -Wextra
switches.

FWIW, PC-lint issues this warning:

Info 722: Suspicious use of ;

Regards
--
jay

[Randy Howard]

On Fri, 16 Feb 2007 07:41:41 -0600, Chris Dollin wrote
(in article <er**********@murdoch.hpl.hp.com>):

britzkrieg wrote:

>I haven't test the Christopher's solution yet. But the getchar()
solution isn't work; I dont' know what's going on, but my program get
off without I push a button.

Well, we can't see your code, so we can't see what you've done
wrong.

But I /guess/ that you did some input earlier and didn't
eat all of it, so your getchar getted a char without you
having to type any more. Solution: don't leave random input
unread. (I have a small bet with my evil twin that it's your
`scanf` that's the root of the problem.)

Made up statistic, but worthy of consideration anyway:

90% of all programs that call scanf() have a bug rooted in the use of
scanf().

:-)
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw

[Richard Bos]

CBFalconer <cb********@yahoo.comwrote:

Chris Dollin wrote:

santosh wrote:

Is there a specific reason for doing while( ... ) {} instead of
while( ... ); other than readability? I consider the latter form
to be more readable, but I may be in the minority regarding that.

Readability. I find `;` to be more missable (and more likely to
be an accident) than {}. One's parsecage may vary.

Try:

while (side_effects) continue;

That's a good one; another I like is putting the semi-colon on a line of
its own. That's unusual enough to be clear. Like this:

while (side_effects--)
;

Richard

[Chris Dollin]

CBFalconer wrote:

Chris Dollin wrote:

>santosh wrote:

... snip ...

>>>
Is there a specific reason for doing while( ... ) {} instead of
while( ... ); other than readability? I consider the latter form
to be more readable, but I may be in the minority regarding that.

Readability. I find `;` to be more missable (and more likely to
be an accident) than {}. One's parsecage may vary.

Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

[1] Or `endrepeat`, as in `repeat A while B do C endrepeat`.

--
Chris "electric hedgehog" Dollin
"- born in the lab under strict supervision -", - Magenta, /Genetesis/

[Keith Thompson]

Chris Dollin <ch**********@hp.comwrites:

CBFalconer wrote:

[...]

>Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

Of course you can change it:

#define endwhile }
#define endif }
....

(But don't expect anyone to read your code if you commit such an
abomination.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.

[Richard Bos]

Chris Dollin <ch**********@hp.comwrote:

CBFalconer wrote:

Chris Dollin wrote:

Readability. I find `;` to be more missable (and more likely to
be an accident) than {}. One's parsecage may vary.

Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

[1] Or `endrepeat`, as in `repeat A while B do C endrepeat`.

If you want to hack on the Bourne shell source, you know where to find
it. Yuck.

Richard

[Default User]

Richard Bos wrote:

CBFalconer <cb********@yahoo.comwrote:

Chris Dollin wrote:

santosh wrote:
>
>Is there a specific reason for doing while( ... ) {} instead of
>while( ... ); other than readability? I consider the latter form
>to be more readable, but I may be in the minority regarding that.
>
Readability. I find `;` to be more missable (and more likely to
be an accident) than {}. One's parsecage may vary.

Try:

while (side_effects) continue;

That's a good one; another I like is putting the semi-colon on a line
of its own. That's unusual enough to be clear. Like this:

while (side_effects--)
;

The first C coding standard I worked under mandated/suggested that. It
works pretty well, although these days I tend to use empty braces:

while (side_effects--)
{
}

Brian

[Simon Biber]

Christopher Layne wrote:

britzkrieg wrote:

>Hi,

I had write a program for Windows OS and put the following line:

system("pause")

that use the "pause" command from DOS to pause the screen until I push
a button. How to get the same result in Linux's bash ?

thanks a lot

"read"

Literally:

#!/bin/bash
read -p "press enter key when ready"
<whatever else>

Now if it's a modern version of bash and you're commited to being bash
specific:

read -s -n 1 -p "press any key when ready"

Silent echo, 1 char max

If you want to exactly duplicate MS-DOS's pause command:

system("read -s -n 1 -p \"Press any key to continue . . . \"; echo;");

The extra echo command is necessary as pause adds a newline after you
press a key.

--
Simon.

[Chris Dollin]

Richard Bos wrote:

Chris Dollin <ch**********@hp.comwrote:

>CBFalconer wrote:

Chris Dollin wrote:

>Readability. I find `;` to be more missable (and more likely to
be an accident) than {}. One's parsecage may vary.

Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

[1] Or `endrepeat`, as in `repeat A while B do C endrepeat`.

If you want to hack on the Bourne shell source, you know where to find
it. Yuck.

I don't. Why would you think I did?

(Yes, I /know/ that the Bourne shell was writting with algolifying
macros. C isn't built that way, and I can't change it, and I
have no interest in trying to fake a better-according-to-me
syntax using macros, for all the reasons behind your and
Keith's expressions of distaste. To get a more pleasing grammar
I go to -- or implement -- other languages.)

--
Chris "electric hedgehog" Dollin
There' no hortage of vowel on Uenet.

[Richard Bos]

Chris Dollin <ch**********@hp.comwrote:

Richard Bos wrote:

Chris Dollin <ch**********@hp.comwrote:

CBFalconer wrote:

Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

[1] Or `endrepeat`, as in `repeat A while B do C endrepeat`.

If you want to hack on the Bourne shell source, you know where to find
it. Yuck.

I don't. Why would you think I did?

If you want the origin for a standard hacker idiom, you know where to
find it.

(Yes, I /know/ that the Bourne shell was writting with algolifying
macros. C isn't built that way, and I can't change it, and I
have no interest in trying to fake a better-according-to-me
syntax using macros, for all the reasons behind your and
Keith's expressions of distaste.

No, you don't, because at least one of the reasons behind my distaste is
that I find the endrepeat grammar _not_ better, but overly voluble and
frequently less legible.

Richard

[Chris Dollin]

Richard Bos wrote:

Chris Dollin <ch**********@hp.comwrote:

>Richard Bos wrote:

Chris Dollin <ch**********@hp.comwrote:

CBFalconer wrote:

Try:

while (side_effects) continue;

I shan't /try/ it; while I can see that some would find it OK,
it looks like an abomination to me. Of course what I'd /prefer/
is `endwhile` [1] ... but C Is Not Built That Way And I Can't
Change It.

[1] Or `endrepeat`, as in `repeat A while B do C endrepeat`.

If you want to hack on the Bourne shell source, you know where to find
it. Yuck.

I don't. Why would you think I did?

If you want the origin for a standard hacker idiom, you know where to
find it.

That's not an answer.

>(Yes, I /know/ that the Bourne shell was writting with algolifying
macros. C isn't built that way, and I can't change it, and I
have no interest in trying to fake a better-according-to-me
syntax using macros, for all the reasons behind your and
Keith's expressions of distaste.

No, you don't, because at least one of the reasons behind my distaste is
that I find the endrepeat grammar _not_ better, but overly voluble and
frequently less legible.

Ah. Well, it would have helped if you'd said that. Usually when
I've seem people yuck over the Bourne shell its the algolification-
via-macros that's the issue, not the intended syntax. (I'm curious
whether you've seen a language with the repeat-endrepeat syntax,
since the one I know it from is Pop11.)

Grammatical tastes differ.

Um, this is barely topical: if you're bothered to respond, I'll
take email.

--
Chris "electric hedgehog" Dollin
"He's dead, Jim, but not as we know it." Unsaid /Trek/.