Hyperion Entertainment Message Boards

This is an ancient bug which was fixed in the old Shell but has reappeared with the new one in FE.

To reproduce:
* Open the Shell
* Type "NotePad"
* Close the Shell without pressing return

NotePad opens! Also, the Shell doesn't close...

Of course it won't close, you are running notepad syncronously, this is how it works and always did, (or should have).
The shell process won't be able to end until the command returns from using it.
If you want the shell process to close immediately, you must start the command asyncronously with "run" so it has
its own separate process to work in (and also redirect the three default streams).

run >nil: *>nil: <nil: notepad

I think the point he was trying to make is that the shell assumes that anything on the command line should be executed when the shell is closed. Shouldn't that be taken as a "cancel" event, rather than a positive event?

Simon

colinw wrote:Of course it won't close, you are running notepad syncronously

The thing is, he isn't running NotePad at all, as he never executed the command

Rigo wrote:I think the point he was trying to make is that the shell assumes that anything on the command line should be executed when
the shell is closed. Shouldn't that be taken as a "cancel" event, rather than a positive event?
Simon

Ahh, I understand what you mean now, i'm so used to hitting <ENTER> that it has become automatic.
What it appears to be doing is just flushing the line buffer when a close event is encountered.
I guess because the shell process is about to be terminated and freed, flushing pending buffers could make sence,
it just doesn't dump the queued characters, but instead acts like it had an <ENTER> key pressed just before.

I think it's mostly semantical, a bit like whether your dog barks or not on the way down, when it jumps off a 20 story building.
It's still dead either way.

I am loathe to touch that area of code because it is very touchy and every change has a myriad of side effects.

What do you mean by "old Shell fixed the problem"? Which older Shell had the problem and which not-so-old Shell did not?

colinw wrote:I think it's mostly semantical, a bit like whether your dog barks or not on the way down, when it jumps off a 20 story building.
It's still dead either way.

Well, if the command you had typed were 'delete "" all quiet force', you'd hit yourself quite hard if you tried to avoid running it by using the close gadget. Yes, a dumb thing to do in the first place, but you might have thought you were currently in another directory than SYS: ...

Best regards,

Niels

tonyw wrote: I am loathe to touch that area of code because it is very touchy and every change has a myriad of side effects.

I guess just clearing the line buffer in the case switch when a close gadget event occurs, should be relatively benign.

There are several events feeding into that area of code:

Ctrl-\
Close gadget
ACTION_END

The results vary with what has gone before. It's a minefield.

However, I'll take a look when the rush dies down. BZ #9116.

tonyw wrote:What do you mean by "old Shell fixed the problem"? Which older Shell had the problem and which not-so-old Shell did not?

The old Shell in 3.x had the same problem, it was fixed sometime during 4.1 (or maybe 4.0, I forget). Certainly it was present back in 3.1 and not in 4.1u6.