12 ms·

I think that these 'improved shell' projects (incl. crush and nushell) that try to copy powershell somewhat miss the point of the shell in the first place. If

I think that these 'improved shell' projects (incl. crush and nushell) that try to copy powershell somewhat miss the point of the shell in the first place. If I want a high-level language that's tightly integrated with the unix environment, I already have perl and tcl. Little more power (maybe less integration, but greater capacity to build new integration) and I can use raku or lisp. The point of shell is that it interoperates freely with all programs and all programs share a language. If now, suddenly, I can only use commands that have been explicitly rewritten to support your environment; or regular commands are second-class citizens and need support code to interact with your environment's higher-level functionality—— Then your environment is useless to me. Because I have better programming languages which, despite being able to interact with the system and its commands, don't pretend to be one with the system. As a result, the core high-level language constructs mesh better, because they're not trying to serve two goals at once. It's not possible for something that's not a 'real' shell (including fish, zsh, even csh) to integrate with the system the way a real shell does, because the system itself was designed around the shell.

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.
- 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.
pritambarhate 6y ago
Not many young people know Perl or Tcl (or even lisp for that matter). >> The point of shell is that it interoperates freely with all programs and all programs share a language. Also doesn't mean people should stop trying to come up with these new shells. May be some "new" shell will catch up and tomorrow's "all" programs will be compatible with that shell. For example, now on Mac OS X, now ZSH is the default shell.
- moonchild 6y ago
  I explicitly included zsh. The point is not the language of the shell itself; that has never been the point. The point is that zsh interoperates with the other programs on your system in a way that crush doesn't and can't.
  - viraptor 6y ago
    > a way that crush doesn't and can't What do you mean by can't? If it misses some mode of interaction, that can be always added.
    - ori_b 6y ago
      Consistent behavior when piping through all commands. A lack of modes of operation to consider. Simplicity.
      - viraptor 6y ago
        Simplicity exists on more than a single dimension. Choosing one column from "ls" output for example is not simple, bordering on impossible using the consistent behaviour of standard pipes. Sometimes the inconsistent solution will be simpler by moving the complexity to the choice of the mode of interaction. Sometimes not.
        ori_b 6y ago
        Maybe a shell is the wrong tool for that job, and hiding the modes that the language is operating in complicates things.
