fix nested executions using non-standard ports #1389
that's a bummer because I
The only aspect this commit disambiguates is the priority of port information, which is reflected in a comment.
Working around this bug is painful and so is adding a custom patch for vanilla installations.
I'd appreciate it if you could reconsider and review the changes once more. On my end, I'll promise to find time to contribute to the 2.0 roadmap.
Thanks & cheerio, Harry.
Thank you for taking the time for a reasoned & calm response, I appreciate it!
To expand my initial reply, I'm not knocking the quality of your work or the caution you took (again, it's appreciated!). However, the history of code (or at least, all projects I've maintained) is rife with well-meaning, well-tested, small changes which nonetheless broke previously unseen/untested use cases. The more critical the code path (
So every bugfix is a risk assessment balancing act of "how many people are encountering this bug?" (I haven't seen many other reports that seem to map to this) vs "what's the chance of this bugfix causing other bugs?" (higher than I'd like).
Compound that with the previously-noted conservative approach that I'm applying to Fabric 1 as 2 looms, and you get my original "ehh this changes how
All that said, maintainership is a constant battle between "this could break shit!" and "people can always just roll back!" and I'm trying to cut more, smaller releases - meaning the cost of rollback should be lower than it might otherwise. So I will think about this some more and make another judgement call soon. Thanks again.
In the context of open_shell with sys.stdin connected to a channel, cursor movements appear "wonky", which can really mess up the user experience. An initial escape sequence is not captured correctly and only partially sent across the channel resulting in no effect. A repeated key press yields the correct sequence. I suspect this is caused by a mismatch between select (mapped to a syscall) and reading from the (buffered) sys.stdin. Dropping to the lower-level os.read resolves this issue entirely. NOTE: this may explain #196