8000 Add support for configuring arbitrary command prefixes via environment variables by apockill · Pull Request #13 · p-e-w/shin · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

Add support for configuring arbitrary command prefixes via environment variables #13

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

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

apockill
Copy link
@apockill apockill commented Mar 7, 2023

Hey folks, I realized I wanted to be able to run ChatGPT commands from anywhere in my computer. I forked shin, made it configurable via environment variables, then wrote a short project for calling chat GPT (https://github.com/apockill/clai).

Anyways, I figured other folks might benefit from this addition.

Comment on lines +89 to +95
If you are using shin to always run some specific command, you can edit the
`SHIN_DEFAULT_COMMAND`. It will append this to any bash shell you run. This environment
variable can be set in your `~/.profile`, for example:

```bash
export SHIN_DEFAULT_COMMAND="cowsay"
```
Copy link
@ElijahLynn ElijahLynn Mar 7, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The command for fish is:

set --export SHIN_DEFAULT_COMMAND="cowsay"

Which I have yet to test.

8000
@p-e-w
Copy link
Owner
p-e-w commented Apr 6, 2023

Thanks for the PR!

Making the command interpreter configurable would indeed be a nice feature (see #7). Unfortunately, this PR isn't quite the right approach for several reasons:

  • All commands are still written to the same history database, which doesn't make sense if the interpreter can be changed between invocations. Using the history would mix commands for different interpreters which may not even be valid, or worse, which may be dangerous, in the currently selected one. A separate history is needed for each interpreter.
  • This implementation breaks in a variety of ways when the text contains sequences like && or quotes, because those will be dumped unescaped into the Bash command.
  • Not every interpreter conforms to the simple command line interface where any text that is appended to the interpreter command is executed.

In summary, a more sophisticated implementation is needed, probably in the form of a configuration file where multiple interpreters can be specified, and a UI to switch between them. But this would introduce a lot of complexity, and I'm honestly not convinced that would actually be worth it, to cover the relatively niche use cases I've seen so far.

@apockill
Copy link
Author
apockill commented Apr 6, 2023

That's totally fair! My use case was to make this tool possible, which meant I just needed to pass the string to some command and return the value back. This PR enabled that, but isn't great if, say, you wanted to run zsh instead of bash.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0