hhas01 6y ago
“somewhat miss the point of the shell in the first place” This presupposes that the Unix shell is the way it is because of careful, considered, forward-thinking design, rather than being a haphazard heap of mouldering hacks upon lazy corner-cutting upon quick-n-dirty bodges that should’ve been thrown out and replaced decades ago. I agree that trying to improve the *nix shell is a bad idea… because the _Unix shell itself_ is a bad idea. Fifty years is long enough. Instead of bending over backwards for that obsolescent garbage heap (for which no-one will thank you, as we see), study it, learn its lessons, and draw a line under it. Then go build a clean, modern shell architecture from scratch, using modern tooling and techniques, unhobbled by the myriad defects and deficiencies of the old. It’ll take a tenth of the time and be ten times better (if not, you’re still doing it wrong). See also: https://www.google.com/search?q=sunk+cost+fallacy https://www.google.com/search?q=sunk+cost+fallacy https://homes.cs.washington.edu/~weise/uhh-download.html https://homes.cs.washington.edu/~weise/uhh-download.html -- p.s. As for driving early adoption, don’t even think of trying to win over the Unix old guard (who will only bring regressive practices and complaints with them), but sell it hard to the new generations of users who are accustomed to modern UI/UX standards and much less impressed by what the “Old Unix” dogpile has to offer.
jodrellblank 6y ago
> “because the system itself was designed around the shell.” Windows wasn’t designed around the command prompt, it wasn’t designed around shell utilities. When I call “cat”, it’s not important that I’m writing those three letters, they are a library way of calling a set of file open/read OS functions. When I write “ping”, it’s not the ping tool I care about, it’s the network api calls it does behind the scenes. The Unix/Linux shell is then seen like a “Python standard library” of ways the user can control the OS, and it’s a hugely inconsistent, undesigned, ad-hoc agglomeration of names and parameters and bodges, which cheats out on dealing with the complexity and instead offloads that straight on to the user in a user hostile way. What powershell tries to do for Windows is make a somewhat designed, consistent, and more user-approachable set of wrappers around the Windows OS system calls, along with guidelines and support for vendors to build in that style, a human interface that is introspectable, built to be programmable, but still composable and modular. The objection that trying to do such a user-focused thing on Unix makes a “useless” system is weird because that - a user interface to tools/library of OS call patterns - is what the shell is. In what way is “resolve-dnsname” pretending to be one with the system that dig and nslookup aren’t? They’re names which trigger a pattern of network traffic and show a result. In what way is piping text from dig to sed “real” and piping resolve-dnsname to format-list “pretend”? In what way is running “docker compose” from sh real, but running it from zsh is pretend? In what way is it a better design to have (a pile of shell tools and Python library wrappers and Python wrapping shell tool calls), instead of (a Python based shell with transparent shell tool calls)? Like, “I want what I’m familiar with, too many things to relearn”, or “too many things are awkward in this approach (cough PowerShell)” are reasonable objections, but “trying for a more consistent, more human friendly, interface with more high level language constructs at one’s fingertips makes a thing useless to me” feels heel dragging or Stockholm syndromeish. Presumably you don’t object to there being a choice of multiple command line tools to do a task? Why object on principle to a choice of other OS “front end experiences”? Is there any version of things which you can imagine as being both “better” (less arbitrary and inconsistent than shell) and “not pretend”? > “The point of shell is that it interoperates freely with all programs and all programs share a language.” What language? Some treat piped bytes as bytes (e.g. piping a binary file), others as ASCII, others as UTF-8. All support different parameter options, names and values and ways of specifying them. Many handle output formatting in different ways, many trigger internal states from environment variables. If the point is a common shared language, the point doesn’t seem to have been achieved from a user perspective. And if the point is that “I have to suffer a system that’s tied to a shared language with an AIX box in a bank basement last touched by a human in 1997” the point is a bad one. I use my computer a lot more than I use AIX and I have more computing power to spare on human comforts and conveniences.
moonchild 6y ago
To clarify, I am not saying that everything except for bare /bin/sh without line-editing is Wrong. I wasn't clear enough here. I think that bourne shell, bash, fish, zsh, and csh are all able to interact with the unix system in a way that crush, nushell, and other powershell-alikes cannot.
- throwaway894345 6y ago
  Can you elaborate on that more of interaction? What can bash, etc do that crush, etc can’t. Is this limitation inherent or easily amended?
- liljencrantz 6y ago
  I am the original author of both fish and Crush, and I honestly don't know in what way fish interacts with the OS in a way that Crush by virtue of it's design never could. I know that Crush currently doesn't interact very well with external commands, but I don't see where that is an inherent restriction in the design rather than a missing feature.
kevincox 6y ago
This seems to strike a good compromise as "third party" commands are "lines" type which is basically what we are used to send and receive in unix tools. Of course a lot of tools already support emitting JSON so it seems the Crush is already more useful than the typical unix shell as you can still use "lines" for every program (and convert to a table by parsing if you want to use the more advanced features) and there are already a number of third-party programs that you take directly take advantage of these feature with even though they didn't know anything about this shell. I think the fact that you can already use this with most programs and it is never less powerful than bash seems like good indication that the system doesn't need to be reworked around this shell. It fits in cleanly to existing paradigms.
shawxe 6y ago
You really aren't kidding about Tcl. I recently discovered that with tclreadline, Tcl can be used completely in place of Bash in interactive mode, in a way that something like Python absolutely cannot. A lot of people seem to have negative opinions about Tcl (maybe because it's more of a LISP than its syntax seems to imply), but as someone who is just discovering it, I'm shocked at how powerful it is for how unpopular it seems to have become. It's like some kind of unexpected cross between Bash, LISP, and (with Tk) Visual Basic. There's something about it that's just kind of fun.
- hodgesrm 6y ago
  Tcl is awesome. I used it constantly in the 1990s. It's outstanding for things like testing and build scripts. I think some of the pushback might be because people tried to use it to build large applications and failed. Languages like Java and (dare I say it) Visual Basic were more comprehensive and had good IDE support.
