7 ms·

Or you could get fzf innyour current shell for most of the features (the command history search, file preview/open, etc). Familiar syntax is a big plus though,

Or you could get fzf innyour current shell for most of the features (the command history search, file preview/open, etc). Familiar syntax is a big plus though, a point on which most shells leave a lot of desired.

simias 6y ago
FZF is amazing and I highly recommend it as well, but this project seems to go beyond what FZF provides. This bit in particular: curl https://api.github.com/repos/elves/elvish/issues | from-json | all (one) | each [issue]{ echo $issue[number]: $issue[title] } | head -n 11 That being said I'm still not willing to switch to a non-standard shell syntax, too difficult to use third party servers after that. Also un*x shells are inherently limited by the underlying concept of pipes exchanging only byte streams with no metadata or higher level constructs. You can hack your way around that (as this project seems to be doing) but it's always going to be kludgy. In particular you can't expect any third-party command to play by your rules.
- guitarbill 6y ago
  presumably you can get jq to do something similar, well enough for 95% of the time, which is the issue. like you, i'm not saying new shells don't have a place, but adoption is really the problem. you can get around this if the features are compelling enough. personally, i like fish. certainly, it was a rough adoption curve, but worth it IMO so i can stop setting up and tweaking zsh, plus the built-in auto-complete is fzf-ish enough for me. and i'm told people use powershell even on non-Windows systems. it's just a very tough sell.
- xiaq 6y ago
  > too difficult to use third party servers after that Just "scp" the binary to the server and you're good to go :)
  - fmakunbound 6y ago
    Yeah this one of the selling points, IMO. It's a gigantic Go static executable and easily available for a wide variety of architectures.
- vlowther 6y ago
  Eh, last time I messed with I lost interest after noting that from-json | to-json would silently convert all numbers into quoted strings and do terrible things when nil was involved. It made non-trivial JSON manipulation not worth it. They might have fixed it by now.
  - xiaq 6y ago
    Yes, Elvish now has a dedicated number type, so conversation from JSON is now lossless.
    - vlowther 6y ago
      Excellent -- nil handling work as well?
      - xiaq 6y ago
        Yes, Elvish's $nil maps to JSON's null.
chubot 6y ago
If you want familiar syntax, Oil is the most bash-compatible shell by a mile (which means it's also POSIX compliant). But you can opt in to a bunch of fixes for longstanding shell warts, shown here: https://www.oilshell.org/release/0.8.0/doc/idioms.html https://www.oilshell.org/release/0.8.0/doc/idioms.html So upgrading is / will be worth it. ----- There's an issue to run fzf, which was partially done last year: https://github.com/oilshell/oil/issues/322 https://github.com/oilshell/oil/issues/322 I could use help looking into what remains there! And there are more such issues here: https://github.com/oilshell/oil/labels/should-run-this https://github.com/oilshell/oil/labels/should-run-this Just running these scripts and localizing the error is a big help! And that would get us closer to a new shell that can be realistically adopted. Oil has run thousands of lines of unmodified bash scripts, and many thousands more with minor patches, including some of the biggest shell scripts in the world: https://www.oilshell.org/blog/2020/04/release-0.8.pre4.html https://www.oilshell.org/blog/2020/04/release-0.8.pre4.html
- fmakunbound 6y ago
  Thanks for the Oil shell suggestion. I will definitely check it out this evening. I don't care for POSIX compatibility. I'm a long time Bash user, I've written programs I probably should not have in Bash, and I'm familiar with most of the pitfalls described in a recent HN post https://news.ycombinator.com/item?id=24401085 https://news.ycombinator.com/item?id=24401085 however, after reading through them I thought this is some serious bullshit one must contend with and went looking or alternate shells. Elvish being one of them.
  - chubot 6y ago
    If you've written programs you shouldn't have in bash, then you're very much the target user for Oil :) As stated on the home page, it's our upgrade path from bash to a better language and runtime. So I would be interested if those programs run under Oil. Many do, and if they don't, the fix is usually small. Other programs I've run include Lisp and brainfuck interpreters in bash. And thousands of lines of bash completion scripts. If the programs run, you can opt into strictness checks to improve them / find bugs. And if you want to drop bash compatibility, you can use the new Oil language. (still in progress, but you can try it right now) The goal of Oil is very much to REMOVE all the pitfalls in that thread! It's done with option groups shopt -s oil:basic or shopt -s oil:all. Feel free to contact me on Github or Zulip about it. If you have bash programs, that makes it more interesting. I'm looking for feedback to help shape the Oil language :) Based on my experience I think only 10% of bash users write a program that's longer than 5 lines, or use any bash features. Most people just use what their distro provides (which is what I did for years as well).
