Pausing screen?

[Bill Reid]

[... console windows closing after running a console app from IDE ...]

Yes, it would be possible for any IDE to create a
special console for a "character mode" application,
that just raises the question: what happens when you
run the application outside of the IDE?  Does it
behave the way you want, or the users think it
should?

The program behaves exactly the same, regardless of whether the console
windows disappears or not after the program exits. That behavior is not part
of the program's behavior.

EXACTLY...so what's your point?

And who says that a "special console" is being created in this scenario?
There is absolutely nothing "special" about this console to make it
different from any other console.

It is a very "special" console because the IDE is creating
it for it's own purposes, rather than the operating system
creating it for the program itself...

So, you're saying that the programmer should write a special version of the
program which waits for the user to do something before exiting, so he can
see the output when run from the IDE, and then make a new executable for the
end-users to use?

No, I'm pretty sure I was pretty clear that the programmer
should write the application the way he/she wants it to appear
to the user...to that end, the Microslop Whussual Stupido
is doing the programmer no favors by creating a "special"
console that creates a false impression of how the
program will actually work "in the field"...

Why not just have the IDE cause a "press any key to continue" prompt to
appear after the program exits, and before the window goes away?

It's fine, except to the extent it violates the above...

 

[robertwessel2]

No, I'm pretty sure I was pretty clear that the programmer
should write the application the way he/she wants it to appear
to the user...to that end, the Microslop Whussual Stupido
is doing the programmer no favors by creating a "special"
console that creates a false impression of how the
program will actually work "in the field"...

Of course, having the console window disappear is exactly what usually
happens if you launch the program in such a way that a new console
window is created. For example, by double-clicking on the executable
in Explorer, or entering a command line from the Start/Run prompt.

But having the default (or at the very least optional) behavior to be
leaving the console window open, would definitely be more useful.

 

[Bill Reid]

Of course, having the console window disappear is exactly what usually
happens if you launch the program in such a way that a new console
window is created.  For example, by double-clicking on the executable
in Explorer, or entering a command line from the Start/Run prompt.

But having the default (or at the very least optional) behavior to be
leaving the console window open, would definitely be more useful.

To who? The programmer? Are you, the programmer, using
something like printf() as a poor (read: "stupid") man's
debugger, thus you want to see output that you, the programmer,
never intends the user to see? Why not just set a breakpoint,
which, for even the most brain-dead IDE, is pretty simple
and straightforward, and look at the variable under
question in the debugger?

On the other hand, if you, the programmer, are using
the "console" as the user interface, you definitely
want to see how that appears to the user...and if the
IDE creates a "false" console that the user will not
experience, you, the programmer, have been severely
misled...

 

[Seebs]

To who? The programmer? Are you, the programmer, using
something like printf() as a poor (read: "stupid") man's
debugger, thus you want to see output that you, the programmer,
never intends the user to see?

Having done both debugger-debugging and printf-debugging, I find them
suited to very different kinds of tasks.

For sporadic failures, comprehensive logging can be a lot more useful
than trying to step through things. If nothing else, it can give me
a very clear picture of where to start looking. I really like being
able to look at a log after the fact, without having to know in advance
that I want to run under the debugger.

-s

 

[robertwessel2]

To who?  The programmer?  Are you, the programmer, using
something like printf() as a poor (read: "stupid") man's
debugger, thus you want to see output that you, the programmer,
never intends the user to see?  Why not just set a breakpoint,
which, for even the most brain-dead IDE, is pretty simple
and straightforward, and look at the variable under
question in the debugger?

Leaving aside your judgment about the competence of programmers using
debugging tools and techniques other than the One True Method that
*you* know represents ultimate truth, whether or not said technique is
even possible to use in a given situation... I suspect if I'm
littering my program with printfs for debugging, I can probably manage
to add a pause of some sort at program termination.

On the other hand, if you, the programmer, are using
the "console" as the user interface, you definitely
want to see how that appears to the user...and if the
IDE creates a "false" console that the user will not
experience, you, the programmer, have been severely
misled...

Whether or not the disappearing console window presents a "false" view
of reality is an interesting question. As I said it *is* the default
behavior for numerous ways that a console application might get run.
Only when run from a cmd prompt (and only sometimes then), does the
window actually hang around by default. But as I said, it would
certainly be a reasonable option, and quite plausibly the default, for
the debugger. But not always - many non-GUI applications don't really
produce any console output either, having to always close a pointless
window whenever I try to debug a deamon of some sort would be annoying
as well.

 

[Bill Reid]

Leaving aside your judgment about the competence of programmers using
debugging tools and techniques other than the One True Method that
*you* know represents ultimate truth, whether or not said technique is
even possible to use in a given situation...  

Ah, don't leave it aside, I didn't say programmers
who use a lot of screen prints to debug were "incompetent",
just "stupid", because that's the way I feel when I
waste a lot of time typing "printf("%i\n",my_int);"
when all I had to do was just click in the margin
of the source file window to set the breakpoint,
compile/run, and then roll over the variable in question
to see the value...and I feel stupid even though
it is easy to set breakpoints in my stupid IDE,
it seems to be near-impossible to clear them (selecting
"Clear All Breakpoints" seems to make them immortal)...

I suspect if I'm
littering my program with printfs for debugging, I can probably manage
to add a pause of some sort at program termination.

Well, yeah, there you go...

Whether or not the disappearing console window presents a "false" view
of reality is an interesting question.  As I said it *is* the default
behavior for numerous ways that a console application might get run.
Only when run from a cmd prompt (and only sometimes then), does the
window actually hang around by default.  But as I said, it would
certainly be a reasonable option, and quite plausibly the default, for
the debugger.  But not always - many non-GUI applications don't really
produce any console output either, having to always close a pointless
window whenever I try to debug a deamon of some sort would be annoying
as well.