- mr_toad 6y ago
  Tcl has features that are very powerful, but are really hard for a beginner, and really easy for a novice programmer to shoot themselves in the foot with. Yet Tcl tends to be forced on undergraduate programmers, who probably just learn to loathe it. I lost several toes to it myself decades ago, and haven’t really felt inclined to pick it up again.
chubot 6y ago
Right, I'm often asked this about Oil [1]: Why do you want to write programs in shell? That's not the idea of shell. The idea is that I write programs in Python, JavaScript, R, and C++ regularly, and about 10 different DSLs (SQL, HTML, etc.) And I work on systems written by others, consisting of even more languages. I need a language to glue them together. A language to express build automation and describe deployed systems. Most big systems consist of more than one language. Shell is the best language for that, but it's also old and crufty, with poor implementations. When you program in shell, gcc, git, pip, npm, markdown, rsync, diff, perf, strace, etc. are part of your "standard library". [1] http://www.oilshell.org/ http://www.oilshell.org/
- chubot 6y ago
  Update: also see the philosophy for structured data in Oil below: https://news.ycombinator.com/item?id=24083931 https://news.ycombinator.com/item?id=24083931
hodgesrm 6y ago
New shells seem unlikely to catch fire unless they: * Preserve compatibility with popular shells like bash. * Address some of the broken parts in a way that makes the world better. Quote handling is the original sin of *nix shells. If somebody fixed that you would have my full attention. Otherwise I can just stick with Bash + Python3.
- hannasanarion 6y ago
  Which is impossible, which is why no new shells have caught fire. In order to preserve compatibility, you must handle quotes, namespaces, etc in the same way as Bourne-derived shells, because they will be expected to run scripts that use nested interpolation, or string declarations without quotes, or whatever. Shells that use a more robust syntax, like Fish or Powershell, can't ever be compatible.
  - majkinetor 6y ago
    Not exactly true since PowerShell is doing quite good regarding popularity nowdays...
    - mdaniel 6y ago
      From my perspective, that's partially because CMD is so stunningly incapable as what a reasonable person might think of as a shell. I'd guess the other half is the amount of pressure Microsoft has placed upon management tooling using PS If Apple shipped some Swift-powered shell and all of their management documentation started using it, I'd bet a non-trivial portion of administrators would start to use AppleSwiftShell (although I do deeply appreciate that's a severely flawed comparison since macOS already has a sane functioning shell, but it's the best I could think of as a huge company that owns the platform pushing such a concept down)
      - majkinetor 6y ago
        I doubt. Most people still use cmd because they dont care. Its doing good because it is good and people started to notice once MS propriatery chains went down.
