[hnlmorg]

I've given this a play and I hope you don't mind some constructive criticism I've experienced:

First of, I really like the idea of this project despite normally being a vocal critic against Electron. However I think you bit off too much trying to write your own $SHELL as well as terminal emulator. The result is rather uncomfortable to use because there are shell bugs and incompatibilities compounding the usual expected bugs with any new terminal emulator. For example it took me 5 minutes to just cd into a directory because env vars weren't being recalled, the ~ variable wasn't being recalled, and auto-complete wasn't keyboard optimised (I'd arrow down and hit enter but it would crop the line rather than select the auto-complete entry).

So the next thing I did was to start my preferred shell and I then ran into a whole other series of bugs due to the terminal emulator being tailored for it's own specific shell. In fact the bugs there were so severe that it renders the term virtually unusable on any of the standard shells nor the more esoteric ones I contribute to.

One thing I was pleasantly surprised about though was how well it supported ANSI escape sequences - even ones that aren't part of the formal standard (such as the iTerms true colour sequences). But the bugs surrounding the terms handling of readline (and similiar) really feels like many of the basics are missing despite having some cool advanced features already.

Overall, as much as I'm ideologically against Electron, I can see the advantages of using it in this domain because it allows the ability to include rich content in the command line. It might be nice to get to the point where the command line can offer as much rich content as a web page (something I'm working towards with my own project in fact) - in which case Electron (or similar tech) seems the obvious choice for building a terminal emulator. However upterm's dependance on using your own implementation of Bash (I think it's a bit disingenuous calling your shell "Bash" but that's your prerogative) makes this highly frustrating compared to other rich terminal emulators already out there. And the inability to run your own shell within upterm makes this inflexible for anyone wanting to do something a little more indepth than just cat'ing a JSON file (even running a DB command line tool like mysql or redis-cli would be impractical in upterm in it's current state. And while I didn't try SSHing into remote boxes I can see the same issues happening there too).

I don't know the age of this project but I think it does have real potential. However if I was to ask for anything - and I appreciate this is your baby so I have no entitlement what-so-ever - it would be if you could offer a $SHELL'less version for power users.

edit: Also, I've noticed commands that fail don't appear in the upterm's history. Was this an intentional decision? I appreciate there are arguments for and against only including successful commands but sometimes you'd typo something and the inability to up-array and edit my failed commend added to my frustration. If this was an intentional design decision then is it worth including the last command regardless of success and then excluding it from all subsequent placements in the history?

[shockone]

This is a great piece of feedback, thank you so much!

We do utilize a login shell for executing commands, but we only support Bash and ZSH. So, it's a real Bash. However, there are some complications with environment interpolation and built-in commands; it's a known bug and we're working on it.

Unfortunately, I don't see how to allow using custom shells while providing a better command entering experience (i.e. zle or readline replacement). The core issue is that shells' interface is too primitive: it only consists of three streams with no per-job separation or anything; I wish Bash had a programmatic or REST-like interface.

[hnlmorg]

Maybe you could support a user-defined auto-completion config like Bash et al do for theirs and IDEs would for custom languages too.

With regards to the shell input: I don't know how you are currently detecting the $SHELL prompt (and thus when you can do your auto-completion) but maybe you could allow users to specify hooks for what to watch for to determine the different between the $SHELL and other tools, based on the $SHELL prompt (possibly using $PS1 env var?)

For example you could define that $SHELL's prompt would be:

    SHELLPROMPT>

And when you read that from the $SHELL's STDOUT you know the shell is waiting for prompt. There is obviously the danger that your term would get confused if SHELLPROMPT> happens to appear in the STDOUT when not part of the prompt that it would confuse your term, so perhaps you might need to include an ANSI escape sequence in there as well. Or maybe even define your own custom ANSI escape sequence that $SHELL's need to include in their prompt? (I'm mostly just brainstorming at the moment so these ideas might be worse than your current implementation).

As a side note, the project I'm currently working on is a $SHELL that supports defining data types to STDOUT and STDERR. The issue I have is that those byte streams are typeless and scripts written in my $SHELL needs to work with existing POSIX utilities and potentially on other $SHELLs with untypes streams. Plus I wanted people to be able to type those streams from other languages as well if they wanted and for my $SHELL to understand that. The solution I've decided upon was for an ASNI escape sequence to surround a string with the typed information and for this to only be a included if an environmental variable was set to the name of my shell. This is how I'm working around limitations with POSIX compatibility while still offering a richer environment to develop in when my $SHELL is running (I hope that makes sense).

In fact it sounds like we are attempting to solve similar problems but from a different angle - with myself targeting the $SHELL while you are targeting terminal emulation (which it probably why I'm warming to your project).

[shockone]

It works differently: we just create a new shell session for each command. We create a non-interactive session without reading config files to make it fast and pass it appropriate ENV, which we maintain.

[hnlmorg]

Ahh so the prompt isn't bash then? That explains some of the bugs I got.

I'm not going to criticize your approach as it totally makes sense in terms of building a minimum viable product but I do think you're going to run into a lot of problems with that approach as your project gains traction as it's very different to how a terminal emulators traditionally work. Plus you'll potentially spend a lot of time reimplementing Bash features like it's builtins, scripting features and the multitude of parsers it runs (depending on if you're interested in having a REPL environment like you would normally would with $TERM + $SHELL).

That all said, it looks like you're handling pseudo TTYs decently, which is an easy thing to get wrong (I say that from experience as I've screwed up PTYs in the past!) but also probably the most important part to get right, in my opinion.

[sime2009]

Can your project be found anywhere? (github??)

[shockone]

As of history and failed commands, it should work as you describe, it must be a bug. https://imgur.com/a/BKz5O

[hnlmorg]

If it is any help, the issue happened with Bash builtins like `cd` and `while`. So it's possibly related to the problems you mentioned in the other reply