Hello,
I use Textpad extensively to run perl programs on a Windows machine, both at home (Windows '98 SE) and on campus (Windows 2000 Professional).
I have been able to do nearly everything I want to do -- except read in values from STDIN.
Whenever I run a program that calls for STDIN input, the program just hangs until I stop it.
I can run those programs on the Linux system, so I can still run them somewhere, but I really would like to be able to run them on Windows.
For what I am doing, I would prefer not to read commandline arguements in this particular case (though I often do that for other programs).
Any suggestions as to how I can get Textpad to cooperate with STDIN input?
-- Thanks,
Mary Taffet
How can I use Textpad to read in STDIN values while running
Moderators: AmigoJack, helios, bbadmin, Bob Hansen, MudGuard
-
Bob D
Re: How can I use Textpad to read in STDIN values while runn
This and earlier posts on the same topic seem to have gone unanswered.
I'm taking a Java class with about 20 students, some of whom are fairly new to programming. Many are using Textpad (which was included on the CD that came with the textbook). The instructor requires that a "log" of the user's interaction be included in homework submissions. I'm seeing a lot of the student's struggling to capture this from a DOS window, and if Textpad could help it be a compelling reason to recommend it.
It works find as long as STDIN is not required. However, it appears that as soon as a program tries, it terminates with this message.
...The handle is invalid
Fatal error. Ending Program.
That seems to indicate STDIN is just not available.
I am "evaluating" V 4.3.1 (which came with the text), fiddling with the various options for tool configuration but I've not made any progress. I'm leaning toward the conclusion that this isn't supported as this point.
Also- has anyone got a handle on what the 3 Registers: fields do? I'm guessing they map to the parens in the RegExp above it? Doesn't seem like that would have any bearing on the question at hand.
I'm taking a Java class with about 20 students, some of whom are fairly new to programming. Many are using Textpad (which was included on the CD that came with the textbook). The instructor requires that a "log" of the user's interaction be included in homework submissions. I'm seeing a lot of the student's struggling to capture this from a DOS window, and if Textpad could help it be a compelling reason to recommend it.
It works find as long as STDIN is not required. However, it appears that as soon as a program tries, it terminates with this message.
...The handle is invalid
Fatal error. Ending Program.
That seems to indicate STDIN is just not available.
I am "evaluating" V 4.3.1 (which came with the text), fiddling with the various options for tool configuration but I've not made any progress. I'm leaning toward the conclusion that this isn't supported as this point.
Also- has anyone got a handle on what the 3 Registers: fields do? I'm guessing they map to the parens in the RegExp above it? Doesn't seem like that would have any bearing on the question at hand.
Stdin while running a TextPad tool
I have almost exactly the same problem that Mary does above--I'm running Perl programs within TextPad on a Windows 2000 machine. Works just fine--but I can't input anything from "stdin". In my case, the Perl interpretter treats stdin as always empty, returning empty strings to my Perl program.
I'm going to try to submit an enhancement request on this topic.
It would be great if an authoritative TextPad person could comment on this issue.
I'm going to try to submit an enhancement request on this topic.
It would be great if an authoritative TextPad person could comment on this issue.
-
s_reynisson
- Posts: 940
- Joined: Tue May 06, 2003 1:59 pm
A Good Solution for Some Purposes!
s_reynisson (above) is pointing out that if you do *not* set the "Capture Output" option for the tool that is running your script (e.g., Perl or Java), then when you run the interpreter for the tool TextPad will launch a separate Command Window, and you will be able to type input into the script and view output.
This is an excellent solution for many purposes. It does, however, have some disadvantages. For instance, none of the input or output is available within the TextPad context. It cannot be (as easily) captured, copied, or modified, nor saved to a file, etc., etc.
Still--definitely a good option to keep in mind! Thanks for responding, s_reynisson!
This is an excellent solution for many purposes. It does, however, have some disadvantages. For instance, none of the input or output is available within the TextPad context. It cannot be (as easily) captured, copied, or modified, nor saved to a file, etc., etc.
Still--definitely a good option to keep in mind! Thanks for responding, s_reynisson!
Understanding the Windows limitation on redirecting STDIN
Well, that sounds like a fair challange! But first I'm trying to think through what it means. It is certainly possible to direct keyboard input to a Windows application--I'm typing into an application right now, and TextPad allows input of course. So exactly what is the limitation? Is the problem that a process can't redirect it's own input to a child process?
In any case, just to make sure we're on the same page, (or in the same window!): the goal as I understand it is to be able to have interactive input and output appearing in a TextPad Window, as a result of TextPad: 1) receiving typed input; 2) copying it to one of its windows; PLUS 3) forwarding it to the tool process, and 4) finally capturing output from the tool process and 5) copying that output to the same one of its windows.
Yes?
In any case, just to make sure we're on the same page, (or in the same window!): the goal as I understand it is to be able to have interactive input and output appearing in a TextPad Window, as a result of TextPad: 1) receiving typed input; 2) copying it to one of its windows; PLUS 3) forwarding it to the tool process, and 4) finally capturing output from the tool process and 5) copying that output to the same one of its windows.
Yes?
What's been tried...
Keith, just so I'm not trying to reinvent a wheel that's already been tried, has the technique described in the MSDN article entitled "Creating a Child Process with Redirected Input and Output" already been tried? I know you say you use an anonymous pipe to collect the output--did you find that you can't pipe input to the child process the same way?
-
klangenfarben
- Posts: 11
- Joined: Mon Jan 10, 2005 8:51 pm
- Location: Brattleboro, Vermont, USA
i am quite tired of the civil but insubstantive replies from the technical support here & elsewhere.
The subtext to this thread is that Helios feels that GUI programs do not natively support stdin/stdout/stderr, so that's the end of the story.
There is a long and unhappy history with Helios in this matter and providing an open release for the macro file format.
Helios has done a standup job; I've been using TextPad since v2. I've rarely been asked for a substantial upgrade fee (compare jpsoft.com's Take Command, and they can'yt piping right the way you won't get piping right.
Upon GUI launch a daemon process or, if you're feeling boisterous, provide a service that must be installed and running for the feature to work. Accept the std3 files through an intermediary process THAT THE USER WILL NEVER EVER SEE HEAR OR FEEL is clearly the best coure of action given our knowledge. Do the parsing, do the hard work, stop posting. Hide the temporary results in a 2GB chunk textpad owns upon i installation, and use a memory mapped file to ease the wait.
That's a product description. Put a bounty out on the PM, who has enough tech detail to schdule, and give 2-3 devs two weeks. And yes, that's SERIOUS conversative scheduling. If the PM can't see the light they are hired on for to shine on day 4, on the street with the lot of 'em--no issues in America Erica anymore on that regard, I've got fired from at least 3 SW jobs during which I was top performer and bristly but not grating.
Then, re-issue the bounty.
... but hey, you'll be hailed as the mann who finally delivered what the people wanted! Unfortunately I want to edit my macros...
just get it done
The subtext to this thread is that Helios feels that GUI programs do not natively support stdin/stdout/stderr, so that's the end of the story.
There is a long and unhappy history with Helios in this matter and providing an open release for the macro file format.
Helios has done a standup job; I've been using TextPad since v2. I've rarely been asked for a substantial upgrade fee (compare jpsoft.com's Take Command, and they can'yt piping right the way you won't get piping right.
Upon GUI launch a daemon process or, if you're feeling boisterous, provide a service that must be installed and running for the feature to work. Accept the std3 files through an intermediary process THAT THE USER WILL NEVER EVER SEE HEAR OR FEEL is clearly the best coure of action given our knowledge. Do the parsing, do the hard work, stop posting. Hide the temporary results in a 2GB chunk textpad owns upon i installation, and use a memory mapped file to ease the wait.
That's a product description. Put a bounty out on the PM, who has enough tech detail to schdule, and give 2-3 devs two weeks. And yes, that's SERIOUS conversative scheduling. If the PM can't see the light they are hired on for to shine on day 4, on the street with the lot of 'em--no issues in America Erica anymore on that regard, I've got fired from at least 3 SW jobs during which I was top performer and bristly but not grating.
Then, re-issue the bounty.
... but hey, you'll be hailed as the mann who finally delivered what the people wanted! Unfortunately I want to edit my macros...
just get it done
-
klangenfarben
- Posts: 11
- Joined: Mon Jan 10, 2005 8:51 pm
- Location: Brattleboro, Vermont, USA
"Ideally the feature would work on Win9x as well."
Do not hold this up over under-developed countries & hobbyists. It's as lame a statement as they come. My favorite whereis.exe (cmdline COM file, 1988, excellent at finding files inside ZIPs in 1992) is inoperable due to OS changes, and after some deliberation I found a cmdline GREP that rocked... configurable, versatile... XP SP2 took away the core RAM segent it required.
Three years later & I'm stung but nonetheless fine with it.
Get it done for the XP Vista NT crowd and then see if there's a hue and cry for a second implementation.
Do not hold this up over under-developed countries & hobbyists. It's as lame a statement as they come. My favorite whereis.exe (cmdline COM file, 1988, excellent at finding files inside ZIPs in 1992) is inoperable due to OS changes, and after some deliberation I found a cmdline GREP that rocked... configurable, versatile... XP SP2 took away the core RAM segent it required.
Three years later & I'm stung but nonetheless fine with it.
Get it done for the XP Vista NT crowd and then see if there's a hue and cry for a second implementation.
-
Nicholas Jordan
- Posts: 124
- Joined: Mon Dec 20, 2004 12:33 am
- Location: Central Texas ISO Latin-1
- Contact:
never work
klangenfarben, I like your style .... but you are sending our own to the pavement.
The context of this issue is that most office workers feel that field personnel do not natively deserve tools that work, so that's the end of the story. To this end, any calls into the kernel to do i/o routines on stdin/out/err call into a single-threaded 16 bit instruction stream ( on winne ) and cannot be un-hung by any reasonable coding approach. If you manage to do a fix, you get hired by a massive world empire with no limits to budget or lethargy.
You ( an adroit and knowledgeable coder ) MAY be able to implement a demonstration workaround on a hand-tweaked bench tool, but in practice the fix would result in chaotic episezures within days because of massive replacement of system libraries by commercial traffic for constipation remedies. ( that is just to avoid attracting uninformed traffic - a tech would know the intended metaphor )
This is well known computer science, we will continue to get these requests from winnie, there is no way to redress the matter - if there was, it would have happend by now. It is the oldest battle.
The context of this issue is that most office workers feel that field personnel do not natively deserve tools that work, so that's the end of the story. To this end, any calls into the kernel to do i/o routines on stdin/out/err call into a single-threaded 16 bit instruction stream ( on winne ) and cannot be un-hung by any reasonable coding approach. If you manage to do a fix, you get hired by a massive world empire with no limits to budget or lethargy.
You ( an adroit and knowledgeable coder ) MAY be able to implement a demonstration workaround on a hand-tweaked bench tool, but in practice the fix would result in chaotic episezures within days because of massive replacement of system libraries by commercial traffic for constipation remedies. ( that is just to avoid attracting uninformed traffic - a tech would know the intended metaphor )
This is well known computer science, we will continue to get these requests from winnie, there is no way to redress the matter - if there was, it would have happend by now. It is the oldest battle.
The only dumb question is one you should have asked and didn't.
-
klangenfarben
- Posts: 11
- Joined: Mon Jan 10, 2005 8:51 pm
- Location: Brattleboro, Vermont, USA
never work
"klangenfarben, I like your style .... but you are sending our own to the pavement."
Hardly. I am making a case.
"You ( an adroit and knowledgeable coder ) MAY be able to implement a demonstration workaround on a hand-tweaked bench tool, but in practice the fix would result in chaotic episezures within days because of massive replacement of system libraries by commercial traffic for constipation remedies. ( that is just to avoid attracting uninformed traffic - a tech would know the intended metaphor ) ".
I "MAY" able to do such, but I never implied this was the solution. Lay claim to your own silly ideas, don't involve me.
The solution is simple. Apply The Proxy Pattern. Take a look at JPSoft's Take Command product, which captures STDIO and STDIN as a GUI app.
Hardly. I am making a case.
"You ( an adroit and knowledgeable coder ) MAY be able to implement a demonstration workaround on a hand-tweaked bench tool, but in practice the fix would result in chaotic episezures within days because of massive replacement of system libraries by commercial traffic for constipation remedies. ( that is just to avoid attracting uninformed traffic - a tech would know the intended metaphor ) ".
I "MAY" able to do such, but I never implied this was the solution. Lay claim to your own silly ideas, don't involve me.
The solution is simple. Apply The Proxy Pattern. Take a look at JPSoft's Take Command product, which captures STDIO and STDIN as a GUI app.