Advertisements

Advertisements

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.

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:

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

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?

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.

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

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:

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

Richard Heathfield <> writes:
> 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) ;

Ben Bacarisse wrote:
> Richard Heathfield <> writes:
>
> > 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.

santosh wrote:
> Ben Bacarisse wrote:
> > Richard Heathfield <> writes:
> >
> > > 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.)

Harald van DÄ³k wrote:
> santosh wrote:
> > Ben Bacarisse wrote:
> > > Richard Heathfield <> writes:
> > >
> > > > 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.

santosh wrote:
> Harald van DÄ³k wrote:
> > santosh wrote:
> > > Ben Bacarisse wrote:
> > > > Richard Heathfield <> writes:
> > > >
> > > > > 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.

Share This Page

Welcome to The Coding Forums!

Welcome to the Coding Forums, the place to chat about anything related to programming and coding languages.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to ask questions about coding or chat with the community and help others.
Sign up now!