8 ms·

How hard would it to be to make an entirely new shell language that doesn't feel like it's 30+ years old? Why isn't this more common? I'm aware of, like, TermK

by ajkjk 10y ago

How hard would it to be to make an entirely new shell language that doesn't feel like it's 30+ years old? Why isn't this more common? I'm aware of, like, TermKit[0], but that didn't get finished and I don't recall hearing about any newer efforts. [0]: https://github.com/unconed/TermKit https://github.com/unconed/TermKit

chubot 10y ago
That's exactly what I'm doing :). The rest of the blog goes into some detail, although it's still in the early stages: http://www.oilshell.org/blog/ http://www.oilshell.org/blog/ You can also see a list of other shells on the GitHub wiki page titled ExternalResources: https://github.com/oilshell/oil/wiki/ExternalResources https://github.com/oilshell/oil/wiki/ExternalResources I'm focusing on the shell as a programming language at first, in contrast to TermKit.
mamcx 10y ago
Build it is not the "hard" part. Anyway you can say a lot of languages are almost there (python, ruby, perl, forth, rebol). Is that developer are THE WORST. Them will refuse to switch to anything better if it means to a small change in his old ways. That is why C/C++/Js/Bash rule the world...
- mamcx 10y ago
  BTW, I have thinking in build a shell/ipython hybrid. I think is worthless to try to emulate a shell (too much baggage), but instead build something that is alike a shell, but modern. However, still developers will not buy it. I think maybe it could work for a subset of the user that need to work with data-science and subset of system automation.
  - naringas 10y ago
    have you heard about xonsh? http://xon.sh/ http://xon.sh/
    - XorNot 10y ago
      I'm using xonsh at work, but currently the main thing I've noticed is that I still prefer iPython QT for exploring data and that xonsh starts up too slowly. Last I checked I think the thing I'm missing from using iPython purely as a shell is the ability to pipe?
- hyperpape 10y ago
  It's somewhat difficult to come up with a good syntax. You need to support: unquoted strings, executing commands, pipes, file redirects, etc. Adoption would be even harder, but any resulting language is not going to look like Python or any other "mainstream" language, if it's intended to actually be usable.
  - chubot 10y ago
    Yeah this is a problem, but after writing a bash parser I think it's straightforward to solve. Oil is parsed line by line like any other shell, and there will be a simple rule to determine whether you're in command mode or expression mode. The "lexer modes" technique (previous referred to as "lexical state") should handle the two sublanguages easily. You basically need it to parse bash, and you will need much less of it to parse oil. My bash parser has 13 lexical states (up from 8), but I expect oil to have somewhere between 4 and 8. How it's used in the bash parser: http://www.oilshell.org/blog/2016/10/19.html http://www.oilshell.org/blog/2016/10/19.html
    - hyperpape 10y ago
      I'm not talking about implementation, but rather designing a clear and consistent syntax. It sounds like your intent is to hew pretty closely to existing shells, in which case you're probably doing more detail work.
      - chubot 10y ago
        The strategy is to break compatibility with bash but provide an upgrade path, as mentioned here: https://news.ycombinator.com/item?id=13478291 https://news.ycombinator.com/item?id=13478291 It is a design issue to combine command and expression syntax (unquoted and vs. quoted literals). But I think I've figured it out ... we'll see in a few months! The blog will have updates on these kinds of issues.
        hyperpape 10y ago
        But are you maintaining POSIX compatibility? I thought I'd read that somewhere on your blog, but I might misremember.
- StillBored 10y ago
  Beh, I guess i'm getting old then, because I spent ~10 years of my life (over 10 years ago) learning dozens of scripting and programming languages, and programming professionally in quite a number of them. The takeaway after all that was, rarely is one language better than another, its really about trade-offs. And frankly the older ones are a lot better at following the KISS principal and actually providing an uncluttered framework for writing _EFFICIENT_ code. For example, everyone knows that Java is a "better" and more productive language than COBOL, yet when you start talking to people trying to port old COBOL apps to java, what you discover is that it turns out that COBOL might actually do a better job in the business/transaction space. Same with python and Fortran in the HPC space, and strangely enough the core infrastructure all these more modern efficient languages are running on tends to be "C" based. Which despite the laundry list of issues that people like to parade around, seems to solve systems programming problems better than anything else. None of this would really be a problem except for the fact that the new up and coming language that is cool this year changes from year to year leaving a wasteland of abandoned poorly maintained projects using languages that no one really knew, and are despised by the people who are hired and have to learn them for that one job before moving on to the next one. So, yes bash is a POS, but its universal at this point, isn't really that bad at solving the core problems its designed to solve, and any developer with 1/2 a brain can write a sys V init script (or a lot of similar things) with little more than a couple hours and without the baggage of yet another 1/2GB language/framework/etc pulled in to sit alongside the dozen others already in the project. </rant> Now get off my yard.