liveoneggs 6y ago
yeah perl with qx/cmd/ calls and similar is just really really good for "shell scripting".
nixpulvis 6y ago
Exactly! This is why I started my shell. Eventually it will have the ability to run both POSIX and other shell languages in the same program. Assuming everything is a table is overly restrictive. Assuming everything is text is the UNIX way. It's then the job of the terminal to render it.
joe_the_user 6y ago
Because I have better programming languages which, despite being able to interact with the system and its commands, don't pretend to be one with the system. As a result, the core high-level language constructs mesh better, because they're not trying to serve two goals at once. The power and usefulness of a given language is often the ability to serve multiple goals at once. Python as tool is cool specifically because of a large-ish but accessible-ish library covering a everything from regex-ex to a web-server. This project might not serve the goal of writing high level programs and interacting effortless with the command line/system. But I don't one should automatically dismiss the goal of making stuff-glued-together look like a coherent whole.
IshKebab 6y ago
You are forgetting about how shell scripts start. "I don't want to keep writing these 5 shell commands, I'll put them in a file. Ok that is useful, I'll add some parameters. This shell script works great, I'll add more functionality." And before you know it you have a buggy monster written in a batshit insane language that nobody is going to want to touch. If your shell is at least vaguely sane, the situation is a lot better. I don't really get why you would argue against something that fixes the many many many mistakes of Bash.
- lolc 6y ago
  To a first approximation, people who are ok with Bash as a scripting language do not know enough Bash to safely use it as a scripting language. I see many insane constructs that accidentally work. I also know how much time it would take to explain expansion rules. And people don't even want to hear it because it shakes their simplistic (and inconsistent) understanding. So yes, I hope we'll see something like crush replacing Bash. But I don't see how it will happen.
r-w 6y ago
It's my understanding that commands don't have to be specially written for Crush. As long as they speak an understandable format, they can be used. https://github.com/liljencrantz/crush#reading-and-writing-files https://github.com/liljencrantz/crush#reading-and-writing-fi...
hestefisk 6y ago
I don’t think nushell or crush for that matter copy PowerShell. They have learnt from MS and built upon what they didn’t get right. Strongly typed objects on the command line is theoretically interesting, but slow and complex in practice (why does it still take 3-4 seconds to run ls / gci in my homedir at home?). Text in columns gives you the simplicity of text coupled with some level of structure.
- pjmlp 6y ago
  They haven't learned everything, because the other part is integration with all sorts of native libraries and IPC.
- majkinetor 6y ago
  3 to 4 s to run ls? U should fix ur computer rather then spreading FUD. Also its clearly stated that copy of pwsh is intention on both projects. Nushell is still one man show just like crush so they need decade or so to get to pwsh level. Its nice to make stuff and offer alternatives but lets keep perspective here.
  - hestefisk 6y ago
    Column orientation is very different to object orientation. My computer runs just fine. Do you really think pwsh is fast?
    - majkinetor 6y ago
      No. Its acceeptable, and mostly startup related. Certainly not even close to the level u claim. Once started it is more or less OK depending on specific cmdlet and task in question. I use it in production on numerious gov level services serving millions. Vim is slower for example but rarelly anybody compalain about it given its power.

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.
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.

pritambarhate 6y ago

Not many young people know Perl or Tcl (or even lisp for that matter). >> The point of shell is that it interoperates freely with all programs and all programs share a language. Also doesn't mean people should stop trying to come up with these new shells. May be some "new" shell will catch up and tomorrow's "all" programs will be compatible with that shell. For example, now on Mac OS X, now ZSH is the default shell.

moonchild 6y ago
I explicitly included zsh. The point is not the language of the shell itself; that has never been the point. The point is that zsh interoperates with the other programs on your system in a way that crush doesn't and can't.
- viraptor 6y ago
  > a way that crush doesn't and can't What do you mean by can't? If it misses some mode of interaction, that can be always added.
  - ori_b 6y ago
    Consistent behavior when piping through all commands. A lack of modes of operation to consider. Simplicity.
    - viraptor 6y ago
      Simplicity exists on more than a single dimension. Choosing one column from "ls" output for example is not simple, bordering on impossible using the consistent behaviour of standard pipes. Sometimes the inconsistent solution will be simpler by moving the complexity to the choice of the mode of interaction. Sometimes not.
      - ori_b 6y ago
        Maybe a shell is the wrong tool for that job, and hiding the modes that the language is operating in complicates things.

hhas01 6y ago