xiaq 6y ago
fzf is indeed a very neat standalone tool, and for the use cases it has been optimized for, it is superior to Elvish's UI in many aspects. However, Elvish also has a very expressive programming language, and eventually it will offer more options in programmability.

simias 6y ago

FZF is amazing and I highly recommend it as well, but this project seems to go beyond what FZF provides. This bit in particular: curl https://api.github.com/repos/elves/elvish/issues | from-json | all (one) | each [issue]{ echo $issue[number]: $issue[title] } | head -n 11 That being said I'm still not willing to switch to a non-standard shell syntax, too difficult to use third party servers after that. Also un*x shells are inherently limited by the underlying concept of pipes exchanging only byte streams with no metadata or higher level constructs. You can hack your way around that (as this project seems to be doing) but it's always going to be kludgy. In particular you can't expect any third-party command to play by your rules.

guitarbill 6y ago
presumably you can get jq to do something similar, well enough for 95% of the time, which is the issue. like you, i'm not saying new shells don't have a place, but adoption is really the problem. you can get around this if the features are compelling enough. personally, i like fish. certainly, it was a rough adoption curve, but worth it IMO so i can stop setting up and tweaking zsh, plus the built-in auto-complete is fzf-ish enough for me. and i'm told people use powershell even on non-Windows systems. it's just a very tough sell.
xiaq 6y ago
> too difficult to use third party servers after that Just "scp" the binary to the server and you're good to go :)
- fmakunbound 6y ago
  Yeah this one of the selling points, IMO. It's a gigantic Go static executable and easily available for a wide variety of architectures.
vlowther 6y ago
Eh, last time I messed with I lost interest after noting that from-json | to-json would silently convert all numbers into quoted strings and do terrible things when nil was involved. It made non-trivial JSON manipulation not worth it. They might have fixed it by now.
- xiaq 6y ago
  Yes, Elvish now has a dedicated number type, so conversation from JSON is now lossless.
  - vlowther 6y ago
    Excellent -- nil handling work as well?
    - xiaq 6y ago
      Yes, Elvish's $nil maps to JSON's null.

chubot 6y ago

If you want familiar syntax, Oil is the most bash-compatible shell by a mile (which means it's also POSIX compliant). But you can opt in to a bunch of fixes for longstanding shell warts, shown here: https://www.oilshell.org/release/0.8.0/doc/idioms.html https://www.oilshell.org/release/0.8.0/doc/idioms.html So upgrading is / will be worth it. ----- There's an issue to run fzf, which was partially done last year: https://github.com/oilshell/oil/issues/322 https://github.com/oilshell/oil/issues/322 I could use help looking into what remains there! And there are more such issues here: https://github.com/oilshell/oil/labels/should-run-this https://github.com/oilshell/oil/labels/should-run-this Just running these scripts and localizing the error is a big help! And that would get us closer to a new shell that can be realistically adopted. Oil has run thousands of lines of unmodified bash scripts, and many thousands more with minor patches, including some of the biggest shell scripts in the world: https://www.oilshell.org/blog/2020/04/release-0.8.pre4.html https://www.oilshell.org/blog/2020/04/release-0.8.pre4.html

fmakunbound 6y ago
Thanks for the Oil shell suggestion. I will definitely check it out this evening. I don't care for POSIX compatibility. I'm a long time Bash user, I've written programs I probably should not have in Bash, and I'm familiar with most of the pitfalls described in a recent HN post https://news.ycombinator.com/item?id=24401085 https://news.ycombinator.com/item?id=24401085 however, after reading through them I thought this is some serious bullshit one must contend with and went looking or alternate shells. Elvish being one of them.
- chubot 6y ago
  If you've written programs you shouldn't have in bash, then you're very much the target user for Oil :) As stated on the home page, it's our upgrade path from bash to a better language and runtime. So I would be interested if those programs run under Oil. Many do, and if they don't, the fix is usually small. Other programs I've run include Lisp and brainfuck interpreters in bash. And thousands of lines of bash completion scripts. If the programs run, you can opt into strictness checks to improve them / find bugs. And if you want to drop bash compatibility, you can use the new Oil language. (still in progress, but you can try it right now) The goal of Oil is very much to REMOVE all the pitfalls in that thread! It's done with option groups shopt -s oil:basic or shopt -s oil:all. Feel free to contact me on Github or Zulip about it. If you have bash programs, that makes it more interesting. I'm looking for feedback to help shape the Oil language :) Based on my experience I think only 10% of bash users write a program that's longer than 5 lines, or use any bash features. Most people just use what their distro provides (which is what I did for years as well).

xiaq 6y ago

fzf is indeed a very neat standalone tool, and for the use cases it has been optimized for, it is superior to Elvish's UI in many aspects. However, Elvish also has a very expressive programming language, and eventually it will offer more options in programmability.