Hi Dave, hi all,
I noticed that when I start my normal Trunk image on Windows, which normally does not attach any stdio streams, ExternalCommandShell interrupts the startup process with an error from ExternalCommandShell>>start. See the attached debug log.
While I understand while this error occurs, I think that it should be handled silently. Most users (including myself a few times ago) will just abandon this debugger, preventing further startup tasks from being run correctly and leaving the image in a partially uninitialized state. Plus, the debugger is slightly annoying, as I am aware indeed whether I started Squeak from a command shell or not. I would prefer an error to be raised only if I actually try to use an ExternalCommandShell. It would be great if something could overthink this. :-)
Best, Christoph
--- Sent from Squeak Inbox Talk [ExternalCommandShell startup.SqueakDebug.log]
Hi Christoph,
I do not have a Windows system for testing right now, but I think the attached patch should handle the problem. Could you please give it a try and let me know if it works for you?
I am assuming that the scenario is that the image was running in a VM with console access, and was saved with the ExternalCommandShell running. Then that when restarting on a VM with no console access, we get the error that needs to be handled in startUp: processing.
Thanks!
Dave
On 2023-11-28 11:46, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Dave, hi all,
I noticed that when I start my normal Trunk image on Windows, which normally does not attach any stdio streams, ExternalCommandShell interrupts the startup process with an error from ExternalCommandShell>>start. See the attached debug log.
While I understand while this error occurs, I think that it should be handled silently. Most users (including myself a few times ago) will just abandon this debugger, preventing further startup tasks from being run correctly and leaving the image in a partially uninitialized state. Plus, the debugger is slightly annoying, as I am aware indeed whether I started Squeak from a command shell or not. I would prefer an error to be raised only if I actually try to use an ExternalCommandShell. It would be great if something could overthink this. :-)
Best, Christoph
Sent from Squeak Inbox Talk [ExternalCommandShell startup.SqueakDebug.log]
Hi Dave,
thank you! This patch works fine for me.
I am assuming that the scenario is that the image was running in a VM with console access, and was saved with the ExternalCommandShell running. Then that when restarting on a VM with no console access, we get the error that needs to be handled in startUp: processing.
Yes, this makes sense. :-)
Best, Christoph ________________________________ Von: lewis@mail.msen.com lewis@mail.msen.com Gesendet: Freitag, 1. Dezember 2023 16:06 Uhr An: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] Re: [BUG] ExternalCommandShell interrupts StartUpList if no stdio is present
Hi Christoph,
I do not have a Windows system for testing right now, but I think the attached patch should handle the problem. Could you please give it a try and let me know if it works for you?
I am assuming that the scenario is that the image was running in a VM with console access, and was saved with the ExternalCommandShell running. Then that when restarting on a VM with no console access, we get the error that needs to be handled in startUp: processing.
Thanks!
Dave
On 2023-11-28 11:46, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Dave, hi all,
I noticed that when I start my normal Trunk image on Windows, which normally does not attach any stdio streams, ExternalCommandShell interrupts the startup process with an error from ExternalCommandShell>>start. See the attached debug log.
While I understand while this error occurs, I think that it should be handled silently. Most users (including myself a few times ago) will just abandon this debugger, preventing further startup tasks from being run correctly and leaving the image in a partially uninitialized state. Plus, the debugger is slightly annoying, as I am aware indeed whether I started Squeak from a command shell or not. I would prefer an error to be raised only if I actually try to use an ExternalCommandShell. It would be great if something could overthink this. :-)
Best, Christoph
--- Sent from Squeak Inbox Talk [ExternalCommandShell startup.SqueakDebug.log]
Thanks Christoph, I updated it on www.squeaksource.com/CommandShell.
Dave
On 2023-12-01 15:53, Thiede, Christoph wrote:
Hi Dave,
thank you! This patch works fine for me.
I am assuming that the scenario is that the image was running in a VM with console access, and was saved with the ExternalCommandShell running. Then that when restarting on a VM with no console access, we get the error that needs to be handled in startUp: processing.
Yes, this makes sense. :-)
Best, Christoph
Von: lewis@mail.msen.com lewis@mail.msen.com Gesendet: Freitag, 1. Dezember 2023 16:06 Uhr An: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] Re: [BUG] ExternalCommandShell interrupts StartUpList if no stdio is present
Hi Christoph,
I do not have a Windows system for testing right now, but I think the attached patch should handle the problem. Could you please give it a try and let me know if it works for you?
I am assuming that the scenario is that the image was running in a VM with console access, and was saved with the ExternalCommandShell running. Then that when restarting on a VM with no console access, we get the error that needs to be handled in startUp: processing.
Thanks!
Dave
On 2023-11-28 11:46, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Dave, hi all,
I noticed that when I start my normal Trunk image on Windows, which normally does not attach any stdio streams, ExternalCommandShell interrupts the startup process with an error from ExternalCommandShell>>start. See the attached debug log.
While I understand while this error occurs, I think that it should be handled silently. Most users (including myself a few times ago) will just abandon this debugger, preventing further startup tasks from being run correctly and leaving the image in a partially uninitialized state. Plus, the debugger is slightly annoying, as I am aware indeed whether I started Squeak from a command shell or not. I would prefer an error to be raised only if I actually try to use an ExternalCommandShell. It would be great if something could overthink this. :-)
Best, Christoph
Sent from Squeak Inbox Talk [ExternalCommandShell startup.SqueakDebug.log]
Perfect, have a nice weekend!
Best, Christoph ________________________________ Von: lewis@mail.msen.com lewis@mail.msen.com Gesendet: Samstag, 2. Dezember 2023 00:08 Uhr An: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] Re: [BUG] ExternalCommandShell interrupts StartUpList if no stdio is present
Thanks Christoph, I updated it on www.squeaksource.com/CommandShell.
Dave
On 2023-12-01 15:53, Thiede, Christoph wrote:
Hi Dave,
thank you! This patch works fine for me.
I am assuming that the scenario is that the image was running in a VM with console access, and was saved with the ExternalCommandShell running. Then that when restarting on a VM with no console access, we get the error that needs to be handled in startUp: processing.
Yes, this makes sense. :-)
Best, Christoph ________________________________ Von: lewis@mail.msen.com lewis@mail.msen.com Gesendet: Freitag, 1. Dezember 2023 16:06 Uhr An: The general-purpose Squeak developers list squeak-dev@lists.squeakfoundation.org Betreff: [squeak-dev] Re: [BUG] ExternalCommandShell interrupts StartUpList if no stdio is present
Hi Christoph,
I do not have a Windows system for testing right now, but I think the attached patch should handle the problem. Could you please give it a try and let me know if it works for you?
I am assuming that the scenario is that the image was running in a VM with console access, and was saved with the ExternalCommandShell running. Then that when restarting on a VM with no console access, we get the error that needs to be handled in startUp: processing.
Thanks!
Dave
On 2023-11-28 11:46, christoph.thiede@student.hpi.uni-potsdam.de wrote:
Hi Dave, hi all,
I noticed that when I start my normal Trunk image on Windows, which normally does not attach any stdio streams, ExternalCommandShell interrupts the startup process with an error from ExternalCommandShell>>start. See the attached debug log.
While I understand while this error occurs, I think that it should be handled silently. Most users (including myself a few times ago) will just abandon this debugger, preventing further startup tasks from being run correctly and leaving the image in a partially uninitialized state. Plus, the debugger is slightly annoying, as I am aware indeed whether I started Squeak from a command shell or not. I would prefer an error to be raised only if I actually try to use an ExternalCommandShell. It would be great if something could overthink this. :-)
Best, Christoph
--- Sent from Squeak Inbox Talk [ExternalCommandShell startup.SqueakDebug.log]
squeak-dev@lists.squeakfoundation.org