“somewhat miss the point of the shell in the first place” This presupposes that the Unix shell is the way it is because of careful, considered, forward-thinking design, rather than being a haphazard heap of mouldering hacks upon lazy corner-cutting upon quick-n-dirty bodges that should’ve been thrown out and replaced decades ago. I agree that trying to improve the *nix shell is a bad idea… because the _Unix shell itself_ is a bad idea. Fifty years is long enough. Instead of bending over backwards for that obsolescent garbage heap (for which no-one will thank you, as we see), study it, learn its lessons, and draw a line under it. Then go build a clean, modern shell architecture from scratch, using modern tooling and techniques, unhobbled by the myriad defects and deficiencies of the old. It’ll take a tenth of the time and be ten times better (if not, you’re still doing it wrong). See also: https://www.google.com/search?q=sunk+cost+fallacy https://www.google.com/search?q=sunk+cost+fallacy https://homes.cs.washington.edu/~weise/uhh-download.html https://homes.cs.washington.edu/~weise/uhh-download.html -- p.s. As for driving early adoption, don’t even think of trying to win over the Unix old guard (who will only bring regressive practices and complaints with them), but sell it hard to the new generations of users who are accustomed to modern UI/UX standards and much less impressed by what the “Old Unix” dogpile has to offer.

jodrellblank 6y ago

> “because the system itself was designed around the shell.” Windows wasn’t designed around the command prompt, it wasn’t designed around shell utilities. When I call “cat”, it’s not important that I’m writing those three letters, they are a library way of calling a set of file open/read OS functions. When I write “ping”, it’s not the ping tool I care about, it’s the network api calls it does behind the scenes. The Unix/Linux shell is then seen like a “Python standard library” of ways the user can control the OS, and it’s a hugely inconsistent, undesigned, ad-hoc agglomeration of names and parameters and bodges, which cheats out on dealing with the complexity and instead offloads that straight on to the user in a user hostile way. What powershell tries to do for Windows is make a somewhat designed, consistent, and more user-approachable set of wrappers around the Windows OS system calls, along with guidelines and support for vendors to build in that style, a human interface that is introspectable, built to be programmable, but still composable and modular. The objection that trying to do such a user-focused thing on Unix makes a “useless” system is weird because that - a user interface to tools/library of OS call patterns - is what the shell is. In what way is “resolve-dnsname” pretending to be one with the system that dig and nslookup aren’t? They’re names which trigger a pattern of network traffic and show a result. In what way is piping text from dig to sed “real” and piping resolve-dnsname to format-list “pretend”? In what way is running “docker compose” from sh real, but running it from zsh is pretend? In what way is it a better design to have (a pile of shell tools and Python library wrappers and Python wrapping shell tool calls), instead of (a Python based shell with transparent shell tool calls)? Like, “I want what I’m familiar with, too many things to relearn”, or “too many things are awkward in this approach (cough PowerShell)” are reasonable objections, but “trying for a more consistent, more human friendly, interface with more high level language constructs at one’s fingertips makes a thing useless to me” feels heel dragging or Stockholm syndromeish. Presumably you don’t object to there being a choice of multiple command line tools to do a task? Why object on principle to a choice of other OS “front end experiences”? Is there any version of things which you can imagine as being both “better” (less arbitrary and inconsistent than shell) and “not pretend”? > “The point of shell is that it interoperates freely with all programs and all programs share a language.” What language? Some treat piped bytes as bytes (e.g. piping a binary file), others as ASCII, others as UTF-8. All support different parameter options, names and values and ways of specifying them. Many handle output formatting in different ways, many trigger internal states from environment variables. If the point is a common shared language, the point doesn’t seem to have been achieved from a user perspective. And if the point is that “I have to suffer a system that’s tied to a shared language with an AIX box in a bank basement last touched by a human in 1997” the point is a bad one. I use my computer a lot more than I use AIX and I have more computing power to spare on human comforts and conveniences.

moonchild 6y ago

