Hacker News Reader

Comment by deafpolygon | Hacker News Reader

Why use this over PowerShell for example?

Well, it is a good point, since nowadays PowerShell is also cross-platform, and seems to have more features than nushell does.

Though the true reason is: I haven't really found the time to. Changing a shell is really stressful since you have to unlearn / relearn lots of things from muscle memory, and PowerShell's huge deviance from the rest of the POSIX-y world doesn't help. At least in nushell `rm -rf` works, the same doesn't in PowerShell.

> PowerShell's huge deviance from the rest of the POSIX-y world doesn't help

In PowerShell (on Windows), `rm` is an alias to `Remove-Item`[0].

Therefore,

    rm -r -fo <thing>

An extra dash, extra space, and extra letter isn't too bad by my books. Furthermore, in scripts, aliases are discouraged by PSScriptAnalyzer[1]; IDEs (PowerShell ISE, VS Code PowerShell extension) also support code completion, so:

    Remove-Item -Recurse -Force <thing>

makes things clearer.

[0]: https://learn.microsoft.com/en-us/powershell/scripting/learn...

[1]: https://github.com/PowerShell/PSScriptAnalyzer/blob/master/d...

why do they alias all this stuff. Remove Item is _not_ rm. It's so stupid. Like when they aliased wget and curl to some nonsense web request command and everybody complained that it didn't work.

I'll never use PowerShell. Just way too many bad decisions all over the place.

> why do they alias all this stuff

The alias only exists on Windows. Did you read the linked page?

    The aliases in this table are Windows-specific. Some aliases aren't available on other platforms. This is to allow the native command to work in a PowerShell session. For example, ls isn't defined as a PowerShell alias on macOS or Linux so that the native command is run instead of Get-ChildItem.

`rm` was never an executable on a pure (aka non-MinGW, non-Cygwin, non-MSYS2, non-WSL) Windows console; the equivalents were/are `rmdir` and `del`. Microsoft's position is clear that PowerShell is meant to supersede these old commands, and hence the aliases, but again, only on Windows. I agree that Microsoft made some strange decisions to alias `curl`, etc on other platforms too in PS6, which were reversed for PS7.

These aliases are meant as stepping-stones for POSIX-first people to get their feet wet with the Windows command-line.

>why do they alias all this stuff

To make interactive usage easier? PowerShell essentially replaces the text-oriented environment provided by coreutils with an integrated object-oriented one.

In hindsight it probably would have been better if they just had a help message with something like "Oh you must be a *nix user, thanks for trying Powershell! You can do something similar with command xyz. Read that command's documentation -here- , and read a guide on the differences between posix and powershell -here-"

And if you want to do multiple things you have to separate them with commas:

rm -r -fo thing1, thing2

Or in the non-recursive way:

rm thing1, thing2, thing3

When PS has pushd, popd and dirs -v I’ll switch.

It has Push-Location and Pop-Location, which are aliased to pushd and popd. IDK about dirs -v.

`dirs -v` would be `Get-Location -Stack`. Also in newish versions PowerShell `Set-Location` (aliased to `cd`) supports -/+ to move backwards/forwards in it's own history, so usually you don't even need to bother with `pushd`/`popd` unless you need a named stack.

what about pushd 7 to go to the 7th path in the stack?

Just get the 7th path from `Get-Location` and `Set-Location` there, e.g.

  function Set-StackLocation ($Position) {
    (gl -Stack).Path | select -Index $Position | cd
  }

Seems like a lot of work for something that's just built into bash and is extremely useful.

Like all shells, PowerShell is split between being a scripting language and an interactive shell.

PowerShell leans a bit more towards being a scripting language than an interactive shell, so things are more verbose, as befits a shell script that needs to be read and updated later by a different programmer.

But yeah, lots of little trade offs like that permeate the language.

Less work than trying to add named stacks to bash. If it's so central to your workflow that you're willing to put up with the rest of bash just for it, adding a couple lines to your profile can't be that big of a deal.

Well, it's the first time I saw the magic incantation listed above so I may give it another try know.

I am a C# programmer at heart, and I use powershell a good bit. I can honestly say I can never use powershell without my cheat sheets or my list of favorite commands (and especially the arguments to use).

I looked at this and kinda get it and think I could do some things with it. I don't think it's as powerful and can _definitely_ say it won't be capable of the same automations we use.

That said, the text parsing people do with bash makes me cringe. It's so repulsive and sketchy. Anything to get linux world off of bash would be a good thing.

Do you use pwsh as your daily driver? I find that its commands are as easily memorable as any other shell.

That being said You should enable these:

    Set-PSReadLineKeyHandler -Key Tab -Function MenuComplete
    Set-PSReadLineOption -PredictionSource History

MenuComplete will give you a menu of arguments that each command takes so you can easily see them when pressing tab for completions and prediction source will try to predict the commands you want based on your history.

Also make sure you're on latest version of PSReadLine (I had some problems with it not updating properly and had to do a manual `Install-Module PSReadLine -Force`) and try

  Set-PSReadLineOption -PredictionSource HistoryAndPlugin -PredictionViewStyle ListView

