function system() from stdlib.h

B

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
 
S

santosh

britzkrieg said:
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.
 
C

Chris Dollin

britzkrieg said:
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.
 
S

santosh

Chris said:
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?
 
C

Chris Dollin

santosh said:
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.
What if stdin is already at end-of-file, when getchar() is invoked?

"Pickier people might want to handle EOF."
 
G

Guest

santosh said:
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 */ }
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.
 
R

Richard Heathfield

santosh said:
Chris Dollin 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.

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

santosh

Richard said:
santosh said:

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

Richard Heathfield

santosh said:

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) ;
 
C

Christopher Layne

britzkrieg said:
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
 
C

Christopher Layne

Christopher said:
"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.
 
B

britzkrieg

Christopher said:
#!/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.
 
C

Chris Dollin

britzkrieg said:
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.)
 
C

CBFalconer

Chris said:
santosh wrote:
.... snip ...

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
 
B

Ben Bacarisse

Richard Heathfield said:
santosh said:

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.

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 */;
 
S

santosh

Ben said:
Richard Heathfield said:
santosh said:

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.

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

Guest

santosh said:
Ben said:
Richard Heathfield said:
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.

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

santosh

Harald said:
santosh said:
Ben said:
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.
 
G

Guest

santosh said:
Harald said:
santosh said:
Ben Bacarisse wrote:

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

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top