-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Call to a member function getPathAsString() on boolean #42
Comments
You do not have screen installed. And I have a validation that is incorrect when checking for it. |
I've also encountered this issue, but not with screen, but with python executable. It's because on Ubuntu 20.04+ there is no The problem is that it's hardcoded here:
Can you make this configurable? Through static property or some other suitable way? |
@mskocik May i suggest you give MTM-SSH a shot (or just the basic shells lib if you dont need remote ). Its maintained and has far better performance than MTS and the API is almost the same. Edit: Python3 also became the preferred binary about 2 weeks ago |
So what's the difference between I will try to switch Btw when I was checking repos, |
Hi @mskocik , MTS is going on 8 years and it does not lend itself well to applications where a single PHP process runs multiple shells. Mostly because each command and subsequent reading of the return is executed sync. This is solved in MTM-Shells with command objects that allows this flow to be broken up with a call to execute the command (exec()), but read the return later (get()). Second, MTS relies on "screen" for local shells, that is quite a bit of extra complexity that is no longer needed. In MTM-Shells each shell is just a python process spawned with PTY and a set of pipes for control. Much cleaner execution and tear down. Third, the structure of MTS was poorly conceived as it proved hard to extend to new shell types and terminals. Obvs, if all you need is bash then who cares, but since the shells lib also form the base for remote shells (e.g. MTM-SSH) it became important to break each type out on its own, allowing for completely separate return data parsing / execution structure etc. Lastly, MTS has bolted on PhantomJS which was abandoned when Chrome got headless execution. That is quite a bit of code base that really should be ripped out, but who find that kind of time. Its also too much of a monolith with its own file objects and utilities, those also needed to be broken out. All in all, it seemed like a good time for a re-write and hence MTM-Shells. If you stick with MTS keep an eye on used file handles and abandoned python processes. There is a bug somewhere that stops shells from being torn down and leaves them running indefinitely and abandoned. Its not common, but if it happens in your use case it leads to some irritating resource exhaustion scenarios. |
@merlinthemagic just stopping by to say, I migrated to MTM-Shells as you recommended 👍🙏. There was no other way, because of deprecation warning (using php8.1 with enabled error reporting for deprecations)
|
using your example code
results in
The text was updated successfully, but these errors were encountered: