[HN Gopher] Show HN: A terminal emulator in pure PHP
___________________________________________________________________
Show HN: A terminal emulator in pure PHP
Author : aarondf
Score : 181 points
Date : 2025-03-21 17:43 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| cf100clunk wrote:
| Nice, but your terminal app has a name collision with the long
| lived ''screen'' terminal multiplexer utility:
|
| https://www.gnu.org/software/screen/manual/screen.html
| aarondf wrote:
| Thanks for your feedback!
| cf100clunk wrote:
| To me, name collisions are only a big deal if the app or
| project exists in very similar use case scenarios. In this
| case, I'd say confusion could easily happen if ''screen''
| replaced ''screen'' in the path or a call. How about
| "Soloterm"? Have you thought of others?
| jeffhuys wrote:
| Not only confusion, but inability to just install on
| mac/linux, right? I believe both come with screen by
| default...
|
| Edit: let me actually think a bit before commenting - it
| would probably just install, but then you run screen and
| you might or might not get your newly-installed software
| (so yeah confusion). Not a great first experience at worst
| aarondf wrote:
| It's a package you install into your PHP application.
| It's impossible for it to collide. You cannot run Solo
| Screen as a standalone tool.
| jeffhuys wrote:
| Heh, should've thought a bit longer apparently. But, in
| my defense, I work an office job and it's Friday evening.
| Iykyk
| aarondf wrote:
| It's a package you install into your PHP application. It's
| impossible for it to collide.
| cf100clunk wrote:
| Question: can you call GNU screen from within screen?
| aarondf wrote:
| > Question: can you call GNU screen from within screen?
|
| No. It's literally just an in memory buffer that you
| interact with from PHP.
|
| In Solo (https://github.com/soloterm/solo) we do use GNU
| screen though.
| cf100clunk wrote:
| Thanks, good to know. You and others may have noticed
| some odd activities in this thread (I use Refined Hacker
| News and can see them) so I'm glad for your responses to
| my well-meant comments.
| aarondf wrote:
| Yeah someone's really got a vendetta against SA and HN
| right now huh? Weird stuff!
| jmholla wrote:
| It seems to me that you can, from within the terminal
| that it provides, I supposed depending on what shell you
| run within the emulator. Your example even shows you
| running tail, so I expect it's running some sort of shell
| I'd expect screen could be available on.
|
| Unless, this terminal emulator is missing specific
| features that mean screen doesn't work in it, which would
| make me feel the definition has been stretched a little
| here.
|
| Either way, I have to heavily agree with duskwuff's take:
|
| > They're both pieces of software which implement or
| interact with terminal emulators; I think some
| deconfliction is warranted here.
|
| Edit: I've learned from a different comment [0] that the
| latter is indeed the case. This isn't really a terminal
| emulator.
|
| [0]:
| https://news.ycombinator.com/item?id=43438797#43439716
| duskwuff wrote:
| They're both pieces of software which implement or
| interact with terminal emulators; I think some
| deconfliction is warranted here.
| atarian wrote:
| I was hoping for an actual desktop app powered by PHP, which
| would be really cool having PHP as a desktop runtime.
| aarondf wrote:
| Alas
| aarondf wrote:
| You might enjoy https://nativephp.com/
| endofreach wrote:
| Lol, what? Haven't heard of this... What's your experience
| with nativePHP?
|
| While i am a defender of modern (!) php for web applications,
| this does sound rather weird. But also interesting. Thanks
| for the link.
|
| I wonder though how "native" this is? Glancing over the docs
| it seems to be built upon tauri / electron? Not as native as
| i expected, but probably more native than most people would
| dare to think about...
| aarondf wrote:
| I haven't used it for anything, but it is developed by some
| friends of mine. It's certainly a novel approach! And they
| got it working on iOS too
| noduerme wrote:
| Lol indeed... I also still love PHP. For most small apps
| that's my go to backend, because who needs to worry about
| keeping Node running on some server you forgot about 2
| years ago? And it's a fully modern language.
|
| I'm delighted that there's some kind of desktop API here.
| On the one hand, the fact that it's talking with an
| Electron shell seems sort of magical. But it begs questions
| like, why wouldn't I just use a fully JS stack? And...
| since I've never created a graphical app in PHP before,
| would this be the right time to start?
| noduerme wrote:
| I'd also say ...patterns like this that return the object
| you modified in PHP weird me out, even though they're
| common in JS going back to JQuery:
|
| >> Dialog::new() ->title('Select a file') ->open();
|
| It's an interesting "modern"-ish design choice, but it
| doesn't feel very PHP-ish. $dialog = new Dialog('title')
| followed by $dialog->open() would feel more sane.
| 9dev wrote:
| That heavily depends on the framework you use. Laravel
| uses call chains a lot, and with PHP 8.4 (or even 8.3?)
| you can chain on new: new
| Dialog()->title('Select a file')->open();
| noduerme wrote:
| Just from a high level, chains on 'new' are actually kind
| of awful. They're bad in a world like JS where lots of
| classes need to call async functions to spin up, but
| they're desperately worse in PHP where you really have to
| consider everything to be a blocking call. Something
| basic like this could easily hang a whole thread if, e.g.
| the title chose to read from a remote file. And it would
| be quite hard to tell what was hanging it. This is when
| it feels like PHP is getting out over its skis. I
| understand the desire to keep up with the Joneses, but
| there's no real _penalty_ to writing your example in
| three lines rather than one. It 's not really functional
| either way, and it's not especially debuggable either.
| 9dev wrote:
| How would it make a difference if you split the
| statements up? A bad API is a bad API, and I'm pretty
| sure you can design one in any language (e.g. hide a
| while (true) within an innocuous method). The way to
| trace it down is the same in PHP as elsewhere, too--use a
| debugger. All that said, just don't design shitty APIs
| and give your methods useful names.
|
| An advantage of being able to chain calls are fluent
| expressions that you can return immediately, for example
| from arrow functions or match expressions, which
| definitely makes for easier to read code.
| noduerme wrote:
| I can't think of a lot of examples where I'd want to
| call:
|
| new API()->object->method()->subResult
|
| particularly if the API might block. But I can think of a
| lot of reasons I _wouldn 't_ want to see that in my
| codebase. Usually starting with the fact that
|
| try {
|
| $api = new API();
|
| }
|
| should have a catch after it.
|
| For local stuff, fine, if you want to write that way. I
| don't find it eminently more readable than seeing a
| variable created and employed. And I'd like to see the
| line number the error was thrown on, if I'm reading error
| logs in production.
| pocketarc wrote:
| Sibling mentioned nativephp, but PHP-GTK[0] was also a thing in
| the past!
|
| [0]: https://gtk.php.net
| jorvi wrote:
| I am aware modern PHP is actually pretty good, but having
| grown up with PHP in the 2000s I can't help but get chills up
| my spine every time I read '$nonWebThing written in PHP'
| djfivyvusn wrote:
| I've seen massive cli apps and services written in PHP,
| it's actually pretty good for that sort of thing and given
| no build or compile step the devex is quite nice.
|
| There's trade offs of course but for things where disk or
| network is the bottleneck it performs just fine.
| zerr wrote:
| And Delphi for PHP.
| felbane wrote:
| ...would it?
|
| I guess maybe if it was PHP8 only...
| electroly wrote:
| I'm a little confused--is it an _interactive_ terminal? Or is it
| more like an ANSI renderer where you are producing a single
| static image of the final result of printing a series of bytes? I
| don 't see any JavaScript to hint at interactivity.
| aarondf wrote:
| Nope. Not interactive. It's a library you can use inside of PHP
| to implement a virtual screen. The readme has some pretty
| thorough details!
| jmholla wrote:
| I don't think you can call this a terminal emulator then.
| aarondf wrote:
| Maybe not!
|
| Help me understand then. What would you call a library that
| parses ANSI codes, handles scrolling, screen movement,
| clearing, resets, etc?
| electroly wrote:
| Perhaps something along the lines of an "ANSI terminal
| renderer library"? I think "render" helps suggest that
| it's handling the display but that the library consumer
| still has to handle interactivity and any UI chrome. The
| consumer is the terminal emulator app and this component
| is the renderer.
| aarondf wrote:
| Cool, thanks!
| anthk wrote:
| ANSI/VT100 renderer. A full terminal emulator would
| connect to a tty interface, run subshells and so on.
| aarondf wrote:
| Nice, thanks!
| whalesalad wrote:
| script kiddies are now going to have high-fidelity shells with
| 256 colors for when they pwn you and get root on your godaddy
| drupal install
|
| sidenote: screen is a terrible name for this as there is already
| gnu/screen (colloquially referred to as screen) which has 38
| years head start - https://en.wikipedia.org/wiki/GNU_Screen
|
| also til screen is older than me
| aarondf wrote:
| I am also older than you then, probably
| throwaway150 wrote:
| Commendable work but note that this is not a terminal emulator.
| This is a terminal renderer.
| aarondf wrote:
| Thank you!
| blueflow wrote:
| What functionality does a program need to emulate to be a
| terminal emulator?
| doubled112 wrote:
| Interactive use.
| mrweasel wrote:
| Didn't we have this back in 2001. I seems to remember that we
| kicked a guy of our project because he installed one of the PHP
| consoles on our Solaris box, which basically gave it the same
| rights as the Apache user.
| aarondf wrote:
| Not sure, I was 12
| codetrotter wrote:
| 11 at the time here. For me it would be another 10 years or
| so before I saw a Solaris box or even knew what one was.
|
| I did encounter, and try, Linux much sooner. But didn't
| really "get it" either at the time. Like, I understood that
| it was neat and different. I installed Mandriva Linux on my
| machine when I was 13 or 14 or so, but I was lacking any
| books or guidance to understand how to do anything aside from
| opening the GUI programs that was on it.
|
| It would take all until the age of 18, when I started at the
| university, before I got the help I needed in order to
| understand Linux and editing config files on Linux and
| writing my own scripts and programs on Linux.
| johnisgood wrote:
| > I installed Mandriva Linux on my machine when I was 13 or
| 14 or so, but I was lacking any books or guidance to
| understand how to do anything aside from opening the GUI
| programs that was on it.
|
| It was Gentoo for me at the age of 13 that a random
| Hungarian guy from Finland helped install through SSH.
|
| I did try SUSE around the age of 11, nothing interesting
| though, the interesting stuff came after Gentoo. :D
| jamal-kumar wrote:
| It's still a mainstay of certain malware for sure. Just pop in
| 'php shell' to your favorite search engine, and it's basically
| all stuff for either red teaming or shenanigans
| cship2 wrote:
| To be fair in 2001 php was the underdog of tech stack. It has
| just got ride of the PHP (Personal Home Page) taste in the
| language mouth. So wouldn't be surprised if some company
| running solaris would kick him off.
| aarondf wrote:
| Thanks for all the feedback! I've updated the readme to use the
| word "renderer" rather an "emulator."
|
| Gonna stick with the name screen though
| donatj wrote:
| Oh, interesting!
|
| I started a very similar project probably ten years ago and just
| never got it to a very usable state. My idea at the time was
| based in wanting to be able to write tests for the final output
| of scripts full of control codes.
|
| I am very excited to see this and to play with it!
| aarondf wrote:
| Check out the ComparesVisually trait! (It's described in the
| readme too)
|
| It takes some text, outputs it to iTerm and takes a screenshot.
| Then it takes the same output, runs it through the Screen
| class, outputs it, and takes a screenshot. Then we compare the
| screenshots pixel by pixel. So freakin fun
| adminm wrote:
| I'm curious how you came to the conclusion that naming it
| 'screen' was the best thing for your project?
|
| It's unusual to see so many negative comments on a new project
| announcement and yet you persist and even double down with a
| sarcastic "thanks for your feedback" reply.
| aarondf wrote:
| Sure I can explain it a bit.
|
| I named it screen because the main class is called screen. It
| was extracted from another library to make maintenance easier.
| It's not a tool that can ever be used outside of a PHP project,
| and it has no binary. It's namespaced under SoloTerm.
|
| A nice analogy would be a package named @clerk/auth and then
| everyone complaining about the package being named auth. I mean
| it is... but that's not really the full name or how anyone
| would refer to it.
|
| Most commenters didn't understand any of that nuance and got
| hung up on a surface level thing that didn't really matter. It
| was clear to me that the suggestion didn't apply in this case
| so I thanked them for the feedback. I don't have to take the
| feedback!
|
| Several other folks commented that it's not really an emulator
| but rather a renderer. I thought that was a pretty good point
| and something I was wrong about. So I changed the readme! I
| thanked them for their feedback as well.
|
| It's no secret that HN commenters lean cynical and can miss the
| majors for the minors. I just don't want to fight with them!
| I'm grateful for feedback. Some of it I take and some I
| completely ignore. As everyone should!
| goshx wrote:
| Kudos to you for taking all the heat and handling it
| gracefully.
|
| Perhaps adding a screenshot or video to the README.md showing
| what it does could help people understand it better.
| aarondf wrote:
| Thanks! I know it's probably bizarre behavior to not debate
| at all in the comments, but man, life is short.
|
| Good note on the screenshot. There are some code samples
| but I'll think if there's a way to add a visual. It's tough
| cause it's just a library that you consume in PHP! But I'll
| noodle nonetheless.
| jmholla wrote:
| > Most commenters didn't understand any of that nuance and
| got hung up on a surface level thing that didn't really
| matter. It was clear to me that the suggestion didn't apply
| in this case so I thanked them for the feedback.
|
| It's more nuanced than just that.
|
| From your README:
|
| > Solo provides a TUI (Text User Interface) that runs
| multiple processes simultaneously in separate panels, similar
| to tmux.
|
| You already provide a tool similar to screen. You even call
| out one of its alternatives! This will lead to confusion.
|
| Further, from another of your comments [0]:
|
| > I use GNU Screen in Solo, where I also use Solo Screen, so
| I am aware of it.
|
| combined with
|
| > It was extracted from another library to make maintenance
| easier.
|
| Looking at the code, Solo is the library you extracted it
| from. You built a technology on top of an existing, well-
| known project. Then, you extracted some of your code from it
| and reused the project's name that your tool leverages in
| that related library.
|
| This is the first way in which your analogy is not sufficient
| to support your position.
|
| The second is there is no common, well-known, age-old utility
| called auth in the auth space for people to co-opt.
|
| To quote duskwuff [1] again [2]:
|
| > They're both pieces of software which implement or interact
| with terminal emulators; I think some deconfliction is
| warranted here.
|
| Given the context, I don't think namespacing it is a
| sufficient approach to reducing ambiguity. Especially since
| screen is often referred to without GNU.
|
| As for this reason:
|
| > I named it screen because the main class is called screen.
|
| Saying you named it screen because the main class was called
| that isn't really a justification - especially when you named
| the class in the first place.
|
| The willful reuse of the utility's name that powers your code
| and pithy gratitudes all over this thread, to me, send a
| message of disrespect for the community at large.
|
| [0]: https://news.ycombinator.com/item?id=43439646 [1]:
| https://news.ycombinator.com/item?id=43439429 [2]:
| https://news.ycombinator.com/item?id=43439748
| aarondf wrote:
| I'm sorry you feel that way.
| MrBuddyCasino wrote:
| Does it render to plain text or styled HTML? Not quite clear from
| the readme.
___________________________________________________________________
(page generated 2025-03-22 23:02 UTC)