3 ms·

Your ideas are something I wrestled with while I was writing (a very similarly named) crsh[0]. I chose to avoid trying to reimplementing commands and instead st

by cnity 6y ago

Your ideas are something I wrestled with while I was writing (a very similarly named) crsh[0]. I chose to avoid trying to reimplementing commands and instead stuck with an unstructured environment, but with the ability to parse output using an expandable set of parsers and use inline JavaScript to operate on it. I agree with what you say about perl, but the number of users with experience in perl is -- at least in my bubble -- very small compared with more modern languages. [0] https://crwi.uk/2020/07/12/crsh.html https://crwi.uk/2020/07/12/crsh.html

dividedbyzero 6y ago
While I have some relatively extensive experience with Perl, I'd rather write assembler using morse than touch that ever again. The language is one guy's not-too-well-thought-through hack that gained enormous traction by filling a void, and from there grew far too organically. There are lots and lots of cryptic ways to do the most mundane things, lots of inconsistencies, the language really makes it hard to write software that isn't terrible to maintain.
- cnity 6y ago
  Exactly. This is common with shell scripting languages. They feel like some awful duct tape, when in fact the perfect primitive for joining separate concerns already exists (the pipe). Using a nicer language (like modern JS) to perform procedural logic makes perfect sense to me.
  - inshadows 6y ago
    > Using a nicer language (like modern JS) to perform procedural logic makes perfect sense to me. # ls | grep foo This involves two programs written in nicer language (C). # ls | rg foo This involves two programs written in nicer language (C & Rust). Feel free to come up with JS program that does something well and/or is usable in pipeline. I think you're missing the point of the shell.
- gridlockd 6y ago
  Aren't we talking about "a better shell scripting language"? At the point where a Perl program becomes "hard to maintain", what would the bash alternative even look like? Perl code is often written once and then runs for years without issue. I have on occasion fixed broken Perl scripts despite having practically no experience with the language. It wasn't a problem at all, because your average maintenance job is "something was moved" or "we're switching out X for Y", but not "we need to rewrite this complex system that is a Perl script for some reason".
  - licebmi__at__ 6y ago
    >It wasn't a problem at all, because your average maintenance job is "something was moved" or "we're switching out X for Y", but not "we need to rewrite this complex system that is a Perl script for some reason". I would intuitively agree with you as there are hundreds of unnoticeable perl scripts doing their job, but as someone with moderate experience with the language, I can say that when I did maintenance tasks, they were mostly the second kind.
- zeveb 6y ago
  You are right, but none of those criticisms apply to Tcl, which is both beautiful and integrates really well with the Unix environment. I won't say that it is perfect, but it is really, really good. A better choice than Perl where Perl is used, a better choice than Lua almost everywhere Lua is used, often a better choice than Python. Tcl is horribly, terribly under-appreciated. It is one of the great might-have-beens of modern computing, almost as much as is Lisp.
  - yumaikas 6y ago
    Eh, having used both Tcl and Lua, I definitely think Lua is the better of the two when it comes to a scripting engine for games. And I think Lua is more elegant than TCL overall. TCL's stringiness really gets clumsy in certain types of programs, and it's a much larger target than Lua overall. Not to say that TCL is bad, but I'm glad that dict-based languages prevailed over TCL's string-based-ness
mhotchen 6y ago
This is a very interesting project. I really like the combination of languages and the way you've implemented it. I already see some opportunities to use it.
- cnity 6y ago
  Thank you! It's pretty buggy at the moment, and maybe frustrating to use since it's missing some important shell features, but any feedback is always welcome.
  - mhotchen 6y ago
    Yeah I've just installed it and seen eg. the autocompletion on ls isn't how I'm used to. I will keep playing around and watch for progress because I really like the idea. I especially see this being useful in my CI environment which has a handful of functions, some json and yaml parsing (using jq and python respectively), etc. It's a little cumbersome at the minute but not so much to switch from bash and the rest of the project is JS anyway so it would be good to be consistent.
    - cnity 6y ago
      Excellent. If there are things you notice, please feel free to raise as an issue, and pull requests are always welcome! > useful in my CI environment For sure. I've been meaning to play around with getting a docker image with the shell set as the default. It's definitely a use-case I had in mind.
  - mhotchen 6y ago
    I'm very impressed with what works so far by the way.

