brian

bc nu does everything pwsh does, but without the odd and verbose syntax. their exceptions and error codes are two different systems and don't make sense by default. instead of making shell cmds easy to parse I find myself having to use dotnet versions of things, which would be fine if the syntax for that wasn't so terrible. nu still feels like a unix shell for the most part.

pwsh has its place, especially since it's default. I've written plenty of pwsh scripts at work for ci and the like. I can get over the verbose naming in a text editor. using it from a repl isn't my favorite experience

I love alternative shells. my shell has been set to fish and zsh for about a year each, xonsh for a few years, and now nushell for a couple years, and I think that's probably my ranking as well.

fish and zsh are both nicer than bash, but they don't give you as much as xonsh and nu do. you get nice completion and configuration and such, but it's still a shell when it comes to the programming tasks.

I don't want just a shell, I want a programming language with a good repl that makes it easy to deal with commands. xonsh and nushell both do that.

my major problem with xonsh was that there was python syntax, and there was shell syntax. it didn't feel great to interleave sh cmds and py fns. everything had to be parsed and then everything had to be formatted to go back into sh cmds. the standard library of sh cmds doesn't really exist either. you either use the py version of libraries for paths/processes/whatever, or you call and parse the os version. the former seems like the intended one. I found myself having to find a pip package for whatever task.

nu solves all my problems with xonsh without sacrificing much. there isn't really a split between nu commands and shell ones syntactically. parsing is easy, most cli things output data as lines, ascii tables, or have a json flag, and nu has nice ways to deal with all of those. nu commands generally work given a single element or a list or a full table if they make sense to. running a command on each element in a list and dealing with the output is easy as opposed to having to break your pipeline and write a for loop. they also have plenty of builtins and plugins so the things I generally want to parse are already done. ls returns a table, ps returns a table, I can pass lists into rm, etc. there's community plugins for git so I don't have to remember their syntax for searching for commits, I just query in nu. aws cli has a json flag so I can explore logs and such as nu data. and if I just want.

now downsides to nu. it's not bash so you can't just source whatever file that a command probably gives you, and there's no source-bash like xonsh has, so you're stuck translating it to nu. if it just sets env vars it's not awful since you can just shell out to bash, but doesn't work for more complicated. for things like python you have to make sure you use the correct tool to make your venv since builtin one doesn't give you a nu file to load. not sure about support in other tools.

overall it's great and not really that much learning, especially if you just use it like a shell to begin with. it's not much commitment to try a new shell since you can still call scripts written in your previous one. I'd say try it and see how it goes

the pueue plugin isn't perfect but it covered all my uses at least

worst case you're parsing command output like you would in bash, so you're not really worse off. I've got a handful of aliases that wrap commands I run often so I only dealt with parsing in the beginning. there are enough builtins that output structured data, or applications that have a json flag that it's still useful.

speaking of powershell, it's easy enough in nushell to write an alias that shells out to pwsh and calls ConvertTo-Json then from json on the nu side. that gives you plenty of extra commands that are structured, at least on windows

termux has some sort of gui support. I've never used it but that'd probably be your best bet

it's not data validation like you'd put in a dto, it's an assertion library for unit tests and such. It's mostly just sugar that makes chaining together assertions more concise with better autocomplete you get from fluent apis. You can do the same thing with built in Assert but it's nowhere near as nice to use

try opening that cdn link you sent in a browser. it'll open a directory listing for the package. you can see some examples of what urls to use on the main jsdelivr page.

I imagine the url you want is probably something like https://cdn.jsdelivr.net/npm/lemmy-js-client@0.20.0-image-api-rework.8/dist/index.js (note the extra path on the end and also a specific pinned version instead of latest so new versions don't break things)

you could in micropython at least. it's not unixy but for example see https://github.com/Rybec/pyRTOS

on one hand I agree. on the other, google has historically been afraid of the verb to google becoming generic, so of course I'd like to see that happen.

I think the middle ground is say google it, but make it clear you mean google it on an alternative search engine

I assume that's just the actual vegetable, Google translate says that's correct

looks like misattribution looking at the linked comments. not something tim cook said, just someone replicating his routine but with the other mouse

that is a can of Folgers. I'd argue that incriminating a kitchen scale in the process makes it even worse