Lost stdOut and stdErr handles?
Locked
Lost stdOut and stdErr handles?
 
|
I have an image that seems to no longer be able to write to stdout or stderr. It most definitely was doing that at one time, but now none of the redirection works, however I am seeing actual files called "stdout" and "stderr" in the image directory with output from all of my running images written on top of each other -- unreadable.
Just to make sure it wasn't something in my OS, I tried another image and writing to stdout works fine. I'd like to stay in this image if I can, is there some way to "reset" things back to normal? I poked around in the related FileStream methods but didn't see anything quick and obvious..
|
Re: Lost stdOut and stdErr handles?
|
|
On Tue, Apr 02, 2013 at 07:53:06PM -0500, Chris Muller wrote:
> I have an image that seems to no longer be able to write to stdout or > stderr. It most definitely was doing that at one time, but now none of the > redirection works, however I am seeing actual files called "stdout" and > "stderr" in the image directory with output from all of my running images > written on top of each other -- unreadable. > > Just to make sure it wasn't something in my OS, I tried another image and > writing to stdout works fine. > > I'd like to stay in this image if I can, is there some way to "reset" > things back to normal? I poked around in the related FileStream methods > but didn't see anything quick and obvious.. You can probably just nil out the Stdout Stderr Stdin class variables in FileStream, and I expect that everything will return to normal once reinitialized. And of course you can always use the old standby: OSProcess thisOSProcess stdOut OSProcess thisOSProcess stdErr OSProcess thisOSProcess stdIn Dave |
Re: Lost stdOut and stdErr handles?
|
|
Thank you Dave. Those variables were already nil but I did find something.. Yesterday I had received an error, "stdout is closed" and so, perplexed but in need of moving forward at that time, I went ahead and put a call to #ensureOpen prior to each write to stdout and stderr. I removed that again today and, at least for a quick test, all seems to be fine again. I'm not sure why I got that error about it being closed before.. On Tue, Apr 2, 2013 at 8:05 PM, David T. Lewis <[hidden email]> wrote:
|
Re: Lost stdOut and stdErr handles?
|
|
On Tue, Apr 02, 2013 at 08:18:56PM -0500, Chris Muller wrote:
> Thank you Dave. Those variables were already nil but I did find > something.. Yesterday I had received an error, "stdout is closed" and so, > perplexed but in need of moving forward at that time, I went ahead and put > a call to #ensureOpen prior to each write to stdout and stderr. Ah, that would do it. FileStream stdout name ==> #stdout And if the stream has been closed, sending #ensureOpen will open a new file named 'stdout' in the default directory. Dave > > I removed that again today and, at least for a quick test, all seems to be > fine again. I'm not sure why I got that error about it being closed > before.. > > > On Tue, Apr 2, 2013 at 8:05 PM, David T. Lewis <[hidden email]> wrote: > > > On Tue, Apr 02, 2013 at 07:53:06PM -0500, Chris Muller wrote: > > > I have an image that seems to no longer be able to write to stdout or > > > stderr. It most definitely was doing that at one time, but now none of > > the > > > redirection works, however I am seeing actual files called "stdout" and > > > "stderr" in the image directory with output from all of my running images > > > written on top of each other -- unreadable. > > > > > > Just to make sure it wasn't something in my OS, I tried another image and > > > writing to stdout works fine. > > > > > > I'd like to stay in this image if I can, is there some way to "reset" > > > things back to normal? I poked around in the related FileStream methods > > > but didn't see anything quick and obvious.. > > > > You can probably just nil out the Stdout Stderr Stdin class variables in > > FileStream, and I expect that everything will return to normal once > > reinitialized. > > > > And of course you can always use the old standby: > > > > OSProcess thisOSProcess stdOut > > OSProcess thisOSProcess stdErr > > OSProcess thisOSProcess stdIn > > > > Dave > > > > > > > |
Re: Lost stdOut and stdErr handles?
|
|
The original problem is back. Any ideas _why_ the stream would be "closed"? The class-var, "TheStdioHandles" appears to be initialized fine (equivalent to "FileStream stdioHandles"). I can't write to them and I can't "open" them because then it wants to create a regular file. Any ideas?
On Tue, Apr 2, 2013 at 8:56 PM, David T. Lewis <[hidden email]> wrote:
|
Re: Lost stdOut and stdErr handles?
|
|
Found the problem! I had a reference to StandardFileStream stdout in a temp-var of a method. That method then kicked off another image (via OSProcess) which tried to write to that (now defunct) reference to stdout. The solution apperas to just refer to "StandardFileStream stdout" directly in code rather than through a temp-var. On Wed, Apr 3, 2013 at 9:27 AM, Chris Muller <[hidden email]> wrote:
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |