[DeathArrow]

>This is just an example from YAML to JSON, but you can convert much more formats into other formats.

>open dev/home-impermanence/tests/impermanence.yml | to json

I can do it with PowerShell:

$os_list = (Get-Content -Path "C:\temp\operating-systems.yml" | ConvertFrom-Yaml)

Set-Content -Path "C:\temp\PowerShell_operating-systems.json" -Value ($os_list | ConvertTo-Json)

[Semaphor]

That is a great example, but for different reasons. I think PowerShell is amazing, but it never feels like something I want to work in as a shell. Writing scripts in an IDE, sure. But to convert some yaml to json I’d much rather type open/file.yml | to json

[0x445442]

This is where I’m at with PS as well. It’s stuck in this no man’s land between bash and python. It’s a better scripting language than bash and a better shell than python. But when compared to their main purposes it’s a worse shell than bash and a worse scripting language than python.

The caveat of course is Windows system administration. I’m sure it’s excellent in that domain.

[Semaphor]

I end up using C# as a scripting language, the GUI on Windows, and ZSH on Linux Servers…

[vips7L]

OP here wrote this the most verbose way I could think possible. Most commands are pre-aliased in PowerShell and arguments are fuzzy matched as long as they're not ambiguous.

For example:

   Remove-Item $directory -Recurse -Force
   rm $directory -r -fo

For this specific example ConvertFrom-Yaml actually doesn't exist as a standard cmdlet and ConvertTo-Json isn't aliased by default:

    gc ./something.yml | ConvertFrom-Yaml | ConvertTo-Json > /some/file.json

[js2]

With any shell:

    $ brew install yq
    $ yq -o json . < config.yml

[ratboy666]

This... yq eats yaml. And this is all I need to know (really). I don't know yaml. I don't WANT to know yaml.

Two letter command which I can remember, in the same way that I know jq. And, as a short-form jo. I would not use jo to eat json. I do think that yq is "misnamed" slightly, in that there is no yo command.

(note that I do have yq installed, but not nushell or PowerShell).

shell is glue, not oop -- json is an object notation, converted to stringyness. Which makes for oop->shell. Since "objects" are programmer-think, this should not be the primary command interface. People (not programmers) recognize this, and thus PowerShell is not used by "non-programmers". Ok, you want something above bash (sh, shell), for more programming structure? This is why the #! construct is exec() is so important. That lets you use... um awk, sh, (and should support PowerShell -- not sure). Even C (with tiny-c). I would go with javascript, myself, because it fits with json, and thus jq and jo in the eco-system.

Now, for a criticism of yq -- jq is 30K for a front-end and 350K (or so) for a library. jo is 120K, yq is (gulp) 12MB. Ok, I have the disk space. And it is GO, so ok. Compared with the other GO programs I use commonly: minio (100MB), mcli (mc, 20MB), doctl (20MB), it isn't bad at all. But, I guess that is what GO demands...

Can I teach "functional shell"? Frankly, no. I can get through simple shell in a semester.

[ravi-delia]

I mean, yeah? As much as I hate to admit it (and believe me, I hate to admit it), PowerShell is better than bash at composing tools made by all sorts of people on the fly in easy to write pipelines. I have my issues with it as a language, but it's not like I'm thrilled to write bash. Nushell is an attempt at making a scripting language which builds on bash, rather than supplanting it. PowerShell is much less nice on Linux, especially when you'd have to translate every existing resource.

[sedatk]

Yeah, PowerShell eliminated the output parsing overhead which was the significant portion of any composed shell operation. That's where all shells need to be heading I believe.

[vips7L]

Probably better to write this with the standard alias's so people don't complain about verbosity:

  gc ./something.yml | ConvertFrom-Yaml | ConvertTo-Json > /some/file.json

Also I don't think ConvertFrom-Yaml actually exists as a standard cmdlet.

[ac130kz]

Powershell is also quite anti-semantic, non-portable and verbose

[delta_p_delta_x]

> anti-semantic

Why?

> non-portable

PowerShell 6 and later run on Windows, macOS, and Linux.

> verbose

This is by design.

[ac130kz]

>Why?

Case insensitive, weird parameter passing, no Posix-like interface.

>Windows, macOS, and Linux

Yet it is still mostly suitable for Windows, where it makes sense with weird (read: mostly bad and outdated) platform-wide proprietary decisions.

>This is by design

Well, humans should not spend too much focus on verbosity, maybe I'm wrong, at least that's what I've learnt from a university HCI course.

[vips7L]

> Case insensitive, weird parameter passing, no Posix-like interface

Parameters are passed like any other shell?

> Well, humans should not spend too much focus on verbosity, maybe I'm wrong, at least that's what I've learnt from a university HCI course.

While its by design everything comes aliased and arguments are fuzzy matched. As a human you don't need to spend time on verbosity if you don't want to.

For example:

   Remove-Item $directory -Recurse -Force

   rm $directory -r -fo

[rprospero]

> > anti-semantic > Why? I can't speak to the other poster, but I found the PowerShell example to misleading because it required the presence of a variable that the Nushell did not. I had to read through the code three times to understand:

- Whether the code was modifying some fundamental environment variable that would affect the running of other programs? - If the variable would need to be accessed after the command was run? - Why the variable was named `os_list`? This was admittedly stupidity on my part, but it wasn't event a concern with Nushell.

> > non-portable > PowerShell 6 and later run on Windows, macOS, and Linux.

PowerShell is absolutely multi-platform and that should never be held against it. However, my personal experience has been that most PowerShell guides assume that you are running Windows and will attempt to call commands not available on other platforms (e.g. OS services, other applications). Granted, scripting tutorials for Linux and OSX also assume the presence of certain services, though it's easier to search my path for `7z` than figure out whether the Get-Acme-Version command is available. Nonetheless, the issue is more of documentation than implementation.

> > verbose > This is by design

As for the verbosity, I'll fully agree that PowerShell is highly verbose by design. However, that's a design decision that makes it inappropriate for some applications. An aircraft carrier is larger than a kayak "by design", but that doesn't make it any easier to strap to the top of your car.

[vips7L]

> can't speak to the other poster, but I found the PowerShell example to misleading because it required the presence of a variable that the Nushell did not.

This was just a choice of OP and also isn’t a concern in PowerShell:

  gc ./some.yml | ConvertFrom-Yaml | ConvertTo-Json > some.json

[stoplying1]

Lol so what happens if I run 'curl' in my PS6 script? Asking for a friend with PTSD.

[juki]

Assuming you have curl installed, it'll say

  curl: try 'curl --help' for more information

I assume you're thinking of the old Windows PowerShell that used to have curl/wget aliased to it's own commands, but that's not the case with the new cross-platform PowerShell.

[majkinetor]

Its not verbose. Its just that people that use it like to share verbose stuff as it is more helpful to others.

[jdmichal]

When I'm using PowerShell as a shell, I use all the aliases and shortcuts.

When I'm using PowerShell as a scripting environment, I use the full name for every command and parameter, and even include the names of positional parameters.

I love that it can do both.