p10_user 10y ago
What about fish? I use it on the terminal but still write my shell scripts in bash so they work across systems (including windows with minGW). I think a big issue with new shell adoption is the prevalence of bash basically everywhere.
- kevin_thibedeau 10y ago
  > I think a big issue with new shell adoption is the prevalence of bash basically everywhere. Which is better than the days when csh and different Bourne flavors were common.
- djsumdog 10y ago
  I've been using fish for over two years and love it. But the thing about fish is that is does totally break things that are expecting a sh/bash environment. There is more use out there and I've seen a number of shell tools/plugins include what to add to the fish config right under the bash and zsh sections (that's how I originally found out about fish). Fish does have bugs though. I've seen enough stack traces while running early builds to question the security (although I'm sure we all remember the bash shell-shcok bug that was laying around for years). If you haven't tried fish, I highly recommend it. It takes a little getting use to, but overall it adds a lot of really amazing functionality that I find really useful.
  - wtbob 10y ago
    > If you haven't tried fish, I highly recommend it. It takes a little getting use to, but overall it adds a lot of really amazing functionality that I find really useful. Serious question (that I've asked elsethread): what does fish offer than zsh & bash lack? A quick perusal of the docs reveals nothing obvious, but … I could be missing stuff.
    - ash 10y ago
      Other people indeed chimed in on your question in other comments. But here's my take about the most important fish features: * Instant auto suggestions, you just type stuff, like in a web browser. * Sane defaults, no need to bring around your own config. On a new machine I just install fish, run fish_config and customize the prompt with the web UI. * Scripting with simple syntax, especially for one-liners. Yes, fish is incompatible with bash, but it's less of issue in this case.
taeric 10y ago
Because there are many more than 30 years of learnings in the current shells that people ignore when building substitutes.
- chubot 10y ago
  Yes I agree... that's why I took the trouble to write a very complete bash parser, which taught me a few things, and improved the Oil language design. Some features are plain mistakes, but some of them are useful things that newer shells aren't taking into account (particularly with regard to file descriptors). I'm aiming for a superset of bash semantics, but with different syntax. Importantly, it will be backward compatible, because bash can be converted to oil automatically. (I'm working on that now, not released yet.) http://www.oilshell.org/blog/2016/11/09.html http://www.oilshell.org/blog/2016/11/09.html The rest of the blog has a bunch of shell corner cases, like: http://www.oilshell.org/blog/2016/11/06.html http://www.oilshell.org/blog/2016/11/06.html http://www.oilshell.org/blog/2016/10/28.html http://www.oilshell.org/blog/2016/10/28.html Although I probably only blogged about 20% of the weird stuff I found.
  - taeric 10y ago
    Awesome posts, best of luck in this! Any suggestions/requests for users to help? And I realize I made an omission in my post. I meant to say not just learnings, but use. I would think the biggest hurdle for you will be building a user base.
    - chubot 10y ago
      Thanks a lot! I'm hoping to set things up for contributions in the next couple months. I'm want to publish the test matrix and get some help because filling out the corners takes a lot of time. The general architecture is pretty sound though -- I hit all the "major areas" of shell, although I may need to make another pass at globbing. If you are adventurous you should be able to clone it, follow the instructions for ./pybuild.sh. Then ./spec.sh install-shells, and then run './spec.sh smoke'. That test should pass, but there are like 15-20 other categories in spec.sh in various states of disarray! Of course this is in Python, but to me it makes sense to fill out a sketch before porting it to C++ (only the runtime; I'm hoping to bootstrap the parsers in oil itself). Not sure if that will inhibit or help contribution.
kazinator 10y ago
Unless you drop the requirement that the shell supports this type of usage: command arg1 arg2 ... then whatever is built to this requirement is going to feel decades old to some extent.
- chubot 10y ago
  Why? There's nothing old about that syntax. On the contrary, I don't think anyone would use a shell WITHOUT the "cmd arg1 arg2" syntax. I certainly wouldn't want to. What feels ancient is the lack of good parse error messages and runtime error messages in bash. And syntax like a=X but not a = X or a = 'X' -- the difference being the spaces. And (echo hi) is OK for a subshell, but you need { echo hi; } for a group -- space and ; are required in the latter case, but not the former. The lack of proper functions in shell also feels ancient. For example, writing a completion function in bash is a pretty horrible experience. As another example, a simple function to escape HTML is either 'sed' or three statements like ${foo/&/&}, both of which are obtuse.
nextos 10y ago
I admire Unix, but I also feel things are getting old. I have a minimal Unix setup, with lots of little programs that do one thing and do it well. For example, mutt is my MUA (mail user agent). It just reads my emails, but fetching or sending is carried out by other programs. Fine. Now, the issue is that every little Unix utility that is non-trivial comes with its own little DSL for configuration. Most are inflexible, naive and different to each other. It's hard to script mutt. If you want to do some stuff the author hasn't planned for, you are better off patching the code. Flexibility, and composability, is not as good as they preach. For this reason, I am migrating everything to emacs. It offers me what Unix only promises but falls short at. Everything is an elisp function and thus easy to combine. Things are more organic. And still minimal.
- pjmlp 10y ago
  > I admire Unix, but I also feel things are getting old. " We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy." Rob Pike, https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...
  - nextos 10y ago
    Yes, it's a very good quote. It's sad most Plan 9 and Inferno innovations, just to name two further developments of Unix, have been ignored. But overall, I am more comfortable on live environments like Smalltalk or Emacs. There's just one fundamental abstraction, and things can be composed beautifully. In Unix, on the other hand, everything is not a file. And even if it was, little applications like mutt are silos. The code is static, it can't be easily changed or opened. A file interface, in the form of STDIN/STDOUT is too unstructured.
    - pjmlp 10y ago
zeveb 10y ago
I think that sweet-expressions (http://readable.sourceforge.net/ http://readable.sourceforge.net/) & CL-INTERPOL (http://weitz.de/cl-interpol/ http://weitz.de/cl-interpol/) could be the basis for a new kind of shell: let (foo bar) ls foo "bim/baz" ${foo} Might be turned into the equivalent of 'ls foo bim/baz bar' in sh. In fact, with a minimum of work I think this could be turned into a Lisp shell …
equalunique 10y ago
There's Microsoft PowerShell, an OO shell recently MIT-licensed and ported to Linux. Just throwing that one out there.

by ajkjk 10y ago

chubot 10y ago

That's exactly what I'm doing :). The rest of the blog goes into some detail, although it's still in the early stages: http://www.oilshell.org/blog/ http://www.oilshell.org/blog/ You can also see a list of other shells on the GitHub wiki page titled ExternalResources: https://github.com/oilshell/oil/wiki/ExternalResources https://github.com/oilshell/oil/wiki/ExternalResources I'm focusing on the shell as a programming language at first, in contrast to TermKit.

mamcx 10y ago

Build it is not the "hard" part. Anyway you can say a lot of languages are almost there (python, ruby, perl, forth, rebol). Is that developer are THE WORST. Them will refuse to switch to anything better if it means to a small change in his old ways. That is why C/C++/Js/Bash rule the world...

mamcx 10y ago
BTW, I have thinking in build a shell/ipython hybrid. I think is worthless to try to emulate a shell (too much baggage), but instead build something that is alike a shell, but modern. However, still developers will not buy it. I think maybe it could work for a subset of the user that need to work with data-science and subset of system automation.
- naringas 10y ago
  have you heard about xonsh? http://xon.sh/ http://xon.sh/
  - XorNot 10y ago
    I'm using xonsh at work, but currently the main thing I've noticed is that I still prefer iPython QT for exploring data and that xonsh starts up too slowly. Last I checked I think the thing I'm missing from using iPython purely as a shell is the ability to pipe?
hyperpape 10y ago
It's somewhat difficult to come up with a good syntax. You need to support: unquoted strings, executing commands, pipes, file redirects, etc. Adoption would be even harder, but any resulting language is not going to look like Python or any other "mainstream" language, if it's intended to actually be usable.
- chubot 10y ago
  Yeah this is a problem, but after writing a bash parser I think it's straightforward to solve. Oil is parsed line by line like any other shell, and there will be a simple rule to determine whether you're in command mode or expression mode. The "lexer modes" technique (previous referred to as "lexical state") should handle the two sublanguages easily. You basically need it to parse bash, and you will need much less of it to parse oil. My bash parser has 13 lexical states (up from 8), but I expect oil to have somewhere between 4 and 8. How it's used in the bash parser: http://www.oilshell.org/blog/2016/10/19.html http://www.oilshell.org/blog/2016/10/19.html
  - hyperpape 10y ago
    I'm not talking about implementation, but rather designing a clear and consistent syntax. It sounds like your intent is to hew pretty closely to existing shells, in which case you're probably doing more detail work.
    - chubot 10y ago
      The strategy is to break compatibility with bash but provide an upgrade path, as mentioned here: https://news.ycombinator.com/item?id=13478291 https://news.ycombinator.com/item?id=13478291 It is a design issue to combine command and expression syntax (unquoted and vs. quoted literals). But I think I've figured it out ... we'll see in a few months! The blog will have updates on these kinds of issues.
      - hyperpape 10y ago
        But are you maintaining POSIX compatibility? I thought I'd read that somewhere on your blog, but I might misremember.
StillBored 10y ago
Beh, I guess i'm getting old then, because I spent ~10 years of my life (over 10 years ago) learning dozens of scripting and programming languages, and programming professionally in quite a number of them. The takeaway after all that was, rarely is one language better than another, its really about trade-offs. And frankly the older ones are a lot better at following the KISS principal and actually providing an uncluttered framework for writing _EFFICIENT_ code. For example, everyone knows that Java is a "better" and more productive language than COBOL, yet when you start talking to people trying to port old COBOL apps to java, what you discover is that it turns out that COBOL might actually do a better job in the business/transaction space. Same with python and Fortran in the HPC space, and strangely enough the core infrastructure all these more modern efficient languages are running on tends to be "C" based. Which despite the laundry list of issues that people like to parade around, seems to solve systems programming problems better than anything else. None of this would really be a problem except for the fact that the new up and coming language that is cool this year changes from year to year leaving a wasteland of abandoned poorly maintained projects using languages that no one really knew, and are despised by the people who are hired and have to learn them for that one job before moving on to the next one. So, yes bash is a POS, but its universal at this point, isn't really that bad at solving the core problems its designed to solve, and any developer with 1/2 a brain can write a sys V init script (or a lot of similar things) with little more than a couple hours and without the baggage of yet another 1/2GB language/framework/etc pulled in to sit alongside the dozen others already in the project. </rant> Now get off my yard.

p10_user 10y ago

What about fish? I use it on the terminal but still write my shell scripts in bash so they work across systems (including windows with minGW). I think a big issue with new shell adoption is the prevalence of bash basically everywhere.

kevin_thibedeau 10y ago
> I think a big issue with new shell adoption is the prevalence of bash basically everywhere. Which is better than the days when csh and different Bourne flavors were common.
djsumdog 10y ago
I've been using fish for over two years and love it. But the thing about fish is that is does totally break things that are expecting a sh/bash environment. There is more use out there and I've seen a number of shell tools/plugins include what to add to the fish config right under the bash and zsh sections (that's how I originally found out about fish). Fish does have bugs though. I've seen enough stack traces while running early builds to question the security (although I'm sure we all remember the bash shell-shcok bug that was laying around for years). If you haven't tried fish, I highly recommend it. It takes a little getting use to, but overall it adds a lot of really amazing functionality that I find really useful.
- wtbob 10y ago
  > If you haven't tried fish, I highly recommend it. It takes a little getting use to, but overall it adds a lot of really amazing functionality that I find really useful. Serious question (that I've asked elsethread): what does fish offer than zsh & bash lack? A quick perusal of the docs reveals nothing obvious, but … I could be missing stuff.
  - ash 10y ago
    Other people indeed chimed in on your question in other comments. But here's my take about the most important fish features: * Instant auto suggestions, you just type stuff, like in a web browser. * Sane defaults, no need to bring around your own config. On a new machine I just install fish, run fish_config and customize the prompt with the web UI. * Scripting with simple syntax, especially for one-liners. Yes, fish is incompatible with bash, but it's less of issue in this case.

taeric 10y ago

Because there are many more than 30 years of learnings in the current shells that people ignore when building substitutes.

chubot 10y ago
Yes I agree... that's why I took the trouble to write a very complete bash parser, which taught me a few things, and improved the Oil language design. Some features are plain mistakes, but some of them are useful things that newer shells aren't taking into account (particularly with regard to file descriptors). I'm aiming for a superset of bash semantics, but with different syntax. Importantly, it will be backward compatible, because bash can be converted to oil automatically. (I'm working on that now, not released yet.) http://www.oilshell.org/blog/2016/11/09.html http://www.oilshell.org/blog/2016/11/09.html The rest of the blog has a bunch of shell corner cases, like: http://www.oilshell.org/blog/2016/11/06.html http://www.oilshell.org/blog/2016/11/06.html http://www.oilshell.org/blog/2016/10/28.html http://www.oilshell.org/blog/2016/10/28.html Although I probably only blogged about 20% of the weird stuff I found.
- taeric 10y ago
  Awesome posts, best of luck in this! Any suggestions/requests for users to help? And I realize I made an omission in my post. I meant to say not just learnings, but use. I would think the biggest hurdle for you will be building a user base.
  - chubot 10y ago
    Thanks a lot! I'm hoping to set things up for contributions in the next couple months. I'm want to publish the test matrix and get some help because filling out the corners takes a lot of time. The general architecture is pretty sound though -- I hit all the "major areas" of shell, although I may need to make another pass at globbing. If you are adventurous you should be able to clone it, follow the instructions for ./pybuild.sh. Then ./spec.sh install-shells, and then run './spec.sh smoke'. That test should pass, but there are like 15-20 other categories in spec.sh in various states of disarray! Of course this is in Python, but to me it makes sense to fill out a sketch before porting it to C++ (only the runtime; I'm hoping to bootstrap the parsers in oil itself). Not sure if that will inhibit or help contribution.

kazinator 10y ago

Unless you drop the requirement that the shell supports this type of usage: command arg1 arg2 ... then whatever is built to this requirement is going to feel decades old to some extent.

chubot 10y ago
Why? There's nothing old about that syntax. On the contrary, I don't think anyone would use a shell WITHOUT the "cmd arg1 arg2" syntax. I certainly wouldn't want to. What feels ancient is the lack of good parse error messages and runtime error messages in bash. And syntax like a=X but not a = X or a = 'X' -- the difference being the spaces. And (echo hi) is OK for a subshell, but you need { echo hi; } for a group -- space and ; are required in the latter case, but not the former. The lack of proper functions in shell also feels ancient. For example, writing a completion function in bash is a pretty horrible experience. As another example, a simple function to escape HTML is either 'sed' or three statements like ${foo/&/&}, both of which are obtuse.

nextos 10y ago

I admire Unix, but I also feel things are getting old. I have a minimal Unix setup, with lots of little programs that do one thing and do it well. For example, mutt is my MUA (mail user agent). It just reads my emails, but fetching or sending is carried out by other programs. Fine. Now, the issue is that every little Unix utility that is non-trivial comes with its own little DSL for configuration. Most are inflexible, naive and different to each other. It's hard to script mutt. If you want to do some stuff the author hasn't planned for, you are better off patching the code. Flexibility, and composability, is not as good as they preach. For this reason, I am migrating everything to emacs. It offers me what Unix only promises but falls short at. Everything is an elisp function and thus easy to combine. Things are more organic. And still minimal.

pjmlp 10y ago
> I admire Unix, but I also feel things are getting old. " We really are using a 1970s era operating system well past its sell-by date. We get a lot done, and we have fun, but let's face it, the fundamental design of Unix is older than many of the readers of Slashdot, while lots of different, great ideas about computing and networks have been developed in the last 30 years. Using Unix is the computing equivalent of listening only to music by David Cassidy." Rob Pike, https://interviews.slashdot.org/story/04/10/18/1153211/rob-pike-responds https://interviews.slashdot.org/story/04/10/18/1153211/rob-p...
- nextos 10y ago
  Yes, it's a very good quote. It's sad most Plan 9 and Inferno innovations, just to name two further developments of Unix, have been ignored. But overall, I am more comfortable on live environments like Smalltalk or Emacs. There's just one fundamental abstraction, and things can be composed beautifully. In Unix, on the other hand, everything is not a file. And even if it was, little applications like mutt are silos. The code is static, it can't be easily changed or opened. A file interface, in the form of STDIN/STDOUT is too unstructured.
  - pjmlp 10y ago

zeveb 10y ago

I think that sweet-expressions (http://readable.sourceforge.net/ http://readable.sourceforge.net/) & CL-INTERPOL (http://weitz.de/cl-interpol/ http://weitz.de/cl-interpol/) could be the basis for a new kind of shell: let (foo bar) ls foo "bim/baz" ${foo} Might be turned into the equivalent of 'ls foo bim/baz bar' in sh. In fact, with a minimum of work I think this could be turned into a Lisp shell …

equalunique 10y ago

There's Microsoft PowerShell, an OO shell recently MIT-licensed and ported to Linux. Just throwing that one out there.