To clarify, I am not saying that everything except for bare /bin/sh without line-editing is Wrong. I wasn't clear enough here. I think that bourne shell, bash, fish, zsh, and csh are all able to interact with the unix system in a way that crush, nushell, and other powershell-alikes cannot.

throwaway894345 6y ago
Can you elaborate on that more of interaction? What can bash, etc do that crush, etc can’t. Is this limitation inherent or easily amended?
liljencrantz 6y ago
I am the original author of both fish and Crush, and I honestly don't know in what way fish interacts with the OS in a way that Crush by virtue of it's design never could. I know that Crush currently doesn't interact very well with external commands, but I don't see where that is an inherent restriction in the design rather than a missing feature.

kevincox 6y ago

This seems to strike a good compromise as "third party" commands are "lines" type which is basically what we are used to send and receive in unix tools. Of course a lot of tools already support emitting JSON so it seems the Crush is already more useful than the typical unix shell as you can still use "lines" for every program (and convert to a table by parsing if you want to use the more advanced features) and there are already a number of third-party programs that you take directly take advantage of these feature with even though they didn't know anything about this shell. I think the fact that you can already use this with most programs and it is never less powerful than bash seems like good indication that the system doesn't need to be reworked around this shell. It fits in cleanly to existing paradigms.

shawxe 6y ago

You really aren't kidding about Tcl. I recently discovered that with tclreadline, Tcl can be used completely in place of Bash in interactive mode, in a way that something like Python absolutely cannot. A lot of people seem to have negative opinions about Tcl (maybe because it's more of a LISP than its syntax seems to imply), but as someone who is just discovering it, I'm shocked at how powerful it is for how unpopular it seems to have become. It's like some kind of unexpected cross between Bash, LISP, and (with Tk) Visual Basic. There's something about it that's just kind of fun.

hodgesrm 6y ago
Tcl is awesome. I used it constantly in the 1990s. It's outstanding for things like testing and build scripts. I think some of the pushback might be because people tried to use it to build large applications and failed. Languages like Java and (dare I say it) Visual Basic were more comprehensive and had good IDE support.
mr_toad 6y ago
Tcl has features that are very powerful, but are really hard for a beginner, and really easy for a novice programmer to shoot themselves in the foot with. Yet Tcl tends to be forced on undergraduate programmers, who probably just learn to loathe it. I lost several toes to it myself decades ago, and haven’t really felt inclined to pick it up again.

chubot 6y ago

Right, I'm often asked this about Oil [1]: Why do you want to write programs in shell? That's not the idea of shell. The idea is that I write programs in Python, JavaScript, R, and C++ regularly, and about 10 different DSLs (SQL, HTML, etc.) And I work on systems written by others, consisting of even more languages. I need a language to glue them together. A language to express build automation and describe deployed systems. Most big systems consist of more than one language. Shell is the best language for that, but it's also old and crufty, with poor implementations. When you program in shell, gcc, git, pip, npm, markdown, rsync, diff, perf, strace, etc. are part of your "standard library". [1] http://www.oilshell.org/ http://www.oilshell.org/

chubot 6y ago
Update: also see the philosophy for structured data in Oil below: https://news.ycombinator.com/item?id=24083931 https://news.ycombinator.com/item?id=24083931

hodgesrm 6y ago

New shells seem unlikely to catch fire unless they: * Preserve compatibility with popular shells like bash. * Address some of the broken parts in a way that makes the world better. Quote handling is the original sin of *nix shells. If somebody fixed that you would have my full attention. Otherwise I can just stick with Bash + Python3.

