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..
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
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 lewis@mail.msen.com 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
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 lewis@mail.msen.com 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
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 lewis@mail.msen.com wrote:
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 lewis@mail.msen.com
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
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 asqueaker@gmail.com wrote:
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 lewis@mail.msen.comwrote:
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 lewis@mail.msen.com
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
squeak-dev@lists.squeakfoundation.org