You can also toggle between the default inline and listview with F2. Also if you install

  Install-Module CompletionPredictor

and add this to your profile:

  Import-Module -Name CompletionPredictor
  Set-PSReadLineOption -PredictionSource HistoryAndPlugin -PredictionViewStyle ListView

you also get the normal intellisense autocompletions in the listview. And remember that if you have all the help files installed locally you can use F1 to view help for the current parameter/command.

Been using the latest PSReadline but CompletionPredictor is awesome and exactly what I've been looking for.

One other PowerShell protip

Ctrl+Space is also another great shortcut for completing commands, it lets you see what type a parameter is expecting etc.

    $ Get-ChildItem -<ctrl+space>
    Path                 Depth                File                 ErrorAction    
    <snip>
    [string[]] Path

Thanks! I haven't seen CompletionPredictor before. I'll give it a shot.

/mind blown/

very nice.

I use pwsh as my daily driver, and the verbosity actually reduces my need for a cheatsheet.

What I'd love is for Powershell to _stop_ adding .\ to my tab completed files. Just quote it and leave it alone, unless it's an executable.

Once I got used to stuff parsing as objects, it's really hard to go back to everything-as-a-string in bash. I've gotten to writing a few personal scripts/modules.. processing stuff in JSON is just really nice.

> can _definitely_ say it won't be capable of the same automations we use.

Anything in particular you think would be difficult/impossible in Nushell?

(I'm one of the Nushell developers, might be able to help or put features on the roadmap)

Honesty, I believe this because of the maturity of powershell and not any inability in nushell. Having literally the number of commandlets and having entire .net framework available makes powershell have more options.

Additionally, pretty much every Windows Server feature is commandable with powershell. Some (much?)_ of the UI stuff in windows is just using powershell under the hood.

That said. I am _very much_ looking forward to using nushell when I use linux or wsl. And I wish your team great success. Linux needs it.

Yeah, we're probably never going to be able to compete with PowerShell's sheer volume of Windows integration points. Shelling out to pwsh is probably the best we can do in some situations.

This is a common complaint among implementers of POSIX shells.

They are not LR-parsed languages, and cannot be expressed with yacc grammars.

Debian dash replaced bash as /bin/sh. It gains speed, but no better syntax.

https://archive.fosdem.org/2018/schedule/event/code_parsing_...

Some reasons I prefer Nushell over PowerShell:

- less verbose syntax

- better cross-platform support (PowerShell is technically cross-platform, but it has some baggage from its Windows-first history)

- way faster to start up

I'm a little biased (I'm a member of the Nushell core team), but those are all things that drew me to start contributing to Nushell.

On the other hand, Nushell is certainly less mature+stable than PowerShell.

Something I've been curious about - are there any plans to sink serious effort into massively expanding the stdlib? Powershell's syntax and object-orientation I could take or leave, but access to the entire .NET Framework is pretty hard to beat, and the same draw exists for xonsh. Nushell is neat but there just aren't enough builtins.

I don't think we're going to be able to compete with PowerShell's bajillions of developer-hours invested in deep Windows integration. But we are looking at revamping the Nu language to make it much more pleasant+powerful as a scripting language.

What kinds of features are you looking for in the stdlib?

It's less any specific missing features and more the confidence that I'll literally never run into a missing feature - the things you almost never need, until you do. E.g. upcasing a Turkish string, or printing a number that does the correct thing with `,` and `.` in the user's current locale. PowerShell's support for ACLs is also hugely helpful - being able to do the structured-data thing with the icacls command would go a long way.

No need for (a minimal set of) dotnet runtime. This means Nushell can possibly run on slightly resource constrained environment such as Raspberry Pi, of course you don't expect it to run well with 256MB of RAM though. Also, Nushell is battery packed. For example, say bye bye to your Oh-my-ZSH because the features you have with OMZ (like shell autocompletion, suggestion, theming and formatting) is built-in in Nushell. I have also tried to parse `zfs list` output in my Proxmox machine that I don't want to use `zfs list | less` that often.

That said, I hope Powershell Core can be packed with dotnet 7 native AOT mode [1] so we don't have to screw around with 100 different MSIL DLL files to run a single shell...

[1]: https://learn.microsoft.com/en-us/dotnet/core/deploying/nati...

>of course you don't expect it to run well with 256MB of RAM thoug

I've run Perl scripts on 32MB...

It's dumb but I personally can't get over Camel-Kebab-Case commands. I hate typing Caps, and hyphens.

PowerShell is case-insensitive, you don't need to type caps for variable/function references if you don't want to. You'll still have hyphens, but in an interactive shell (as opposed to a script) there are many aliases you could use that avoid hyphens (or you can make your own).

https://learn.microsoft.com/en-us/powershell/module/microsof...

It's more Unix-y. Smaller footprint, opens faster, short commands by default. Otherwise the PowerShell influence is vastly understated in project page and docs.

Reply on news.ycombinator.com