[cyber_kinetist]

I use it as my primary driver, for the sole reason is that it's the only cross-platform shell that properly supports Windows (without resorting to Cygwin/MSYS, which has performance issues and many pain points). I'm still getting used to the syntax though...

(Edit: forgot to mention Powershell, since nowadays it also works on Macs and Linux)

[deafpolygon]

Why use this over PowerShell for example?

[cyber_kinetist]

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.

[delta_p_delta_x]

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

[VWWHFSfQ]

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.

[delta_p_delta_x]

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

[forgotpwd16]

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

[dec0dedab0de]

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

[thesuperbigfrog]

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

[0x445442]

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

[joombaga]

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

[juki]

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

[sixothree]

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.

[vips7L]

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.

[juki]

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.

[papascrubs]

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

[vips7L]

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

[deafpolygon]

/mind blown/

very nice.

[deafpolygon]

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.

[ripley12]

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

[sixothree]

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.

[ripley12]

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.

[chasil]

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

[ripley12]

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.

[pie_flavor]

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.

[ripley12]

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?

[pie_flavor]

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.

[stevefan1999]

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

[anthk]

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

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

[cassepipe]

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

[haltcase]

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

[forgotpwd16]

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.

[pletnes]

Doesn’t xonsh run correctly on windows? I used it but hated the environment due to the lack of utilities on windows (it’s just a shell, not an environment).

[BeetleB]

xonsh (Python based shell) works fine on Windows. Been using it for over 4 years.

[actually_a_dog]

I'm curious what you mean by "properly supports Windows." Are you on a version of Windows that supports WSL2 (Windows Subsystem for Linux)?

[cyber_kinetist]

I really don't want to start up a separate Linux VM just to open up a shell. (I already crossed out Cygwin / MSYS on the list because of performance issues...)

[cyber_kinetist]

Also, I need to compile actual Windows binaries using the shell (MSVC, clang-cl), and I obviously can’t do that under a Linux VM.

[yamtaddle]

MSVC's command line tools kick off just fine from shell scripts running under WSL2. Much to my surprise. I assume it doesn't run in the VM.

[chasil]

Busybox for Windows has a very accessible shell.

[cyber_kinetist]

Yeah, I've used that before. But it was a bit too minimal for my tastes.

[pletnes]

WSL is great but it’s basically a convenient VM. It’s no longer windows, as far as I’m concerned.

[chem83]

It’s a lightweight Hyper-V VM, just like Windows itself when you turn Hyper-V support on (boots hypervisor first, then the Windows VM in the root or parent partition)[0].

But if that’s an issue, WSL1 is still an option.[1] It’s a thin translation layer between Linux kernel calls and NT kernel calls, which was the original concept of subsystem from the early NT days which allowed OS/2 apps to run on top of ntdll.dll.

WSL2 didn’t replace WSL1.

[0] https://learn.microsoft.com/en-us/virtualization/hyper-v-on-...

[1] https://learn.microsoft.com/en-us/windows/wsl/compare-versio...

[pletnes]

It’s not an issue, in fact as a Linux fan it’s magnificent! However it is not windows so if you want to use it for windows stuff / software development there’s going to be some edge cases, performance penalties and hiccups. So long as you stay inside the WSL2 VM and filesystem it’s fantastic.

Also WSL1 was a subsystem in the NT kernel but WSL2 is not like this - it runs a separate Linux kernel, with some convenient integrations. WSL1 never did support all the features - I recall I had to use windows .exe executables for some software packages that do have apt-installable packages.

[ripley12]

> WSL2 didn’t replace WSL1.

It kind of did, IMO. You can still use WSL1, but my understanding is that it's a dead end; MS has given up on the translation layer approach. WSL1 will still get bugfixes but it seems pretty clear that WSL2 will get the lion's share of investment going forward.

[sixothree]

It's literally a subsystem. It's integrated in many ways you would not use to describe a "VM". I don't understand the aversion nor the confusion.

[rewgs]

Here’s an example: if I build a Python app with PyInsyaller (which can’t cross-compile), and if I want a Windows executable, I have to build on Windows, not WSL, which defeats the whole purpose of “bash on Windows” because now at best I have to use Cygwin or Powershell or something and deal with a completely different environment.

[dragonwriter]

You can run windows programs from whatever Linux shell (in WSL) you want, because the Windows filesystem is mounted and Windows executables run in the Windows environment.

OTOH, if you are doing anything complicated, it gets weird because (e.g.) file paths have to be passed as windows paths to windows programs, not using the linux mount path that you would access the path from in linux. But, you can, in principle, use a Linux shell in WSL to run Windows PyInstaller to build for Windows.

[Semaphor]

I thought since WSL2 it’s just a Hyper-V VM with some nice upfront configuration (like mounting all windows disks)?

[sixothree]

I'm pretty sure Windows itself, as in your desktop, runs virtualized under many circumstances; and nobody seems to complain about Hyper-V then.

And to be clear, WSL2 is very much integrated into windows via the filesystem and networking. I like to think of the networking more akin to docker than anything else.

[jdmichal]

It can also cross-run programs and UIs. I can type in `code .` in my Ubuntu image, and VSCode will open in Windows at that directory. I can also run UI programs in Ubuntu and their windows pop up in the Windows desktop environment.