by cnity 6y ago

dividedbyzero 6y ago

While I have some relatively extensive experience with Perl, I'd rather write assembler using morse than touch that ever again. The language is one guy's not-too-well-thought-through hack that gained enormous traction by filling a void, and from there grew far too organically. There are lots and lots of cryptic ways to do the most mundane things, lots of inconsistencies, the language really makes it hard to write software that isn't terrible to maintain.

cnity 6y ago
Exactly. This is common with shell scripting languages. They feel like some awful duct tape, when in fact the perfect primitive for joining separate concerns already exists (the pipe). Using a nicer language (like modern JS) to perform procedural logic makes perfect sense to me.
- inshadows 6y ago
  > Using a nicer language (like modern JS) to perform procedural logic makes perfect sense to me. # ls | grep foo This involves two programs written in nicer language (C). # ls | rg foo This involves two programs written in nicer language (C & Rust). Feel free to come up with JS program that does something well and/or is usable in pipeline. I think you're missing the point of the shell.
gridlockd 6y ago
Aren't we talking about "a better shell scripting language"? At the point where a Perl program becomes "hard to maintain", what would the bash alternative even look like? Perl code is often written once and then runs for years without issue. I have on occasion fixed broken Perl scripts despite having practically no experience with the language. It wasn't a problem at all, because your average maintenance job is "something was moved" or "we're switching out X for Y", but not "we need to rewrite this complex system that is a Perl script for some reason".
- licebmi__at__ 6y ago
  >It wasn't a problem at all, because your average maintenance job is "something was moved" or "we're switching out X for Y", but not "we need to rewrite this complex system that is a Perl script for some reason". I would intuitively agree with you as there are hundreds of unnoticeable perl scripts doing their job, but as someone with moderate experience with the language, I can say that when I did maintenance tasks, they were mostly the second kind.
zeveb 6y ago
You are right, but none of those criticisms apply to Tcl, which is both beautiful and integrates really well with the Unix environment. I won't say that it is perfect, but it is really, really good. A better choice than Perl where Perl is used, a better choice than Lua almost everywhere Lua is used, often a better choice than Python. Tcl is horribly, terribly under-appreciated. It is one of the great might-have-beens of modern computing, almost as much as is Lisp.
- yumaikas 6y ago
  Eh, having used both Tcl and Lua, I definitely think Lua is the better of the two when it comes to a scripting engine for games. And I think Lua is more elegant than TCL overall. TCL's stringiness really gets clumsy in certain types of programs, and it's a much larger target than Lua overall. Not to say that TCL is bad, but I'm glad that dict-based languages prevailed over TCL's string-based-ness

mhotchen 6y ago

This is a very interesting project. I really like the combination of languages and the way you've implemented it. I already see some opportunities to use it.

cnity 6y ago
Thank you! It's pretty buggy at the moment, and maybe frustrating to use since it's missing some important shell features, but any feedback is always welcome.
- mhotchen 6y ago
  Yeah I've just installed it and seen eg. the autocompletion on ls isn't how I'm used to. I will keep playing around and watch for progress because I really like the idea. I especially see this being useful in my CI environment which has a handful of functions, some json and yaml parsing (using jq and python respectively), etc. It's a little cumbersome at the minute but not so much to switch from bash and the rest of the project is JS anyway so it would be good to be consistent.
  - cnity 6y ago
    Excellent. If there are things you notice, please feel free to raise as an issue, and pull requests are always welcome! > useful in my CI environment For sure. I've been meaning to play around with getting a docker image with the shell set as the default. It's definitely a use-case I had in mind.
- mhotchen 6y ago
  I'm very impressed with what works so far by the way.