The only point was to do what makes sense for what
you are doing, but that would be the dreaded "common
sense", and you know what they say about "common sense",
and even more so in this group...

 

[Nick Keighley]

Having done both debugger-debugging and printf-debugging, I find them
suited to very different kinds of tasks.

For sporadic failures, comprehensive logging can be a lot more useful
than trying to step through things.  If nothing else, it can give me
a very clear picture of where to start looking.  I really like being
able to look at a log after the fact, without having to know in advance
that I want to run under the debugger.

yes. But I tend to write such logs to files rather thant he console.
Even knowing the last thing the program wes doing before it crashed
can be helpful. Some programs are supposed to run for days or weeks or
even longer.

 

[Nick Keighley]

On 3/30/2010 10:51 AM, Bill Reid wrote:


Do you call a Linux console windows an "MS-DOS command prompt"?  If not, why
do you insist on calling a Windows console window an "MS-DOS command prompt"?

does a linux console window have a superficial resemblance to a MS-DOS
prompt window? Does linux support a DOS-like shell? (knowing linux,
probably yes!)

 

[Andrew Poelstra]

yes. But I tend to write such logs to files rather thant he console.
Even knowing the last thing the program wes doing before it crashed
can be helpful. Some programs are supposed to run for days or weeks or
even longer.

In that case, I usually pipe the output from stdout to tee (and then
grep or sed or whatever, and then tee again) so that I can see the
data as well as having a capture, and also having a filtered capture
if I suspect I know where the problem lies.

 

[Alan Curry]

|
|does a linux console window have a superficial resemblance to a MS-DOS
|prompt window?

Let's see... a console is a tty where kernel messages go. Normally that
wouldn't be in a window, but there is xconsole. However we don't normally try
to run a shell in it. So no.

| Does linux support a DOS-like shell? (knowing linux,
|probably yes!)

A shell that has no job control (including no support for "cmd &" syntax to
put a job in the background and leave it there), does no globbing encouraging
every command apply its own unique interpretation of wildcards, supports
neither functions nor aliases, has no syntax at all for redirecting stderr,
no command substitution, and a quoting system that nobody will ever
understand?

No I think we forgot to implement one of those.

 

[robertwessel2]

|               Does linux support a DOS-like shell? (knowing linux,
|probably yes!)

A shell that has no job control (including no support for "cmd &" syntax to
put a job in the background and leave it there), does no globbing encouraging
every command apply its own unique interpretation of wildcards, supports
neither functions nor aliases, has no syntax at all for redirecting stderr,
no command substitution, and a quoting system that nobody will ever
understand?

No I think we forgot to implement one of those.

Well, just to be picky, "start" will start a background process, and
stderr can be redirected with "2>" (two, greater than). And the Unix
approach of globbing anything that looks like a filename is certainly
wrong much of the time (I'm not saying the DOS/Windows approach is
correct, just that the Unix one isn't either). And while batch files
(and some other stuff) do support a basic form of substitution, it
does, certainly leave a lot to be desired.

 

[Kenny McCormack]

Well, just to be picky, "start" will start a background process, and
stderr can be redirected with "2>" (two, greater than). And the Unix
approach of globbing anything that looks like a filename is certainly
wrong much of the time (I'm not saying the DOS/Windows approach is
correct, just that the Unix one isn't either). And while batch files
(and some other stuff) do support a basic form of substitution, it
does, certainly leave a lot to be desired.

Wrong on all counts. Do try to keep up.

You are talking about CMD.EXE, the command interpreter for NT-family
Windows systems. We were talking about the "MS DOS Command Prompt".

Note that you were almost, sort of, right about "start", in the context
of Windows 95/98 - but note that START is not a built-in command. The
functionality is implemented via an external command ("START.EXE").

--
(This discussion group is about C, ...)

Wrong. It is only OCCASIONALLY a discussion group
about C; mostly, like most "discussion" groups, it is
off-topic Rorsharch revelations of the childhood
traumas of the participants...

 

[robertwessel2]

...


Wrong on all counts.  Do try to keep up.

You are talking about CMD.EXE, the command interpreter for NT-family
Windows systems.  We were talking about the "MS DOS Command Prompt".

Perhaps you should try reading the thread... This subthread clearly
started with a discussion of the Windows command prompt often
misidentified as the "MS-DOS" prompt. And who's this "we" having this
discussion? I don't actually see a post from you in this thread prior
to the above.

 

[Bill Reid]

Use the Debug menu, and click "Start without debugging". That's been a
feature of VS since forever, and it was retained in VSE.

It appears you don't know how to do that, but that didn't stop you from
posting.

Well, I still don't know how to do that, but I did download
Microsoft Visual C++ 2010 Express last night, and sure enough,
no such phony-baloney "console" option exists, and when a
console "solution" (BWHAHAHAHAHAHAHA!!!!) is built in "Release
Mode" and run from the "Debug" menu, the console is NOT
"retained"...

If you read my post again, you'll find that there is very clear text to
the effect that "If you're running from the console", suggesting to all
but the densest amongst us that you start a console and then run your
program from within that console.

And you still are so technically incompetent you can't
even comprehend what Microsoft calls a "console", even
when directed to a clear description of the beast...

No, I'm thinking of the right answer. You, on the other hand, are not
thinking. I suggest you start.

Yeah, sure, whatever, you know the difference between
stupidity and ignorance is ignorance can be cured except
for the stupid...but we already knew that, I just was
amused that Microsoft does NOT apparently offer a
special "console" to mislead both the stupid and the
ignorant, at least for their "freebie" (and apparently
worth every penny!) IDEs...