hannasanarion 6y ago
Which is impossible, which is why no new shells have caught fire. In order to preserve compatibility, you must handle quotes, namespaces, etc in the same way as Bourne-derived shells, because they will be expected to run scripts that use nested interpolation, or string declarations without quotes, or whatever. Shells that use a more robust syntax, like Fish or Powershell, can't ever be compatible.
- majkinetor 6y ago
  Not exactly true since PowerShell is doing quite good regarding popularity nowdays...
  - mdaniel 6y ago
    From my perspective, that's partially because CMD is so stunningly incapable as what a reasonable person might think of as a shell. I'd guess the other half is the amount of pressure Microsoft has placed upon management tooling using PS If Apple shipped some Swift-powered shell and all of their management documentation started using it, I'd bet a non-trivial portion of administrators would start to use AppleSwiftShell (although I do deeply appreciate that's a severely flawed comparison since macOS already has a sane functioning shell, but it's the best I could think of as a huge company that owns the platform pushing such a concept down)
    - majkinetor 6y ago
      I doubt. Most people still use cmd because they dont care. Its doing good because it is good and people started to notice once MS propriatery chains went down.

liveoneggs 6y ago

yeah perl with qx/cmd/ calls and similar is just really really good for "shell scripting".

nixpulvis 6y ago

Exactly! This is why I started my shell. Eventually it will have the ability to run both POSIX and other shell languages in the same program. Assuming everything is a table is overly restrictive. Assuming everything is text is the UNIX way. It's then the job of the terminal to render it.

joe_the_user 6y ago

Because I have better programming languages which, despite being able to interact with the system and its commands, don't pretend to be one with the system. As a result, the core high-level language constructs mesh better, because they're not trying to serve two goals at once. The power and usefulness of a given language is often the ability to serve multiple goals at once. Python as tool is cool specifically because of a large-ish but accessible-ish library covering a everything from regex-ex to a web-server. This project might not serve the goal of writing high level programs and interacting effortless with the command line/system. But I don't one should automatically dismiss the goal of making stuff-glued-together look like a coherent whole.

IshKebab 6y ago

You are forgetting about how shell scripts start. "I don't want to keep writing these 5 shell commands, I'll put them in a file. Ok that is useful, I'll add some parameters. This shell script works great, I'll add more functionality." And before you know it you have a buggy monster written in a batshit insane language that nobody is going to want to touch. If your shell is at least vaguely sane, the situation is a lot better. I don't really get why you would argue against something that fixes the many many many mistakes of Bash.

lolc 6y ago
To a first approximation, people who are ok with Bash as a scripting language do not know enough Bash to safely use it as a scripting language. I see many insane constructs that accidentally work. I also know how much time it would take to explain expansion rules. And people don't even want to hear it because it shakes their simplistic (and inconsistent) understanding. So yes, I hope we'll see something like crush replacing Bash. But I don't see how it will happen.

r-w 6y ago

It's my understanding that commands don't have to be specially written for Crush. As long as they speak an understandable format, they can be used. https://github.com/liljencrantz/crush#reading-and-writing-files https://github.com/liljencrantz/crush#reading-and-writing-fi...

hestefisk 6y ago

I don’t think nushell or crush for that matter copy PowerShell. They have learnt from MS and built upon what they didn’t get right. Strongly typed objects on the command line is theoretically interesting, but slow and complex in practice (why does it still take 3-4 seconds to run ls / gci in my homedir at home?). Text in columns gives you the simplicity of text coupled with some level of structure.

pjmlp 6y ago
They haven't learned everything, because the other part is integration with all sorts of native libraries and IPC.
majkinetor 6y ago
3 to 4 s to run ls? U should fix ur computer rather then spreading FUD. Also its clearly stated that copy of pwsh is intention on both projects. Nushell is still one man show just like crush so they need decade or so to get to pwsh level. Its nice to make stuff and offer alternatives but lets keep perspective here.
- hestefisk 6y ago
  Column orientation is very different to object orientation. My computer runs just fine. Do you really think pwsh is fast?
  - majkinetor 6y ago
    No. Its acceeptable, and mostly startup related. Certainly not even close to the level u claim. Once started it is more or less OK depending on specific cmdlet and task in question. I use it in production on numerious gov level services serving millions. Vim is slower for example but rarelly anybody compalain about it given its power.