11 ms·

The case for Nushell

105 points by lukastyrychtr 3y ago

fnordpiglet 3y ago
I’m a minor contributor to Nushell, it’s a great community working together and I really enjoy developing in rust on a shell. It’s much easier than the old c/c++ shells. It also has a native integration with polars (dataframe) that is very powerful.
zakariya_og 3y ago
isnt this a repost?
Barrin92 3y ago
>Nushell is trying to answer the question: "what if we asked more of our shells?" well apparently one thing you should not really ask is "can you activate a python virtual environment?". I tried out nushell for the first time a few months ago and that was the first thing I ran into which apparently is still causing issues after four years[1], which to me doesn't really inspire confidence that this is a practical tool for people who want to get regular dev work done [1] https://github.com/nushell/nushell/issues/852 https://github.com/nushell/nushell/issues/852
snicker7 3y ago
I usually just use the Julia REPL as my “shell” (my terminal emulator is configured to open it directly).
- sundarurfriend 3y ago
  Do you use something like Shelly [https://github.com/umlet/Shelly.jl https://github.com/umlet/Shelly.jl] ? Also, do you not often need to pipe one command into another? Afaik the Julia REPL's shell mode doesn't allow pipes, redirects, etc. Do you straight up do `run(pipeline(...` for those cases?
corasaurus-hex 3y ago
The single greatest thing someone could do to break the stranglehold of ancient shells is to make a language that compiles to both posix and their new shell syntax. Make it so people can write once and run on both old and new shells.
gsuuon 3y ago
I daily drive nushell - combined with wezterm it's great for a completely cross-platform setup. There are definitely usability and stability issues though, to the point where I wouldn't yet recommend it to anyone who isn't ready for some pain. I've had lost data issues from buggy 'mv' for example, basic things like '&&' or '||' not working, etc. I avoid ever updating because I need to spend an hour or so fixing scripts. But the trade-off is that you get really nice error messages and working with structured data can be a breath of fresh air. Once it hits 1.0 I think it'll be an easy choice over existing traditional shells. It does make me wonder though - at what point does it make more sense to just add some shell-like commands and functionality to a typed language's REPL? I played around with this idea using F# and FSI. The composition (|> instead of |) maps pretty directly and you get the benefit of types but in a more sane language (sorry nushell). You'd just need to add a 'cd' to mutate pwd state, pull in FAKE core and alias the most common shell operations.
- gsuuon 3y ago
  Apparently this is a thing in haskell already, so F# isn't too much of a stretch: https://hackage.haskell.org/package/turtle https://hackage.haskell.org/package/turtle
eviks 3y ago
> The truth is, in 2023 if someone asked us to design a system, we wouldn't design POSIX. If, in 2023, someone asked us to design a shell language, we wouldn't design bash/zsh. This matters. Indeed, clinging to the awful design choices of the past prolongs misery for all the future generations > [bash] Pros: it's everywhere. Learn once, run anywhere not on native Windows unlike, say, python-based shells like xonsh or even pwsh
natemcintosh 3y ago
I love using nushell, and I hope it becomes a standard going forward. I do sometimes feel slightly annoyed that I have to type out a bit more in nushell, as opposed to simply tacking on another flag, but I think JT makes a really great case for doing just that. In terms of adoption, JT asks: 1. Is Nushell compelling enough for a single person to adopt it? 2. Would adopting Nushell broadly as a community move the needle? I'm 100% on board with nushell in my personal computing. But I'm still worried about number 2. I think something like rust was able to succeed because enough people really felt like there a need for something to fill that space. Do enough people feel like nushell fills a necessary gap? I hope so.
svat 3y ago
This may be obvious, but what I realized recently, when I tried to switch to one of the “alternative” shells (xonsh, based on Python), is that the experience of using a shell is (at least) four (overlapping) experiences: 1. The basic interactive stuff at the command-line: typing commands, tab-completion, aborting a half-written command when you change your mind or remember something else to do first, cut-and-paste, …. 2. Basic scripting at the command-line: writing a loop, piping one command into another, defining a function (over multiple lines?), …. 3. Scripting for job control: getting the return value of a command, waiting for a command to finish, putting one in the background, sleep, … 4. Programming as in other languages: if/else statements, assigning to variables, what arrays look like, doing more complicated logic and processing, …. [There's some overlap, and note that (3) or (4) may happen either at the command-line itself or in a separate .sh (or whatever) file in a text editor.] I found that `xonsh` seemed to be focusing on making (4) better—basically replacing the `if … fi` and `case … esac` of Bash/Zsh with Python—but it turns out I care about it less, and I'm too used to (just) 20 years of (1) to miss it: when Alt-. doesn't insert the last part of the previous command, or I cut some line(s) with Ctrl-k and Alt-y doesn't maintain the kill ring to paste it back (so it's gone??), and half-a-dozen other issues like that, it was annoying enough for me to switch back in less than a day or two. I don't think of myself as an old/long-time user (when I started in 2003 I was a newbie), but I guess I am one by now: don't mess with standard readline conventions. And (3) is core to why someone would use shell scripts; if you need me to "import subprocess" or do anything nontrivial to pipe (for example), you've already lost me. My understanding is that fish has focused on (1) with good results, and the "ls | where size > 10kb" example here, or what Powershell is good at, is focusing on another (5) that I didn't write about (the commands themselves, the flags to them, parsing their output etc). Anyway, interesting post, I'll try out nushell. As the post doesn't seem to link to it: https://www.nushell.sh/ https://www.nushell.sh/ (install it, and then start it with `nu`, not `nushell`.)
- 1vuio0pswjnm7 3y ago
  FWIW, I like libedit's vi mode more than readline's.
- fiddlerwoaroof 3y ago
  The issue I have is I don’t really get the value of solving (5) at the shell level: anything doable with richer datatypes is doable with a version of coreutils and peripheral utilities with better serialization formats. And, I’d rather the shell’s piping be less intelligent in favor of offloading more intelligence where it’s easier for users to extend: external binaries on $PATH
nickelpro 3y ago
This makes a terrible case for Nushell as a shell. It makes a reasonable case for Nuhsell as a programming language. If I want a programming language I use a programming language. A shell is an interactive environment and only a programming language by way of the Turing-complete nature of its grammar. However, if I am stringing more than a couple commands together something has gone terribly wrong. The features I care about are features that make that interactivity better, not a type system.
- eecc 3y ago
  Uhm, so what about REPLs? Jupyter notebooks? Are they wrong? What if the typedness of the shell made the interaction better? Can you make an argument that this does not hold? The article does make a good argument in favor
  - nickelpro 3y ago
    REPLs and notebooks and all the rest are great. NuShell might be a great REPL, I don't know, don't really care. The fact no one uses a REPL as a shell, and there's no demand to add direct exec() to REPLs, demonstrate they're different categories. Let programming languages do what programming languages are good at. Let shells do what shells are good at. Please do not write programs in a shell. Do not create a half-assed programming language in a shell to encourage people to write programs in said shell.
    - Per_Bothner 3y ago
      Huh? Using a shell interactively is a REPL. REPL means Read-Eval-Print-Loop. That's what you do when you type commands to a bach/zsh/fish/nushell/... prompt. But it also how you type commands to a gnuplot or Mathematica or APL or Python or Lisp prompt. Some REPLs have nicer interactive features (such a completion than others). Some REPLs have nicer or more powerful syntax or different data types. But as longs as you have a Read-Eval-Print-Loop it's a REPL.
- Eji1700 3y ago
  The article admits basically exactly this, but also makes arguments as to why? ``` He proceeded to explain that if he could recreate many of the techniques we showed all as part of a C++ library that people could use. At this time, I wasn't sure how to respond other than "but you don't have to, we already built this language" but he couldn't be swayed. If it wasn't C++, he didn't want it. Fast forward a couple years, and I'm standing in front of a JavaScript audience giving a similar talk, this time promoting TypeScript. I remember the kind of politely confused looks on people's faces as I showed off the features TypeScript offered. There was a similar sense of "why do we need to leave JavaScript?". To answer whether Nushell can overcome this kind of inertia, I'll pose two questions: Is Nushell compelling enough for a single person to adopt it? Would adopting Nushell broadly as a community move the needle? Let's tackle the first question. Time and again, as people try Nushell, they come back with quotes like "this is the most excited I've been about tech in 15 years". It has a fanbase that loves it, and that fanbase is growing. It reminds me of the early days of Rust, just after hitting 1.0. To the second question: would adopting Nushell broadly actually improve things noticeably? Without a doubt. I say this without any reservation. Thinking of our shells as structured, interactive processing engines opens up the doors to a much wider array of things you can do with them. The commands would be far simpler than their POSIX equivalents and would compose far better. They'd benefit from the full knowledge of the data being shared between them. Adaptors could be made to connect to all parts of the system, allowing you full, structured interaction with everything you have access to. ``` I enjoy nushell, but I am far far far from the average user/target audience. I do not sys admin or anything like it, I mostly use it to quickly navigate the filesystem and, with nushell specifically, occasionally to work with data i've gotten from other things. I haven't gotten quite to the point I would write scripts in it yet, but at the point i'm considering throwing up an FSX file or going into a repl, I like that I might just be able to use nushell instead for the smaller tasks. Is this useful? To me, sure, to everyone else, hell if I know. edit- Article even touches on this mindset: > I don't need to do heavy data processing everyday, but it's nice to not have to shift what I'm doing at all when I need to do it. I don't have to download new utilities or switch languages. It's all right there. Need to write a script to load some files and handle some directory processing? Still right there. Need to throw together some web query that outputs the top download results for a github repo? You guessed it, all still right there.
LispSporks22 3y ago
I can’t live without job control
p-e-w 3y ago
> Recently, I had a chat with some of my friends about Nushell and why they stuck with traditional shells like bash/zsh or the "new" hotness like fish rather than using Nushell. Umm... because Nushell is pre-1.0, with major language changes every few weeks? Living on the bleeding edge isn't everyone's cup of tea, and certainly not with something as fundamental to the system as a shell. Rest assured I will switch the moment 1.0 is released and a stability promise is published. That being said, yeah – Nushell is the real deal. It's the Unix philosophy, except this time it actually works.
- imiric 3y ago
  > It's the Unix philosophy, except this time it actually works. How is Nushell compatible with the Unix philosophy? The core Unix philosophy is about enabling workflows that combine a set of independent tools in novel ways. Nushell implements a monolithic ecosystem with commands that support its fancy features, but using any external command not written for Nushell will be cumbersome at best, and incompatible at worst. This goes against the open philosophy of Unix, which is partly what has allowed it to grow and succeed.
  - ChrisSD 3y ago
    So long as a tool can output a machine readable format, it can be consumed by nushell. If it can't then... that's actually a big problem when composing tools in bash too. Parsing arbitrary unstructured text is not good for composition and requires making something bespoke for each and every tool. As well as each and every argument for each and every tool for those arguments that happen to change the output in different ways.
    - imiric 3y ago
      > Parsing arbitrary unstructured text is not good for composition and requires making something bespoke for each and every tool. Right, but therein lies the flexibility of using unstructured text as the exchange format. Each tool doesn't need to be aware of the format it needs to consume or output; it just cares about what makes sense for itself and the user. It's up to the user to determine the best way of composing each tool within a specific pipeline. This might seem cumbersome, but there are a limited set of ways tools can be composed, and generic helper tools exist for a variety of use cases (xargs, sed, awk, grep, cut, paste, etc.). If one tool breaks, then it's easy to either replace it, or fix the pipeline to support that specific tool. In contrast, by making a strict contract of the exchange format, each tool needs to support a specific contract, and any deviation or update of it means that all tools need to be updated as well, while also maintaining backwards compatibility. This might be fine for a monolithic environment where a single project maintains all tools, but it's unsustainable if one wants to build an open ecosystem of tools that work independently, but can still be composed in any pipeline.
guitarbill 3y ago
Maybe I'm not using my shell to the fullest, but 95% of commands are pretty simple, and not complicated queries. `ls` might have a bajillion flags, but `-lah` go a long way. Because fish's autocomplete, I don't have to remember tar flags. That's the killer feature for me. Along those lines, a quick way to drive adoption could be a huge "how do i do x" or recipes page to Ctrl+F through. If I have to search the internet for how to do x in nushell/fish/etc, I might as well stick to arcane bash - at least you know someone has had the same problem before. Make it easy for me to get stuff done by showing me how to get stuff done, and I'll grok the shell bit by bit. I did see https://www.nushell.sh/cookbook/ https://www.nushell.sh/cookbook/ , but it isn't really a searchable reference. There's some setup stuff, other short pages with basic tutorials (?), a link to a repo with example scripts, and for one-liners you are instructed to join a discord. None of these are easily searchable.
- gsuuon 3y ago
  There is a 'Coming to Nu' section of the nushell book which covers 'how do I do x' coming from other shells: https://www.nushell.sh/book/coming_from_bash.html https://www.nushell.sh/book/coming_from_bash.html
- westernpopular 3y ago
  > Along those lines, a quick way to drive adoption could be a huge "how do i do x" or recipes page to Ctrl+F through. If I have to search the internet for how to do x in nushell/fish/etc, I might as well stick to arcane bash - at least you know someone has had the same problem before. https://github.com/tldr-pages/tldr https://github.com/tldr-pages/tldr
- pxc 3y ago
  > If I have to search the internet for how to do x in nushell/fish/etc, I might as well stick to arcane bash - at least you know someone has had the same problem before. I feel the opposite way: if I don't really know Bash, I'm not throwing away a bunch of my hard-earned knowledge and experience to start again from zero by switching to Fish. It's just a lateral move, and an obvious win if the shell it takes me to is simpler, smaller, or otherwise easier to learn.
parasitid 3y ago
and there shall be Emacs Shell ;) https://www.gnu.org/software/emacs/manual/html_mono/eshell.html https://www.gnu.org/software/emacs/manual/html_mono/eshell.h...
mongol 3y ago
I tried it briefly and the fact that find means grep and so on will be a tough nut for me to crack, learning-wise. I understand that if you start from a clean slate, you want to make the experience internally consistent. But how do you as a user manage, when your muscle memory is used to something else?
- coldtea 3y ago
  >But how do you as a user manage, when your muscle memory is used to something else? Like with anything else new: if you find it worth it, you develop new muscle memory.
  - waynesonfire 3y ago
    Just don't see it. I'd need at least 10x improvement to switch and that means fundamental changes to interacting with processes as I'm petty surgical with bash, find, awk, sed. A shell isn't 10x by being a union of all the best tools, it needs to redefine them. And 'where' doesn't come close.
imiric 3y ago
Nushell is definitely interesting, and I'm glad it exists, but I'm not using it because of at least a couple of major reasons: - It reimplements all commands. You're not actually using GNU coreutils, but Nushell reimplementations of ls, rm, etc. See [1]. I understand why it's done, but this has many drawbacks: 1. All existing shell examples and documentation spanning decades are useless. Nushell commands try to replicate existing UIs, but they invariably must be incompatible to support all features and deprecate unnecessary ones, so the only valid source of documentation is Nushell itself. 2. Nushell-specific bugs[2,3]. This goes without saying, and will improve as the project matures, but experiencing bugs with core commands is jarring. I've never had that with GNU tools. 3. Unsupported commands won't have any of the benefits, and you'd still have to parse their output in the traditional way, or use a Nushell helper. How often this happens will depend on your use case, but you'll always depend on Nushell for integrating that command in your workflow. - Related to point 3, Nushell is building an entirely separate monolithic ecosystem, which goes against the open ideology of Unix. This is similar to BusyBox, where you always have to be aware you're not using GNU tools, but some slightly incompatible equivalents. More importantly, this approach doesn't scale. There will always be new commands that target POSIX shells, but not many commands will be written specifically for Nushell. I appreciate what projects like Nushell and Murex are trying to address, but having a saner scripting language and passing structured data in pipelines is not worth the drawbacks for me. For one, Bash scripting is not so bad if you set some sane defaults and use ShellCheck. Sure, it has its quirks, but all languages do. Even so, the same golden rule applies: use a "real" programming language if your problem exceeds a certain level of complexity. This is relative and will depend on your discomfort threshold, but using the right tool for the job is always a good practice. No matter how good the shell language is, I would hesitate to write and maintain a complex project in it. And for general QoL improvements with interactive use, Zsh is a fine shell, while still being POSIX compatible. [1]: https://github.com/nushell/nushell/blob/main/crates/nu-command/src/filesystem/ https://github.com/nushell/nushell/blob/main/crates/nu-comma... [2]: https://github.com/nushell/nushell/issues/5027 https://github.com/nushell/nushell/issues/5027 [3]: https://github.com/nushell/nushell/issues/9310 https://github.com/nushell/nushell/issues/9310
- hnlmorg 3y ago
  > I appreciate what projects like Nushell and Murex are trying to address, but having a saner scripting language and passing structured data in pipelines is not worth the drawbacks for me. Murex doesn’t change any of coreutils. With murex can use the command line as dumb byte streams with the standard GNU / BSD utils if you want…and in fact I do just this myself. What Murex offers is an abstraction on top that allows you to add type hints to those byte streams so you can do fancier stuff with it if you wanted. Think of it like what Typescript does for JavaScript. You have access to all the same POSIX utilities and additional type aware controls on top but it’s completely optional if you want to use those type aware controls (personally, I think once you do, you wouldn’t go back, but I respect people’s personal preferences).
hresvelgr 3y ago
The case for Nushell is weak because shells are not an ideal environment, but rather a lowest common denominator by today's standards that has stuck and hasn't disappeared. What we need is a better interactive environment interface. It baffles me that something like Pharo's interactive environment hasn't been copied all over the place. I understand it's largely because it's a self contained environment that it is able to afford the functionality it has, but there are lessons in there worth learning from.
- coldtea 3y ago
  >The case for Nushell is weak because shells are not an ideal environment Not sure what "an ideal environment" even means, but shells have tons of very nice features. The problem is they also have a lot of legacy bs and tons of footguns.
  - hresvelgr 3y ago
    > Not sure what "an ideal environment" even means, but shells have tons of very nice features. If you haven't, I would encourage you to try Pharo. It's a Smalltalk dialect but you program through what feels like an operating system. The richness in interactivity and feedback is unparalleled. This is what I would consider an "ideal environment." Shells are useful tools, they wouldn't have the ubiquity they do if that weren't true. That being said, there's definitely more interesting and powerful paradigms out there for interacting with an operating system at a lower level.
    - theamk 3y ago
      My years doing hardware development and driver programming in college taught me about the evils and endless frustration of invisible, un-resettable state. "Why did my driver worked the first time but exactly same code fails now? Which of hundreds of hardware registers did I forget to reset _this time_?" Same thoughts appear when I look at Smalltalks... Ok, I can edit any function or variable, including a system one; and the changes would be saved automatically in opaque persistent "image". So if you mess a system function, your whole system is unusable and you have restore from snapshot; and even something as simple as a program which continuously pops up message boxes can make system unusable (and again, require restoring from snapshots). It's like Windows 98 but with no reboot option!
hnlmorg 3y ago
This post implies the decision is between nushell, MS Powershell or something based on shells from the 70s. But there are a plethora of other shells like nushell, that have been around for longer than nushell. It’s actually a pretty crowded market space. So why are people still using bash? In part because it’s a default (defaults are hard to change) and in part because it’s largely “good enough”. It’s the same reason JavaScript is everywhere. First because it was the default in browsers and then because it was good enough that people didn’t want the effort of having to learn nor use another language.
- dubcanada 3y ago
  Like what? I’d love a stable nushell alternative.
  - hnlmorg 3y ago
    Stable is a problem because a lot of these shells don’t offer any guarantees for breaking changes. My own shell, https://github.com/lmorg/murex https://github.com/lmorg/murex is committed to backwards compatibility but even here, there are occasional changes made that might break backwards compatibility. Though I do push back on such changes as much as possible, to the extent that most of my scripts from 5 years ago still run unmodified. In fact I’ve started using some of those older scripts as part of the automated test suits to check against accidental breaking changes.
  - geophile 3y ago
    Check out my entry, marcel: https://marceltheshell.org https://marceltheshell.org. E.g., find the newest vlc instance and kill it (a command that an acquaintance needs frequently, for some reason): ps | select (p: p.name == 'vlc') | sort (p: p.create_time) | tail 1 | (p: p.signal(9)) - ps produces a stream of Process objects. - select binds each Process to p, and then selects those whose name is vlc. (Anything in parens is a Python function. You can include or omit "lambda".) - sort by create time, (using a Python function to specify the sort criterion). - tail 1 as in Linux, to get the newest qualifying Process. - Run the function p.signal(9), which kills the Process.
jakobnissen 3y ago
Nushell is a great improvement in terms of shell design, and it really does feel like a modern, better equivalent of the shell. However, I tried using it twice as my main shell and had to give up both times. The first time, I experienced a handful of bugs. The most annoying one was that I couldn't copy-paste passwords into the shell because Nu kept inserting control characters. Then I kept having trouble with other programs that rely on the shell - for example, "conda init" does not work with nushell, nor does Julia's shell work with nu. So practically speaking, I had to continually boot up zsh inside Nu. Then, there are the constant breaking changes. It feels like every month there is some breaking change, and every few months I need to dig into my nushell setup scripts to unbreak half my shell tools because some syntax changed. Yeah, no thanks. Hopefully someone else will do the annoying work of test running Nu for 5 more years until it's stable and integrates well, but for me, I went back to zsh.
- sundarurfriend 3y ago
  Do you remember what issues you had with Julia's shell mode when using nu? A (very) cursory look at the Julia code doesn't reveal any obvious problems, but there's probably some hidden assumptions (possibly around POSIXness) that's causing troubles.
fergie 3y ago
Nushell is part of the ongoing Visual Studio-ification of software engineering. TypeScript and Powershell are preferences, not standards. If you want to use them, great, but its wrong to say that these have evolved into defacto ways of doing things. Also- that everything is text in Bash is one of its great strengths, just as Powershell's reliance on Objects was generally understood to be a weakness. Also- I don't get the need for IDE support? Surely the point of a shell language is that it is designed to be used for a terminal? As others have said here- this feels like a better case for nushell as a scripting language than nushell as a shell.
- pm90 3y ago
  IDE support is required if you’re building up complex scripts/custom functions.
- pindab0ter 3y ago
  Could you expand on the "Visual Studio-ification" of software engineering, and why that would be a bad thing?
  - fergie 3y ago
    "Visual Studio-ification": Any technology that requires Visual Studio to be productive. The classic example would be TypeScript, but you can clearly see nushell's overtures to VS in the linked article. A de facto requirement on VS to make a webpage is bad enough, a de facto requirement on VS to write a shell script is even worse.
    - fortunateregard 3y ago
      Hover/go-to-definition seems more like a nice-to-have than a requirement. Either way, neovim support can be found here: https://github.com/LhKipp/nvim-nu https://github.com/LhKipp/nvim-nu
    - DangitBobby 3y ago
      It has nice error messages so you definitely don't need an IDE to edit scripts.
meeho 3y ago
> Nushell is designed to be a language Last time I checked it didn't have functions. Has that changed?
- milliams 3y ago
  It does, see https://www.nushell.sh/book/custom_commands.html https://www.nushell.sh/book/custom_commands.html def greet [name] { $"hello ($name)" } They were added in 0.25 in January 2021 (https://www.nushell.sh/blog/2021-01-05-nushell_0_25.html#custom-commands https://www.nushell.sh/blog/2021-01-05-nushell_0_25.html#cus...)
extr 3y ago
Maybe a hot take but copilot CLI has obviated the need for this kind of thing for me personally. Most of my shell commands are incredibly simple, and now with copilot CLI, I have a 80% head start on anything more complex. In fact sometimes I will just type "!! <sloppy command>" and it will autocorrect to basically what I was going for without any further prompting.
xigoi 3y ago
Am I the only one who uses a shell primarily as an interactive interface, not as a programming language? Why do all shells seem to focus on the latter aspect?
- hnlmorg 3y ago
  They don’t. Murex (my shell, https://GitHub.com/lmorg/murex https://GitHub.com/lmorg/murex ) is all about the interactive environment. Elvish is too.
- IshKebab 3y ago
  Because the biggest problems with shells are when people think "these commands work for me; I'll just save them in a file".
- mongol 3y ago
  There is an overlap. I often write for-loops in bash interactively for example. The ideal shell works well for both, but bridging this gap is a challenge.
maleldil 3y ago
Nushell is interesting. I tried using it as a scripting language (fish is better for interactive usage[1]), but I didn't get very far because it's constantly evolving and scripts that work today might not work next week. I can't commit scripts to a codebase if future users can't run them. So I end up using fish for scripting too. [1] Not only does fish have the best out of the box experience (although that's reproducible with plugins in other shells), it's also old and common enough that tools usually support it alongside bash and zsh. Nushell is too niche and always changing for tools to support it properly.
- em-bee 3y ago
  >fish is also old and common enough that tools usually support it for many years, more than a decade at least, this was not the case. it was a long and hard road for early fish users to get to that point. and i'd make the claim that todays openness towards alternative shells that break compatibility with traditional syntax is in large part thanks to the groundwork done by fish. that is to say that if nushell can present a compelling argument with its improvements, then there is hope yet. but for that to happen focus needs to be on interactive usage that is at least as good or better than fish and not just focus on better scripting. there is a place for better scripting. gluing together multiple tools where input, output and arguments to commands matter is something normal programming languages don't do well.
  - maleldil 3y ago
    I agree with you overall. Still, the reality today is that Nushell has a long way to go in terms of support. I think it's hard for Nushell to do something for interactive usage that would displace fish for me, but I'm always open to exploration. The thing that resonates the most with me is the need for a better scripting language. A "proper" language, that worries about types, not just stringly typing everything. I think Nushell is making good progress on that, and the main reason I don't use it today is because it moves and breaks too fast for my taste.
fiedzia 3y ago
The case for any other shell: ls -R and find exist and work. Nushell doesn't cover that. I like the idea, but execution has so glaring holes that I had to go back to fish 1 min after installing nu. (there is glob ** that doesn't have any column and I don't see a way to compose it with ls, and ls ** doesn't work).
tux3 3y ago
My main criticism of nushell is that it seems to be more developed as a programming language than as a shell. Looking at the bug tracker, someone asked 4 years ago how to separate multiple commands, as in `git pull; git push`. It turns out, this is hard with nushell. At some point a ; syntax was added in nushell, but it is NOT the separator you expect. It's actually a strange cross between bash && and ; `echo a | grep b; echo ok` does NOT run the second command, so here nushell ; is like bash && `false; echo ok` DOES runs the second command, so here nushell ; is a plain ; There is no exact && equivalent. There is no || equivalent syntax at all. And the closest form of a plain bash ; I could find is |1; (piping into a constant value, which guarantees a 0 return code, so that ; will never fail)
- em-bee 3y ago
  which programming language doesn't allow multiple statements on one line? ok, there may be a few that strictly require linebreaks to start a new statement and lisp where everything is one huge statement with nested expressions. but not supporting this in a shell looks like a deal breaker. the primary function of a shell is to execute a sequence of commands.
EdiX 3y ago
I think nushell makes a pretty good case against itself. Take ls: like the article says gnu ls has tons of options to configure how its output is displayed. But that's because ls is a user interface for displaying lists of files. I'm not sure how the proponents of all these new shell keep missing this point. If you just want a list of files in a POSIX shell you use a glob expression. But whatever, nushell has its own builtin ls that is for getting lists of files. And then you pipe it into other commands to configure the output. Great. Can I get the output to be like 'ls -C'? Nope. Can I turn off colors? No. Can I add the indicator character like 'ls -F'? Not a chance. Well, at least I don't have to pass '-l' just to see the file mode... actually I do, otherwise it would be too slow. Many of the options that clutter gnu ls are generic options that apply to all tables, and it would be nice to abstract them. But many aren't, many are specific to what ls is doing and it's hard to me to see how this all could be generalized in a way that applies both to ls and to grep. For now nushell sidesteps the problem by not having its own reimplementation of grep, unlike ls if you type grep you get real grep and you can't pipe the output into anything meaningful. The best I could do to replicate grep inside nushell was this: cat haystack | split row -r '\n' | enumerate | where item =~ needle asides from the shocking verbosity, I can't see any way to replicate the --color option of grep, or -A and -B. The cop-out solution to this is to have builtins return objects (as in OOP objects, with methods), but then everything needs to be written in the same language.
- ripley12 3y ago
  If you want to use grep in Nushell, you can use grep and pipe the output to `lines` to split the raw output by line.
- dwattttt 3y ago
  > If you just want a list of files in a POSIX shell you use a glob expression. I think this sums up the problem. If you want a list of files for display you use ls, and if you want it for other purposes use a glob; it seems much more elegant to have one way of getting files, and a separate way to format it for displaying if that's what you want.
  - theamk 3y ago
follower 3y ago
Today I learned (after disappearing down a rabbit hole after reading the linked article) that it's actually possible to begin to use & benefit from nushell's structured data pipe feature without changing one's current shell. Structured data pipes have always been my primary reason for keeping an eye on nushell's development but after looking at the project's documentation again today it all still seemed "too much initial effort with uncertain outcome". Because I don't want to switch my shell (not because bash is good but because it's not a priority to justify the expenditure of effort), I just want to have structured data in pipes within bash! Turns out it's as easy as: nu --commands 'ls | where size > 1MiB' (Where `nu` is the nushell binary being called from your existing shell prompt.) Or, as more complete flow of data example: echo "[1,2,3]" | nu --stdin --commands 'from json | to json' | cat Now you can fit nushell within your existing workflow where ever it's useful enough for you--without needing to commit to changing your entire shell. (And this isn't the only or necessarily the best way to arrange things for the communication with bash--there's "^" & "externals" & "command signatures" & "from ssv" etc too.) And nushell does have some nifty tools such as `explore` with `:try` to interactively build a processing pipeline. But this information doesn't seem to be documented anywhere in the "book" or other introductory material. It only seems to be documented in the help message of the `nu` binary--which I almost didn't even get as far downloading today. But then I found the help text in the source, so decided to try it again: https://github.com/nushell/nushell/blob/fd4ba0443d01e67f6304b7220ef414a33287bdbe/src/command.rs#L248 https://github.com/nushell/nushell/blob/fd4ba0443d01e67f6304... If the structured data pipes is one of the main appeals for you, maybe try this approach out?
- lelanthran 3y ago
  > Turns out it's as easy as: They should have lead with that. I ignored nushell only because of the limitations of using a non bash shell with no sequence of commands using ;, && and ||.
- ramblerman 3y ago
  Nice, that's a great way to begin using it and testing the waters.
- follower 3y ago
sunshine-o 3y ago
I guess we all appreciate the traditional Unix shell as an incredibly stable tool over the last 50 years (!). But let's face it, it's hard to justify that a kid born in this millennia should learn & use this antiquated & obscure software. My fear is I suspect the success of those YAML based Ansible or Github Actions tools is the result of people being afraid or tired of writing shell scripts. But let's face it those are abominations because it lock you in a platform and you end up drowning in way too many YAML files. So yes I believe we need an ambitious update to the Unix shell and the Nushell team did a pretty good job. If we don't we will have to deal with many of those "automation" platforms & their poor configuration "languages".

105 points by lukastyrychtr 3y ago

I’m a minor contributor to Nushell, it’s a great community working together and I really enjoy developing in rust on a shell. It’s much easier than the old c/c++ shells. It also has a native integration with polars (dataframe) that is very powerful.

zakariya_og 3y ago

isnt this a repost?

Barrin92 3y ago

>Nushell is trying to answer the question: "what if we asked more of our shells?" well apparently one thing you should not really ask is "can you activate a python virtual environment?". I tried out nushell for the first time a few months ago and that was the first thing I ran into which apparently is still causing issues after four years[1], which to me doesn't really inspire confidence that this is a practical tool for people who want to get regular dev work done [1] https://github.com/nushell/nushell/issues/852 https://github.com/nushell/nushell/issues/852

snicker7 3y ago

I usually just use the Julia REPL as my “shell” (my terminal emulator is configured to open it directly).

sundarurfriend 3y ago
Do you use something like Shelly [https://github.com/umlet/Shelly.jl https://github.com/umlet/Shelly.jl] ? Also, do you not often need to pipe one command into another? Afaik the Julia REPL's shell mode doesn't allow pipes, redirects, etc. Do you straight up do `run(pipeline(...` for those cases?

corasaurus-hex 3y ago

The single greatest thing someone could do to break the stranglehold of ancient shells is to make a language that compiles to both posix and their new shell syntax. Make it so people can write once and run on both old and new shells.

gsuuon 3y ago

I daily drive nushell - combined with wezterm it's great for a completely cross-platform setup. There are definitely usability and stability issues though, to the point where I wouldn't yet recommend it to anyone who isn't ready for some pain. I've had lost data issues from buggy 'mv' for example, basic things like '&&' or '||' not working, etc. I avoid ever updating because I need to spend an hour or so fixing scripts. But the trade-off is that you get really nice error messages and working with structured data can be a breath of fresh air. Once it hits 1.0 I think it'll be an easy choice over existing traditional shells. It does make me wonder though - at what point does it make more sense to just add some shell-like commands and functionality to a typed language's REPL? I played around with this idea using F# and FSI. The composition (|> instead of |) maps pretty directly and you get the benefit of types but in a more sane language (sorry nushell). You'd just need to add a 'cd' to mutate pwd state, pull in FAKE core and alias the most common shell operations.

gsuuon 3y ago
Apparently this is a thing in haskell already, so F# isn't too much of a stretch: https://hackage.haskell.org/package/turtle https://hackage.haskell.org/package/turtle

eviks 3y ago

> The truth is, in 2023 if someone asked us to design a system, we wouldn't design POSIX. If, in 2023, someone asked us to design a shell language, we wouldn't design bash/zsh. This matters. Indeed, clinging to the awful design choices of the past prolongs misery for all the future generations > [bash] Pros: it's everywhere. Learn once, run anywhere not on native Windows unlike, say, python-based shells like xonsh or even pwsh

natemcintosh 3y ago

I love using nushell, and I hope it becomes a standard going forward. I do sometimes feel slightly annoyed that I have to type out a bit more in nushell, as opposed to simply tacking on another flag, but I think JT makes a really great case for doing just that. In terms of adoption, JT asks: 1. Is Nushell compelling enough for a single person to adopt it? 2. Would adopting Nushell broadly as a community move the needle? I'm 100% on board with nushell in my personal computing. But I'm still worried about number 2. I think something like rust was able to succeed because enough people really felt like there a need for something to fill that space. Do enough people feel like nushell fills a necessary gap? I hope so.

svat 3y ago

This may be obvious, but what I realized recently, when I tried to switch to one of the “alternative” shells (xonsh, based on Python), is that the experience of using a shell is (at least) four (overlapping) experiences: 1. The basic interactive stuff at the command-line: typing commands, tab-completion, aborting a half-written command when you change your mind or remember something else to do first, cut-and-paste, …. 2. Basic scripting at the command-line: writing a loop, piping one command into another, defining a function (over multiple lines?), …. 3. Scripting for job control: getting the return value of a command, waiting for a command to finish, putting one in the background, sleep, … 4. Programming as in other languages: if/else statements, assigning to variables, what arrays look like, doing more complicated logic and processing, …. [There's some overlap, and note that (3) or (4) may happen either at the command-line itself or in a separate .sh (or whatever) file in a text editor.] I found that `xonsh` seemed to be focusing on making (4) better—basically replacing the `if … fi` and `case … esac` of Bash/Zsh with Python—but it turns out I care about it less, and I'm too used to (just) 20 years of (1) to miss it: when Alt-. doesn't insert the last part of the previous command, or I cut some line(s) with Ctrl-k and Alt-y doesn't maintain the kill ring to paste it back (so it's gone??), and half-a-dozen other issues like that, it was annoying enough for me to switch back in less than a day or two. I don't think of myself as an old/long-time user (when I started in 2003 I was a newbie), but I guess I am one by now: don't mess with standard readline conventions. And (3) is core to why someone would use shell scripts; if you need me to "import subprocess" or do anything nontrivial to pipe (for example), you've already lost me. My understanding is that fish has focused on (1) with good results, and the "ls | where size > 10kb" example here, or what Powershell is good at, is focusing on another (5) that I didn't write about (the commands themselves, the flags to them, parsing their output etc). Anyway, interesting post, I'll try out nushell. As the post doesn't seem to link to it: https://www.nushell.sh/ https://www.nushell.sh/ (install it, and then start it with `nu`, not `nushell`.)

1vuio0pswjnm7 3y ago
FWIW, I like libedit's vi mode more than readline's.
fiddlerwoaroof 3y ago
The issue I have is I don’t really get the value of solving (5) at the shell level: anything doable with richer datatypes is doable with a version of coreutils and peripheral utilities with better serialization formats. And, I’d rather the shell’s piping be less intelligent in favor of offloading more intelligence where it’s easier for users to extend: external binaries on $PATH

nickelpro 3y ago

This makes a terrible case for Nushell as a shell. It makes a reasonable case for Nuhsell as a programming language. If I want a programming language I use a programming language. A shell is an interactive environment and only a programming language by way of the Turing-complete nature of its grammar. However, if I am stringing more than a couple commands together something has gone terribly wrong. The features I care about are features that make that interactivity better, not a type system.

eecc 3y ago
Uhm, so what about REPLs? Jupyter notebooks? Are they wrong? What if the typedness of the shell made the interaction better? Can you make an argument that this does not hold? The article does make a good argument in favor
- nickelpro 3y ago
  REPLs and notebooks and all the rest are great. NuShell might be a great REPL, I don't know, don't really care. The fact no one uses a REPL as a shell, and there's no demand to add direct exec() to REPLs, demonstrate they're different categories. Let programming languages do what programming languages are good at. Let shells do what shells are good at. Please do not write programs in a shell. Do not create a half-assed programming language in a shell to encourage people to write programs in said shell.
  - Per_Bothner 3y ago
    Huh? Using a shell interactively is a REPL. REPL means Read-Eval-Print-Loop. That's what you do when you type commands to a bach/zsh/fish/nushell/... prompt. But it also how you type commands to a gnuplot or Mathematica or APL or Python or Lisp prompt. Some REPLs have nicer interactive features (such a completion than others). Some REPLs have nicer or more powerful syntax or different data types. But as longs as you have a Read-Eval-Print-Loop it's a REPL.
Eji1700 3y ago
The article admits basically exactly this, but also makes arguments as to why? ``` He proceeded to explain that if he could recreate many of the techniques we showed all as part of a C++ library that people could use. At this time, I wasn't sure how to respond other than "but you don't have to, we already built this language" but he couldn't be swayed. If it wasn't C++, he didn't want it. Fast forward a couple years, and I'm standing in front of a JavaScript audience giving a similar talk, this time promoting TypeScript. I remember the kind of politely confused looks on people's faces as I showed off the features TypeScript offered. There was a similar sense of "why do we need to leave JavaScript?". To answer whether Nushell can overcome this kind of inertia, I'll pose two questions: Is Nushell compelling enough for a single person to adopt it? Would adopting Nushell broadly as a community move the needle? Let's tackle the first question. Time and again, as people try Nushell, they come back with quotes like "this is the most excited I've been about tech in 15 years". It has a fanbase that loves it, and that fanbase is growing. It reminds me of the early days of Rust, just after hitting 1.0. To the second question: would adopting Nushell broadly actually improve things noticeably? Without a doubt. I say this without any reservation. Thinking of our shells as structured, interactive processing engines opens up the doors to a much wider array of things you can do with them. The commands would be far simpler than their POSIX equivalents and would compose far better. They'd benefit from the full knowledge of the data being shared between them. Adaptors could be made to connect to all parts of the system, allowing you full, structured interaction with everything you have access to. ``` I enjoy nushell, but I am far far far from the average user/target audience. I do not sys admin or anything like it, I mostly use it to quickly navigate the filesystem and, with nushell specifically, occasionally to work with data i've gotten from other things. I haven't gotten quite to the point I would write scripts in it yet, but at the point i'm considering throwing up an FSX file or going into a repl, I like that I might just be able to use nushell instead for the smaller tasks. Is this useful? To me, sure, to everyone else, hell if I know. edit- Article even touches on this mindset: > I don't need to do heavy data processing everyday, but it's nice to not have to shift what I'm doing at all when I need to do it. I don't have to download new utilities or switch languages. It's all right there. Need to write a script to load some files and handle some directory processing? Still right there. Need to throw together some web query that outputs the top download results for a github repo? You guessed it, all still right there.

LispSporks22 3y ago

I can’t live without job control

p-e-w 3y ago

> Recently, I had a chat with some of my friends about Nushell and why they stuck with traditional shells like bash/zsh or the "new" hotness like fish rather than using Nushell. Umm... because Nushell is pre-1.0, with major language changes every few weeks? Living on the bleeding edge isn't everyone's cup of tea, and certainly not with something as fundamental to the system as a shell. Rest assured I will switch the moment 1.0 is released and a stability promise is published. That being said, yeah – Nushell is the real deal. It's the Unix philosophy, except this time it actually works.

imiric 3y ago
> It's the Unix philosophy, except this time it actually works. How is Nushell compatible with the Unix philosophy? The core Unix philosophy is about enabling workflows that combine a set of independent tools in novel ways. Nushell implements a monolithic ecosystem with commands that support its fancy features, but using any external command not written for Nushell will be cumbersome at best, and incompatible at worst. This goes against the open philosophy of Unix, which is partly what has allowed it to grow and succeed.
- ChrisSD 3y ago
  So long as a tool can output a machine readable format, it can be consumed by nushell. If it can't then... that's actually a big problem when composing tools in bash too. Parsing arbitrary unstructured text is not good for composition and requires making something bespoke for each and every tool. As well as each and every argument for each and every tool for those arguments that happen to change the output in different ways.
  - imiric 3y ago
    > Parsing arbitrary unstructured text is not good for composition and requires making something bespoke for each and every tool. Right, but therein lies the flexibility of using unstructured text as the exchange format. Each tool doesn't need to be aware of the format it needs to consume or output; it just cares about what makes sense for itself and the user. It's up to the user to determine the best way of composing each tool within a specific pipeline. This might seem cumbersome, but there are a limited set of ways tools can be composed, and generic helper tools exist for a variety of use cases (xargs, sed, awk, grep, cut, paste, etc.). If one tool breaks, then it's easy to either replace it, or fix the pipeline to support that specific tool. In contrast, by making a strict contract of the exchange format, each tool needs to support a specific contract, and any deviation or update of it means that all tools need to be updated as well, while also maintaining backwards compatibility. This might be fine for a monolithic environment where a single project maintains all tools, but it's unsustainable if one wants to build an open ecosystem of tools that work independently, but can still be composed in any pipeline.

guitarbill 3y ago

Maybe I'm not using my shell to the fullest, but 95% of commands are pretty simple, and not complicated queries. `ls` might have a bajillion flags, but `-lah` go a long way. Because fish's autocomplete, I don't have to remember tar flags. That's the killer feature for me. Along those lines, a quick way to drive adoption could be a huge "how do i do x" or recipes page to Ctrl+F through. If I have to search the internet for how to do x in nushell/fish/etc, I might as well stick to arcane bash - at least you know someone has had the same problem before. Make it easy for me to get stuff done by showing me how to get stuff done, and I'll grok the shell bit by bit. I did see https://www.nushell.sh/cookbook/ https://www.nushell.sh/cookbook/ , but it isn't really a searchable reference. There's some setup stuff, other short pages with basic tutorials (?), a link to a repo with example scripts, and for one-liners you are instructed to join a discord. None of these are easily searchable.

gsuuon 3y ago
There is a 'Coming to Nu' section of the nushell book which covers 'how do I do x' coming from other shells: https://www.nushell.sh/book/coming_from_bash.html https://www.nushell.sh/book/coming_from_bash.html
westernpopular 3y ago
> Along those lines, a quick way to drive adoption could be a huge "how do i do x" or recipes page to Ctrl+F through. If I have to search the internet for how to do x in nushell/fish/etc, I might as well stick to arcane bash - at least you know someone has had the same problem before. https://github.com/tldr-pages/tldr https://github.com/tldr-pages/tldr
pxc 3y ago
> If I have to search the internet for how to do x in nushell/fish/etc, I might as well stick to arcane bash - at least you know someone has had the same problem before. I feel the opposite way: if I don't really know Bash, I'm not throwing away a bunch of my hard-earned knowledge and experience to start again from zero by switching to Fish. It's just a lateral move, and an obvious win if the shell it takes me to is simpler, smaller, or otherwise easier to learn.

parasitid 3y ago

and there shall be Emacs Shell ;) https://www.gnu.org/software/emacs/manual/html_mono/eshell.html https://www.gnu.org/software/emacs/manual/html_mono/eshell.h...

mongol 3y ago

I tried it briefly and the fact that find means grep and so on will be a tough nut for me to crack, learning-wise. I understand that if you start from a clean slate, you want to make the experience internally consistent. But how do you as a user manage, when your muscle memory is used to something else?

coldtea 3y ago
>But how do you as a user manage, when your muscle memory is used to something else? Like with anything else new: if you find it worth it, you develop new muscle memory.
- waynesonfire 3y ago
  Just don't see it. I'd need at least 10x improvement to switch and that means fundamental changes to interacting with processes as I'm petty surgical with bash, find, awk, sed. A shell isn't 10x by being a union of all the best tools, it needs to redefine them. And 'where' doesn't come close.

imiric 3y ago

Nushell is definitely interesting, and I'm glad it exists, but I'm not using it because of at least a couple of major reasons: - It reimplements all commands. You're not actually using GNU coreutils, but Nushell reimplementations of ls, rm, etc. See [1]. I understand why it's done, but this has many drawbacks: 1. All existing shell examples and documentation spanning decades are useless. Nushell commands try to replicate existing UIs, but they invariably must be incompatible to support all features and deprecate unnecessary ones, so the only valid source of documentation is Nushell itself. 2. Nushell-specific bugs[2,3]. This goes without saying, and will improve as the project matures, but experiencing bugs with core commands is jarring. I've never had that with GNU tools. 3. Unsupported commands won't have any of the benefits, and you'd still have to parse their output in the traditional way, or use a Nushell helper. How often this happens will depend on your use case, but you'll always depend on Nushell for integrating that command in your workflow. - Related to point 3, Nushell is building an entirely separate monolithic ecosystem, which goes against the open ideology of Unix. This is similar to BusyBox, where you always have to be aware you're not using GNU tools, but some slightly incompatible equivalents. More importantly, this approach doesn't scale. There will always be new commands that target POSIX shells, but not many commands will be written specifically for Nushell. I appreciate what projects like Nushell and Murex are trying to address, but having a saner scripting language and passing structured data in pipelines is not worth the drawbacks for me. For one, Bash scripting is not so bad if you set some sane defaults and use ShellCheck. Sure, it has its quirks, but all languages do. Even so, the same golden rule applies: use a "real" programming language if your problem exceeds a certain level of complexity. This is relative and will depend on your discomfort threshold, but using the right tool for the job is always a good practice. No matter how good the shell language is, I would hesitate to write and maintain a complex project in it. And for general QoL improvements with interactive use, Zsh is a fine shell, while still being POSIX compatible. [1]: https://github.com/nushell/nushell/blob/main/crates/nu-command/src/filesystem/ https://github.com/nushell/nushell/blob/main/crates/nu-comma... [2]: https://github.com/nushell/nushell/issues/5027 https://github.com/nushell/nushell/issues/5027 [3]: https://github.com/nushell/nushell/issues/9310 https://github.com/nushell/nushell/issues/9310

hnlmorg 3y ago
> I appreciate what projects like Nushell and Murex are trying to address, but having a saner scripting language and passing structured data in pipelines is not worth the drawbacks for me. Murex doesn’t change any of coreutils. With murex can use the command line as dumb byte streams with the standard GNU / BSD utils if you want…and in fact I do just this myself. What Murex offers is an abstraction on top that allows you to add type hints to those byte streams so you can do fancier stuff with it if you wanted. Think of it like what Typescript does for JavaScript. You have access to all the same POSIX utilities and additional type aware controls on top but it’s completely optional if you want to use those type aware controls (personally, I think once you do, you wouldn’t go back, but I respect people’s personal preferences).

hresvelgr 3y ago

The case for Nushell is weak because shells are not an ideal environment, but rather a lowest common denominator by today's standards that has stuck and hasn't disappeared. What we need is a better interactive environment interface. It baffles me that something like Pharo's interactive environment hasn't been copied all over the place. I understand it's largely because it's a self contained environment that it is able to afford the functionality it has, but there are lessons in there worth learning from.

coldtea 3y ago
>The case for Nushell is weak because shells are not an ideal environment Not sure what "an ideal environment" even means, but shells have tons of very nice features. The problem is they also have a lot of legacy bs and tons of footguns.
- hresvelgr 3y ago
  > Not sure what "an ideal environment" even means, but shells have tons of very nice features. If you haven't, I would encourage you to try Pharo. It's a Smalltalk dialect but you program through what feels like an operating system. The richness in interactivity and feedback is unparalleled. This is what I would consider an "ideal environment." Shells are useful tools, they wouldn't have the ubiquity they do if that weren't true. That being said, there's definitely more interesting and powerful paradigms out there for interacting with an operating system at a lower level.
  - theamk 3y ago
    My years doing hardware development and driver programming in college taught me about the evils and endless frustration of invisible, un-resettable state. "Why did my driver worked the first time but exactly same code fails now? Which of hundreds of hardware registers did I forget to reset _this time_?" Same thoughts appear when I look at Smalltalks... Ok, I can edit any function or variable, including a system one; and the changes would be saved automatically in opaque persistent "image". So if you mess a system function, your whole system is unusable and you have restore from snapshot; and even something as simple as a program which continuously pops up message boxes can make system unusable (and again, require restoring from snapshots). It's like Windows 98 but with no reboot option!

hnlmorg 3y ago

This post implies the decision is between nushell, MS Powershell or something based on shells from the 70s. But there are a plethora of other shells like nushell, that have been around for longer than nushell. It’s actually a pretty crowded market space. So why are people still using bash? In part because it’s a default (defaults are hard to change) and in part because it’s largely “good enough”. It’s the same reason JavaScript is everywhere. First because it was the default in browsers and then because it was good enough that people didn’t want the effort of having to learn nor use another language.

dubcanada 3y ago
Like what? I’d love a stable nushell alternative.
- hnlmorg 3y ago
  Stable is a problem because a lot of these shells don’t offer any guarantees for breaking changes. My own shell, https://github.com/lmorg/murex https://github.com/lmorg/murex is committed to backwards compatibility but even here, there are occasional changes made that might break backwards compatibility. Though I do push back on such changes as much as possible, to the extent that most of my scripts from 5 years ago still run unmodified. In fact I’ve started using some of those older scripts as part of the automated test suits to check against accidental breaking changes.
- geophile 3y ago
  Check out my entry, marcel: https://marceltheshell.org https://marceltheshell.org. E.g., find the newest vlc instance and kill it (a command that an acquaintance needs frequently, for some reason): ps | select (p: p.name == 'vlc') | sort (p: p.create_time) | tail 1 | (p: p.signal(9)) - ps produces a stream of Process objects. - select binds each Process to p, and then selects those whose name is vlc. (Anything in parens is a Python function. You can include or omit "lambda".) - sort by create time, (using a Python function to specify the sort criterion). - tail 1 as in Linux, to get the newest qualifying Process. - Run the function p.signal(9), which kills the Process.

jakobnissen 3y ago

Nushell is a great improvement in terms of shell design, and it really does feel like a modern, better equivalent of the shell. However, I tried using it twice as my main shell and had to give up both times. The first time, I experienced a handful of bugs. The most annoying one was that I couldn't copy-paste passwords into the shell because Nu kept inserting control characters. Then I kept having trouble with other programs that rely on the shell - for example, "conda init" does not work with nushell, nor does Julia's shell work with nu. So practically speaking, I had to continually boot up zsh inside Nu. Then, there are the constant breaking changes. It feels like every month there is some breaking change, and every few months I need to dig into my nushell setup scripts to unbreak half my shell tools because some syntax changed. Yeah, no thanks. Hopefully someone else will do the annoying work of test running Nu for 5 more years until it's stable and integrates well, but for me, I went back to zsh.

sundarurfriend 3y ago
Do you remember what issues you had with Julia's shell mode when using nu? A (very) cursory look at the Julia code doesn't reveal any obvious problems, but there's probably some hidden assumptions (possibly around POSIXness) that's causing troubles.

fergie 3y ago

Nushell is part of the ongoing Visual Studio-ification of software engineering. TypeScript and Powershell are preferences, not standards. If you want to use them, great, but its wrong to say that these have evolved into defacto ways of doing things. Also- that everything is text in Bash is one of its great strengths, just as Powershell's reliance on Objects was generally understood to be a weakness. Also- I don't get the need for IDE support? Surely the point of a shell language is that it is designed to be used for a terminal? As others have said here- this feels like a better case for nushell as a scripting language than nushell as a shell.

pm90 3y ago
IDE support is required if you’re building up complex scripts/custom functions.
pindab0ter 3y ago
Could you expand on the "Visual Studio-ification" of software engineering, and why that would be a bad thing?
- fergie 3y ago
  "Visual Studio-ification": Any technology that requires Visual Studio to be productive. The classic example would be TypeScript, but you can clearly see nushell's overtures to VS in the linked article. A de facto requirement on VS to make a webpage is bad enough, a de facto requirement on VS to write a shell script is even worse.
  - fortunateregard 3y ago
    Hover/go-to-definition seems more like a nice-to-have than a requirement. Either way, neovim support can be found here: https://github.com/LhKipp/nvim-nu https://github.com/LhKipp/nvim-nu
  - DangitBobby 3y ago
    It has nice error messages so you definitely don't need an IDE to edit scripts.

meeho 3y ago

> Nushell is designed to be a language Last time I checked it didn't have functions. Has that changed?

milliams 3y ago
It does, see https://www.nushell.sh/book/custom_commands.html https://www.nushell.sh/book/custom_commands.html def greet [name] { $"hello ($name)" } They were added in 0.25 in January 2021 (https://www.nushell.sh/blog/2021-01-05-nushell_0_25.html#custom-commands https://www.nushell.sh/blog/2021-01-05-nushell_0_25.html#cus...)

extr 3y ago

Maybe a hot take but copilot CLI has obviated the need for this kind of thing for me personally. Most of my shell commands are incredibly simple, and now with copilot CLI, I have a 80% head start on anything more complex. In fact sometimes I will just type "!! <sloppy command>" and it will autocorrect to basically what I was going for without any further prompting.

xigoi 3y ago

Am I the only one who uses a shell primarily as an interactive interface, not as a programming language? Why do all shells seem to focus on the latter aspect?

hnlmorg 3y ago
They don’t. Murex (my shell, https://GitHub.com/lmorg/murex https://GitHub.com/lmorg/murex ) is all about the interactive environment. Elvish is too.
IshKebab 3y ago
Because the biggest problems with shells are when people think "these commands work for me; I'll just save them in a file".
mongol 3y ago
There is an overlap. I often write for-loops in bash interactively for example. The ideal shell works well for both, but bridging this gap is a challenge.

maleldil 3y ago

Nushell is interesting. I tried using it as a scripting language (fish is better for interactive usage[1]), but I didn't get very far because it's constantly evolving and scripts that work today might not work next week. I can't commit scripts to a codebase if future users can't run them. So I end up using fish for scripting too. [1] Not only does fish have the best out of the box experience (although that's reproducible with plugins in other shells), it's also old and common enough that tools usually support it alongside bash and zsh. Nushell is too niche and always changing for tools to support it properly.

em-bee 3y ago
>fish is also old and common enough that tools usually support it for many years, more than a decade at least, this was not the case. it was a long and hard road for early fish users to get to that point. and i'd make the claim that todays openness towards alternative shells that break compatibility with traditional syntax is in large part thanks to the groundwork done by fish. that is to say that if nushell can present a compelling argument with its improvements, then there is hope yet. but for that to happen focus needs to be on interactive usage that is at least as good or better than fish and not just focus on better scripting. there is a place for better scripting. gluing together multiple tools where input, output and arguments to commands matter is something normal programming languages don't do well.
- maleldil 3y ago
  I agree with you overall. Still, the reality today is that Nushell has a long way to go in terms of support. I think it's hard for Nushell to do something for interactive usage that would displace fish for me, but I'm always open to exploration. The thing that resonates the most with me is the need for a better scripting language. A "proper" language, that worries about types, not just stringly typing everything. I think Nushell is making good progress on that, and the main reason I don't use it today is because it moves and breaks too fast for my taste.

fiedzia 3y ago

The case for any other shell: ls -R and find exist and work. Nushell doesn't cover that. I like the idea, but execution has so glaring holes that I had to go back to fish 1 min after installing nu. (there is glob ** that doesn't have any column and I don't see a way to compose it with ls, and ls ** doesn't work).

tux3 3y ago

My main criticism of nushell is that it seems to be more developed as a programming language than as a shell. Looking at the bug tracker, someone asked 4 years ago how to separate multiple commands, as in `git pull; git push`. It turns out, this is hard with nushell. At some point a ; syntax was added in nushell, but it is NOT the separator you expect. It's actually a strange cross between bash && and ; `echo a | grep b; echo ok` does NOT run the second command, so here nushell ; is like bash && `false; echo ok` DOES runs the second command, so here nushell ; is a plain ; There is no exact && equivalent. There is no || equivalent syntax at all. And the closest form of a plain bash ; I could find is |1; (piping into a constant value, which guarantees a 0 return code, so that ; will never fail)

em-bee 3y ago
which programming language doesn't allow multiple statements on one line? ok, there may be a few that strictly require linebreaks to start a new statement and lisp where everything is one huge statement with nested expressions. but not supporting this in a shell looks like a deal breaker. the primary function of a shell is to execute a sequence of commands.

EdiX 3y ago

I think nushell makes a pretty good case against itself. Take ls: like the article says gnu ls has tons of options to configure how its output is displayed. But that's because ls is a user interface for displaying lists of files. I'm not sure how the proponents of all these new shell keep missing this point. If you just want a list of files in a POSIX shell you use a glob expression. But whatever, nushell has its own builtin ls that is for getting lists of files. And then you pipe it into other commands to configure the output. Great. Can I get the output to be like 'ls -C'? Nope. Can I turn off colors? No. Can I add the indicator character like 'ls -F'? Not a chance. Well, at least I don't have to pass '-l' just to see the file mode... actually I do, otherwise it would be too slow. Many of the options that clutter gnu ls are generic options that apply to all tables, and it would be nice to abstract them. But many aren't, many are specific to what ls is doing and it's hard to me to see how this all could be generalized in a way that applies both to ls and to grep. For now nushell sidesteps the problem by not having its own reimplementation of grep, unlike ls if you type grep you get real grep and you can't pipe the output into anything meaningful. The best I could do to replicate grep inside nushell was this: cat haystack | split row -r '\n' | enumerate | where item =~ needle asides from the shocking verbosity, I can't see any way to replicate the --color option of grep, or -A and -B. The cop-out solution to this is to have builtins return objects (as in OOP objects, with methods), but then everything needs to be written in the same language.

ripley12 3y ago
If you want to use grep in Nushell, you can use grep and pipe the output to `lines` to split the raw output by line.
dwattttt 3y ago
> If you just want a list of files in a POSIX shell you use a glob expression. I think this sums up the problem. If you want a list of files for display you use ls, and if you want it for other purposes use a glob; it seems much more elegant to have one way of getting files, and a separate way to format it for displaying if that's what you want.
- theamk 3y ago

follower 3y ago

Today I learned (after disappearing down a rabbit hole after reading the linked article) that it's actually possible to begin to use & benefit from nushell's structured data pipe feature without changing one's current shell. Structured data pipes have always been my primary reason for keeping an eye on nushell's development but after looking at the project's documentation again today it all still seemed "too much initial effort with uncertain outcome". Because I don't want to switch my shell (not because bash is good but because it's not a priority to justify the expenditure of effort), I just want to have structured data in pipes within bash! Turns out it's as easy as: nu --commands 'ls | where size > 1MiB' (Where `nu` is the nushell binary being called from your existing shell prompt.) Or, as more complete flow of data example: echo "[1,2,3]" | nu --stdin --commands 'from json | to json' | cat Now you can fit nushell within your existing workflow where ever it's useful enough for you--without needing to commit to changing your entire shell. (And this isn't the only or necessarily the best way to arrange things for the communication with bash--there's "^" & "externals" & "command signatures" & "from ssv" etc too.) And nushell does have some nifty tools such as `explore` with `:try` to interactively build a processing pipeline. But this information doesn't seem to be documented anywhere in the "book" or other introductory material. It only seems to be documented in the help message of the `nu` binary--which I almost didn't even get as far downloading today. But then I found the help text in the source, so decided to try it again: https://github.com/nushell/nushell/blob/fd4ba0443d01e67f6304b7220ef414a33287bdbe/src/command.rs#L248 https://github.com/nushell/nushell/blob/fd4ba0443d01e67f6304... If the structured data pipes is one of the main appeals for you, maybe try this approach out?

lelanthran 3y ago
> Turns out it's as easy as: They should have lead with that. I ignored nushell only because of the limitations of using a non bash shell with no sequence of commands using ;, && and ||.
ramblerman 3y ago
Nice, that's a great way to begin using it and testing the waters.
follower 3y ago

sunshine-o 3y ago

I guess we all appreciate the traditional Unix shell as an incredibly stable tool over the last 50 years (!). But let's face it, it's hard to justify that a kid born in this millennia should learn & use this antiquated & obscure software. My fear is I suspect the success of those YAML based Ansible or Github Actions tools is the result of people being afraid or tired of writing shell scripts. But let's face it those are abominations because it lock you in a platform and you end up drowning in way too many YAML files. So yes I believe we need an ambitious update to the Unix shell and the Nushell team did a pretty good job. If we don't we will have to deal with many of those "automation" platforms & their poor configuration "languages".