Hi all,
Is it possible to prevent Pd from 'detaching' itself from the command
prompt when launched from the command line under Windows?
It is very useful for debugging externals to be able to printf()
things to the command line, but don't seem to be able to do this under
XP.
I'm not a Windows user, so maybe I'm just missing something obvious.
TIA,
Jamie
On Sep 25, 2009, at 3:49 PM, IOhannes m zmölnig wrote:
Jamie Bullock wrote:
Hi all,
Is it possible to prevent Pd from 'detaching' itself from the command prompt when launched from the command line under Windows?
start the pd.com rather than the pd.exe
There is definitely some black magic to it. I find that different
shells will give you different results, like cmd.exe versus the MSYS
rxvt shell, the Cygwin rxvt shell, or Cygwin cmd.exe shell.
.hc
I spent 33 years and four months in active military service and during
that period I spent most of my time as a high class muscle man for Big
Business, for Wall Street and the bankers. - General Smedley Butler
Hans-Christoph Steiner wrote:
On Sep 25, 2009, at 3:49 PM, IOhannes m zmölnig wrote:
start the pd.com rather than the pd.exe
There is definitely some black magic to it. I find that different shells will give you different results, like cmd.exe versus the MSYS rxvt shell, the Cygwin rxvt shell, or Cygwin cmd.exe shell.
in w32 an application is either attached to the console or it is not. this is a compile/link time decision, and not a runtime decision. so therefore the official way to have both is to create 2 separate applications; for legacy reasons it is suggested to use ".com" (being the older app extension for dos) for the console application and ".exe" for windowed applications. if you have both in your path and just call "pd" from the cmdline, CMD would/should(?) usually try .com first,thus you will be default get the console-variant when running from the console (unless of course your explicitely run pd.exe)
there is no black magic involved and i never enccountered any problems with w32 CMD.
everything else (cygwin, mingw) is probably not implementing the cli the way micro$oft imagined the world to be. i don't know about rxvt, but i strongly guess that cygwin's cmd is meant to be a (intendedly better) replacement of the built-in cmd, which makes me think that it should respect behaviour like "immediately returning to prompt or not", in order to not avoid all .bat files ever.
sdmr IOhannes
On Sep 27, 2009, at 8:52 AM, IOhannes m zmölnig wrote:
Hans-Christoph Steiner wrote:
On Sep 25, 2009, at 3:49 PM, IOhannes m zmölnig wrote:
start the pd.com rather than the pd.exe
There is definitely some black magic to it. I find that different shells will give you different results, like cmd.exe versus the MSYS rxvt shell, the Cygwin rxvt shell, or Cygwin cmd.exe shell.
in w32 an application is either attached to the console or it is not. this is a compile/link time decision, and not a runtime decision. so therefore the official way to have both is to create 2 separate applications; for legacy reasons it is suggested to use ".com" (being the older app extension for dos) for the console application and
".exe" for windowed applications. if you have both in your path and just call "pd" from the cmdline, CMD would/should(?) usually try .com first,thus you will be default get the console-variant when running from the console (unless of course your explicitely run pd.exe)there is no black magic involved and i never enccountered any problems with w32 CMD.
everything else (cygwin, mingw) is probably not implementing the cli
the way micro$oft imagined the world to be. i don't know about rxvt, but i strongly guess that cygwin's cmd is meant to be a (intendedly better) replacement of the built-in cmd, which makes me think that it should respect behaviour like "immediately returning to prompt or not", in order to not avoid all .bat files ever.
Hmm, well, in my experience I have not found a reliable way to get
stdout/stderr going to cmd.exe in the same way as UNIX terminal. If
someone could document how, I would greatly appreciate it.
.hc
As we enjoy great advantages from inventions of others, we should be
glad of an opportunity to serve others by any invention of ours; and
this we should do freely and generously. - Benjamin Franklin
-
Hans-Christoph Steiner -
IOhannes m zmölnig -
Jamie Bullock