[HN Gopher] Show HN: A terminal emulator in pure PHP
       ___________________________________________________________________
        
       Show HN: A terminal emulator in pure PHP
        
       Author : aarondf
       Score  : 96 points
       Date   : 2025-03-21 17:43 UTC (5 hours 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.
        
       | pmarreck wrote:
       | Neat tech demo, but I'd never rely on something like this- I
       | can't help but recall the guy who wrote his own security code for
       | MTGOX which resulted in its getting hacked... Please do not build
       | software that you expect to last in PHP.
       | 
       | As a long-time engineer who's maintained systems across decades,
       | the core problem with PHP isn't that it's "not Turing complete"
       | or "doesn't work"--it's that it encourages entropy.
       | 
       | PHP grew organically from a CGI templating language into a
       | "language" without clear design principles. It's inconsistent
       | (in_array(needle, haystack) vs array_map(callback, array)),
       | mutability is everywhere, and its type system has historically
       | been an afterthought. The result is code that's often hard to
       | reason about, test, or refactor safely--especially once the
       | original author is long gone.
       | 
       | The classic junior rebuttals-- "It powers half the web," "Laravel
       | is great," "Modern PHP is typed!"-- miss the point. The issue
       | isn't what _can_ be done in PHP, it 's what PHP _encourages by
       | default_ : global state, poor encapsulation, inconsistent APIs,
       | and difficult-to-enforce discipline. These become cost
       | multipliers over time.
       | 
       | Yes, a disciplined team can write clean, testable PHP. But so can
       | a team using punch cards. The real question is: does the language
       | guide you toward maintainable, composable abstractions or away
       | from them? PHP has historically done the latter. Worse, its
       | community normalized things like: ignoring its own test suite
       | failures, tolerating runtime warnings, etc.
       | 
       | When you're 3 years into maintaining a PHP codebase that five
       | devs with differing levels of discipline have touched, you'll
       | wish the original author had used nearly anything else.
       | 
       | The older you get, the more you realize "strictness and
       | determinism are primal virtues" in coding.
       | 
       | Use better tools. Your future self will thank you.
       | 
       | Also, as someone else already stated, "screen" the name is
       | already quite taken by another venerable tool. (That tells me
       | you're kind of junior.)
       | 
       | Feel free to downvote away, I don't fucking care, because I spent
       | years working on spaghetticode hell of exactly the sort that PHP
       | encourages.
        
         | aarondf wrote:
         | Thanks for the... rant? Sorry you've had such a rough time.
         | 
         | I use GNU Screen in Solo, where I also use Solo Screen, so I am
         | aware of it.
         | 
         | https://github.com/soloterm/solo/blob/main/src/Commands/Conc...
        
         | calvinmorrison wrote:
         | as your average PHP enjoyer, I agree with all of these
         | complaints, but also will note
         | 
         | - you really need to train the team on PHP footguns, which are
         | as bad as C foot guns
         | 
         | - finding PHP programmers is easy.
         | 
         | - your shits already written in PHP
         | 
         | - in the same way rolling your own stdlib in C is silly,
         | leverage good PHP frameworks
         | 
         | ymmv but its not that bad. at least it keeps my day exciting.
        
         | lpapez wrote:
         | You come across as pretty opinionated and eager to comment for
         | someone who states they don't care.
         | 
         | I work with spaghetti PHP every day. It pays the bills. There
         | are far worse jobs out there.
         | 
         | The expert wishes to fix the tedious tasks. But a true master
         | understands that all tasks are equally tedious.
         | 
         | Relax and enjoy the ride.
        
         | dgivney wrote:
         | > The issue isn't what can be done in PHP, it's what PHP
         | encourages by default:
         | 
         | Lets break this done.
         | 
         | > global state,
         | 
         | PHP is stateless.
         | 
         | > poor encapsulation,
         | 
         | Encapsulation in PHP is mostly consistent with Java.
         | 
         | > inconsistent APIs,
         | 
         | PHP is written in C and an original design decision by those C
         | programmers was to make the APIs consistent with libc.
         | 
         | > and difficult-to-enforce discipline.
         | 
         | Its very easy to enforce. All modern projects would run tools
         | like Pint, Phpcs & Phpcbf to enforce their code standards and
         | preferred style in their CI Pipeline.
        
           | hnlmorg wrote:
           | > PHP is written in C and an original design decision by
           | those C programmers was to make the APIs consistent with
           | libc.
           | 
           | Old PHP did have some pretty inconsistent naming conventions
           | (or lack of). Which is what I think the GP was referring to.
           | 
           | I've not written any PHP in quite a few years but I've read
           | that there's been a concerted effort to address those
           | inconsistencies and the old complaint is now just a relic of
           | a bygone era.
           | 
           | One thing I have learned over the several decades that I've
           | been writing software is that literally every language could
           | have a book written about its problems. People often seem to
           | forget that language design is a constant battle of
           | tradeoffs. And because their preferred languages naturally
           | align with their tradeoff preferences, they don't even
           | realise that their own preferences are deeply flawed for a
           | great many type of scenarios too.
           | 
           | So it really disappoints me when people subscribe to language
           | tribes like it's their religion.
        
         | deergomoo wrote:
         | > its type system has historically been an afterthought
         | 
         | This is a rather outdated view. PHPs type system isn't the most
         | expressive thing out there, but it's very achievable to have
         | end-to-end type safety these days. For a start it's possible to
         | delineate between nullable and non-nullable types, something
         | many more "serious" languages don't support.
         | 
         | It has the weakness that, not being compiled, you need an
         | additional static analysis tool to catch these things before
         | runtime. But at least it has the good graces to crash if you
         | tell it you're expecting a Foo and you try to pass a Bar,
         | unlike e.g. Python.
         | 
         | Modern PHP is a completely different thing to the 5.x days.
         | Yeah you still have the inconsistent stdlib, but everything has
         | a few warts after 30 years.
        
         | fancyswimtime wrote:
         | we need low barrier to entry langs, it affords some a start.
         | Also The php symfony components are very well written; I
         | recommend giving them a look
        
         | chasil wrote:
         | I have some Oracle Pro*C code that is infinitely more pleasant
         | to use when I rewrite it in PHP.
         | 
         | I don't think the PHP version has greater entropy than the
         | compiled C.
        
         | etothet wrote:
         | It is completely possible to have a PHP application written 3+
         | years ago that is well maintained, continues to promote best
         | practices, has excellent test coverage, that isn't a nightmare
         | to deal with. It's also possible for the opposite, but that's
         | the case with every language. In my 20+ years of professional
         | experience, the biggest factor come down to what values a team
         | sets as priorities.
        
       | 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
        
         | pocketarc wrote:
         | Sibling mentioned nativephp, but PHP-GTK[0] was also a thing in
         | the past!
         | 
         | [0]: https://gtk.php.net
        
       | 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!
        
       | 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
        
       | 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
        
         | fragmede wrote:
         | GNU screen, from 1987, would like their name back.
        
           | aarondf wrote:
           | Every other commenter in this thread would like their comment
           | back ;)
        
             | fragmede wrote:
             | Maybe you should take that as a hint
        
               | aarondf wrote:
               | I rarely take advice from commenters on hacker news
        
       ___________________________________________________________________
       (page generated 2025-03-21 23:00 UTC)