Support launching with a specific command

lread commented 2 years ago

Currently membrane.term launches a /bin/bash shell.

This results in the following warning text on macOS 10.15.7:

The default interactive shell is now zsh.
To update your account to use zsh, please run `chsh -s /bin/zsh`.
For more details, please visit https://support.apple.com/kb/HT208050.

Seems that macOS would really rather we use zsh! 🙂

Ideas I'm not sure the best approach here but offer up:

allow user to specify which shell to invoke via a :shell option
else use value specified by SHELL environment variable (does that make sense?)
else use /bin/bash

Next Steps Happy to follow up with PR if this all makes sense.

phronmophobic commented 2 years ago

Sounds great. Would love a PR!

allow user to specify which shell to invoke via a :shell option

else use value specified by SHELL environment variable (does that make sense?)

else use /bin/bash

Seems like a good plan. Shells are definitely not my area expertise. It seems like $SHELL isn't a perfect default according to stackoverflow (https://stackoverflow.com/a/16375583), but the other options seems like they might actually be more brittle across future OS versions. I like your plan.

phronmophobic commented 2 years ago

I just had a thought that it might be interesting to boot directly into emacs and afaict, it works!

https://github.com/phronmophobic/membrane.term/commit/bc5072fb044c8a8796b196951904e8ef4e8ec572

One idea I've been kicking around using membrane.term as a way to provide a usable code-editor for membrane. It might require a little configuration to hide the frame, but it seems plausible.

Embedding a code editor made me wonder if you could embed a number of other cli tools. In place of ["/bin/bash" "-l"], I also tried ["/usr/bin/env" "vim"], ["git" "log"], ["clj"], and ["htop"] which all seemed to work. Still not sure what this implies or if I'm misusing pty, but I think there's some really cool use cases that might be hidden here, but not quite sure what.

lread commented 2 years ago

Interesting! So maybe instead of adding a :shell option we add a :cmd option.

phronmophobic commented 2 years ago

Yea, that makes sense. It could potentially be useful for the use case you mention of taking screenshots for cli tools. You can bypass the shell and skip to the good part.

lread commented 2 years ago

Neat!

How do you feel about bringing in deps?

I'm thinking of babashka.process's nice tokenization support.

phronmophobic commented 2 years ago

I'm pretty open to adding dependencies that solve problems. Obviously, if it's incredibly huge, it's worth thinking about, but that's very rare for clojure libs.

lread commented 2 years ago

So while I work on #5, I'm thinking ahead about the new cmd idea.

We'll have (assume the clojure -M... prefix, replace --cmd for :cmd for -X usage):

run-term (cmd defaults as proposed for shell option - with -l)
run-term --cmd "/bin/zsh -l"
run-term --cmd "git log"

But what about run-script? Currently run-script :path effectively types or plays or enters (or what's a better word? maybe applies?) the script to the terminal.

What do you think of:

run-script --play script.sh (rename path to play, cmd defaults as for run-term)
run-script --cmd "clj" --play script.clj"

Watha think? With the cmd idea, is the play concept still interesting/valuable?

phronmophobic commented 2 years ago

We'll have (assume the clojure -M... prefix, replace --cmd for :cmd for -X usage):
run-term (cmd defaults as proposed for shell option - with -l)
run-term --cmd "/bin/zsh -l"
run-term --cmd "git log"

I assume you're using babashka.process to tokenize "git log" into ["git" "log"]. Are there any common shells where the tokenization might differ? That's probably fine, but worth checking.

What do you think of:

run-script --play script.sh (rename path to play, cmd defaults as for run-term)
run-script --cmd "clj" --play script.clj"

Play does sound better than "path". It's not entirely clear that run-script and run-term should be different commands. It would also be possible to add options like --headless and --screenshot, but maybe it's less confusing if they're separate commands.

Watha think? With the cmd idea, is the play concept still interesting/valuable?

I think so. One of the original intended use cases was to be able to automate taking screenshots for terminal utilities. I'm not sure how to produce the following image without a --play option.

terminal

The script was:

export PS1="$ "
cd
cd workspace/deep-diff2
clear
clojure
(require '[lambdaisland.deep-diff2 :as ddiff])
(ddiff/pretty-print (ddiff/diff {:a 1 :b 2} {:a 1 :c 3}))

Additionally, You could theoretically also use it for testing how a command line program responds to ctrl+c, ctrl+z, and other input sequences.

lread commented 2 years ago

Thanks @phronmophobic!

I assume you're using babashka.process to tokenize "git log" into ["git" "log"].

Yeah, that's the thought.

Are there any common shells where the tokenization might differ? That's probably fine, but worth checking.

The convenience might turn out to be inconvenient/problematic in some cases. I shall ponder more on this.

It's not entirely clear that run-script and run-term should be different commands. It would also be possible to add options like --headless and --screenshot, but maybe it's less confusing if they're separate commands.

Hmmm, interesting point. I think maybe keeping them separate might be more understandable as they have different goals - and there are options specific to run-script. But run-script might be renamed to screenshot because that's its ultimate outcome.

And on keeping a play option: nice example, sounds good, thanks!

phronmophobic commented 2 years ago

The convenience might turn out to be inconvenient/problematic in some cases. I shall ponder more on this.

For the cli, I think it's ok if to not support every use case if it makes 80-90% of use cases easier. If it's uncommon for a shell to not have similar tokeniztion, it's always possible to use the programmatic API as a workaround.

I think maybe keeping them separate might be more understandable as they have different goals - and there are options specific to run-script. But run-script might be renamed to screenshot because that's its ultimate outcome.

👍

And on keeping a play option: nice example, sounds good, thanks!

It would also leave open the possibility for a "record" feature in the future.

lread commented 2 years ago

Cool, but my most important question is: what's the difference between phronmophobic (your username) and phronemophobic (seen in your project namespaces) and are these related to phronesis and does this mean you have a fear of practical wisdom?

phronmophobic commented 2 years ago

It's been my username since middleschool, but the original definition I read was that phronemophobia is the "fear of thinking". I definitely have a tendency to over think things :D. The reason my username is spelled wrong was because the first platform that I used had a 14 character username limit. I own phronemophobic.com which is why it's used in all of the project namespaces. 😄

lread commented 2 years ago

Thanks! The fact that you've put a lot of thought into your username makes total sense! 🙂

lread commented 2 years ago

@phronmophobic, gonna look at this one.

Current thoughts:

The screenshot --play/:play option can become optional (currently mandatory)
New --command/:command option
1. If unspecified, defaulting to a reasonable shell still makes sense:
  1. on macOS and Linux will follow the original proposal
  2. on Windows will default to Powershell (not saying this means we support Windows correctly yet, but we would get past launch)
2. For programmatic API, :command ["prog" "arg1" "arg2"]
3. For command line API, --command "prog arg1 arg2", the value of which we will translate to programmatic API form via babashka.process/tokenize.

Sound good to you too?

phronmophobic commented 2 years ago

Sound good to you too?

Sounds like a good plan!

phronmophobic / membrane.term

Support launching with a specific command #3