4 ms·

No, it is not. That might be desirable though depending on your perspective or use-case https://elv.sh/ref/language.html https://elv.sh/ref/language.html

chrisweekly 6y ago
FWIW, XONSH (https://xon.sh https://xon.sh - pronounced "konsh") is a POSIX-compliant shell that lets you write everything in Python. (I don't use it, but my cousin is one of its authors.)
- chubot 6y ago
  My memory of how it works is that it's only POSIX complaint because it does os.system() to a POSIX compliant shell. It parses some Python syntax on the command line and then uses Python's eval() to handle it. And then for shell parts it calls os.system(). My memory is fuzzy though so I'd be happy for a correction ...
  - em-bee 6y ago
    other than seeming inefficient, does doing that have any negative side effects or cause problems somehow?
    - chubot 6y ago
      Well, I'm biased because I'm working on Oil, and I'm sure the xonsh developers are aiming at something very different. However on top of actually being slow (not just seeming slow) [1], I see it as a huge problem because it makes for an ill-defined language. The behavior of your shell now depends on whatever /bin/sh and Python interpreter is on your machine. When you change Python versions, are your xonsh commands going to break? What about when you change shell versions? What happens when you copy some xonsh from one machine to another, with possibly different versions? Do they still work? Some people might say that it's for interactive use, not for programs. But to me the point of shell is that you can seamlessly cut and paste your interactive sessions and now you have full automation. It's an amazing way to quickly build programs. In other words, shell is the language with the best REPL. And it has the biggest standard library [2] ----- Oil takes a very principled approach to parsing, e.g. http://www.oilshell.org/blog/tags.html?tag=parsing-shell#parsing-shell http://www.oilshell.org/blog/tags.html?tag=parsing-shell#par... while the xonsh approach is just about the most unprincipled approach there is. Again, I think they were aiming at something very different, but to me it falls short of what I want in a shell (and what other people have told me they want.) ----- [1] I have some experience with running the bash completion scripts that xosnh scrapes: http://www.oilshell.org/blog/2018/10/10.html http://www.oilshell.org/blog/2018/10/10.html . It is indeed slow. [2] https://news.ycombinator.com/item?id=24083764 https://news.ycombinator.com/item?id=24083764
      - em-bee 6y ago
        Some people might say that it's for interactive use, not for programs. But to me the point of shell is that you can seamlessly cut and paste your interactive sessions and now you have full automation. It's an amazing way to quickly build programs. one could argue that a shell based on python should be especially suitable for turning your commandline into scripts. i have never tried xonsh but i have used the python repl to interactively build a python script xonsh approach is just about the most unprincipled approach there is could you possibly elaborate on that please?
        chubot 6y ago
        It's not Python though.. it's a tightly coupled mix of Python, shell and other stuff. You would have to extract the Python to actually run it with a Python interpreter, in which case you don't need xonsh at all. What I mean by unprincipled is that it doesn't parse or define its language. It passes the problem off to other programs (sh and Python).

chrisweekly 6y ago

FWIW, XONSH (https://xon.sh https://xon.sh - pronounced "konsh") is a POSIX-compliant shell that lets you write everything in Python. (I don't use it, but my cousin is one of its authors.)

chubot 6y ago
My memory of how it works is that it's only POSIX complaint because it does os.system() to a POSIX compliant shell. It parses some Python syntax on the command line and then uses Python's eval() to handle it. And then for shell parts it calls os.system(). My memory is fuzzy though so I'd be happy for a correction ...
- em-bee 6y ago
  other than seeming inefficient, does doing that have any negative side effects or cause problems somehow?
  - chubot 6y ago
    Well, I'm biased because I'm working on Oil, and I'm sure the xonsh developers are aiming at something very different. However on top of actually being slow (not just seeming slow) [1], I see it as a huge problem because it makes for an ill-defined language. The behavior of your shell now depends on whatever /bin/sh and Python interpreter is on your machine. When you change Python versions, are your xonsh commands going to break? What about when you change shell versions? What happens when you copy some xonsh from one machine to another, with possibly different versions? Do they still work? Some people might say that it's for interactive use, not for programs. But to me the point of shell is that you can seamlessly cut and paste your interactive sessions and now you have full automation. It's an amazing way to quickly build programs. In other words, shell is the language with the best REPL. And it has the biggest standard library [2] ----- Oil takes a very principled approach to parsing, e.g. http://www.oilshell.org/blog/tags.html?tag=parsing-shell#parsing-shell http://www.oilshell.org/blog/tags.html?tag=parsing-shell#par... while the xonsh approach is just about the most unprincipled approach there is. Again, I think they were aiming at something very different, but to me it falls short of what I want in a shell (and what other people have told me they want.) ----- [1] I have some experience with running the bash completion scripts that xosnh scrapes: http://www.oilshell.org/blog/2018/10/10.html http://www.oilshell.org/blog/2018/10/10.html . It is indeed slow. [2] https://news.ycombinator.com/item?id=24083764 https://news.ycombinator.com/item?id=24083764
    - em-bee 6y ago
      Some people might say that it's for interactive use, not for programs. But to me the point of shell is that you can seamlessly cut and paste your interactive sessions and now you have full automation. It's an amazing way to quickly build programs. one could argue that a shell based on python should be especially suitable for turning your commandline into scripts. i have never tried xonsh but i have used the python repl to interactively build a python script xonsh approach is just about the most unprincipled approach there is could you possibly elaborate on that please?
      - chubot 6y ago
        It's not Python though.. it's a tightly coupled mix of Python, shell and other stuff. You would have to extract the Python to actually run it with a Python interpreter, in which case you don't need xonsh at all. What I mean by unprincipled is that it doesn't parse or define its language. It passes the problem off to other programs (sh and Python).