Skip to content
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

Ongoing: additional shell support #207

Open
2 tasks
balupton opened this issue Jan 20, 2024 · 3 comments
Open
2 tasks

Ongoing: additional shell support #207

balupton opened this issue Jan 20, 2024 · 3 comments
Labels
ongoing Ongoing efforts of incremental improvements PR / Bounty only External demand, as such, external funding / effort is required to make this happen

Comments

@balupton
Copy link
Member

balupton commented Jan 20, 2024

As Dorothy is cross-shell compatible, here are additional shells we could target:

Listings of shells:

Note that Dorothy commands need not be coded in a language optimised for interactive login shells, as such here are alternatives for writing Dorothy commands:

  • nu, however it is still early days with b/c breaks monthly
@balupton balupton added ongoing Ongoing efforts of incremental improvements PR / Bounty only External demand, as such, external funding / effort is required to make this happen labels Jan 20, 2024
This was referenced Jan 20, 2024
@balupton
Copy link
Member Author

balupton commented Jan 23, 2024

One idea here is to introduce reimplementations of each of the simpler commands/ for the different shells, but with the same test suite. So for instance: is-integer is bash, but is-integer.nu is with nushell. This could become an invaluable resource for shell scripters, while also allowing overlay shells like Nushell to work more seamlessly with command invocations.

@balupton
Copy link
Member Author

For scripting,

So far I haven't found any that offer a sensible errexit, however Ruby's ability to metaprogram could enable this:
https://stackoverflow.com/a/30940226/130638

The snippet from that example doesn't support ignoring failures for executions which we don't care if they fail, and from my limited ruby experience will crash the whole app.

The ideal, would be the way it works from bash.bash, which is all unignored exit statuses trigger an exception, which can be caught by eval_capture

Perhaps such can be metaprogrammed for Ruby. If so, I wonder about Ruby's performance and also if it can be compiled into portable binaries.

Higher level options like Deno could be done via function calls, however that becomes messy for piping and escaping, and as nearly everything is an invocation we don't want to do function calls for everything.

Nu I hope will be the best contender, however they haven't ratified or even started their exception handling yet.

@balupton
Copy link
Member Author

balupton commented Mar 3, 2024

Seems great, this could be it:

https://github.com/dsherret/dax

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ongoing Ongoing efforts of incremental improvements PR / Bounty only External demand, as such, external funding / effort is required to make this happen
Development

No branches or pull requests

1 participant