Cli-microsoft365: Support pipe into commands

[baywet]

Let's assume somebody wants to write the following command spo site list | spo app install (imagine some filters in the site collection selection and an app id provided).
Today that's not possible because commands don't support pipe input.
More context https://github.com/pnp/office365-cli/pull/624#issuecomment-426727846

[waldekmastykarz]

I can have a look to see what's possible in vorpal, the engine behind the CLI. Meanwhile, how would we decide what could be passed through the pipe? For the spo app install command you mentioned above, it could be just as convenient to pass the list of sites or the list of apps.

[baywet]

As far as I remember from my PowerShell cmdlet development, the way it's done in PS is you handle it through declaring the types that can be piped in and testing the type when you get something. You can also declare associations between parameters and piped types so if I'm piping a bunch of site collections, the site parameter is disabled (for auto-completion/availability).

[baywet]

I'm not sure how vorpal works but it'd be cool to have a similar behavior if we could

[waldekmastykarz]

That's true, but if I'm not mistaken, everything that's coming through a pipe in Bash is a string. If we have distinct input types such as id (guid) and site URL then detecting the type of input parameter could just work. Either way, it's something that we could decide per command. Good idea 👍 I'll have a look at what's possible.

[waldekmastykarz]

I had a look at it and indeed, bash doesn't have the notion of objects. Instead, what you get is a string. So if you wanted to pipe the output of one CLI command to another, using the JSON output would be the way to go. From the CLI point of view, the underlying tech supports it, so we'd need to implement the base support for processing stdin and then handle it on a per-command basis.

We can keep this issue open for adding the base support in the CLI and then open a new issue for each command where we want to add support for accepting pipe input, detailing what inputs are valid. How does that sound @baywet?

[baywet]

I think that's a good plan. To keep the type information maybe we could leverage the odata type property? Add it when serializing for pipe output and then read it on the input to determine what we're getting?

[waldekmastykarz]

Very nice suggestion! It would work perfectly when chaining multiple CLI commands together. I wonder if we could extend the identity (talking in PowerShell terms 😉) to support single properties like URL or GUID as well. This would be helpful in cases where you want to pipe a list of URLs or IDs which aren't complete odata objects and don't have a type designation.

[waldekmastykarz]

@andrewconnell and I had a discussion about this lately and we couldn't find examples of other CLIs doing this. It seems like such behavior (piping complex output of one command to another) is something specific to PowerShell. CLIs are typically used in scripts where the values are assigned to and passed via variables. So while adding support for piping could be done, it might be confusing for folks who are used to working with CLIs. I'm inclined to reconsider adding this to the CLI and keep using scripts for more complex scenarios

[andrewconnell]

Piping isn't something you do with CLI's... that's a POSH concept. If you want to pipe, use POSH, but POSH-ifying a CLI isn't the right approach for the target audience.

What you're describing is done using a bash script, not by introducing support for piping with the CLI.

I fully acknowledge some bash commands support limited piping, but this opens up a can of worms.

[baywet]

From what I remember if the ages before powershell (and yes I was young so memories might be blurry) one of the big advantages of bash over the windows command prompt was it's much better pipe support and tooling around it (see, grep...).
Now I might be mistaking but I can see a "bash aficionado" having a file full of site urls or something similar, greping it and then piping that into one of the commands. Or is it unrealistic?
Now I understand piping in bash doesn't support complex types and I agree that we should not over complicate the cli if the underlying infrastructure doesn't support what we're trying to achieve. I also think we should support "basic bash piping" in the cli for the reasons I exposed and leave the responsability to the user of inputting the right format. (Helped with done documentation)
What do you think?

[waldekmastykarz]

Looking at your original example spo site list | spo app install, that wouldn't work, even in PowerShell, because you'd need to pass each list separately rather than a list of lists.

Where it would make perfect sense I think is for things like JSON theme file or certificate contents, or contents of a script to set on a custom action, where you want the whole large string to be passed as-is without processing it. Passing such values through arguments is tricky because of quotes that need to be escaped just right depending on the shell you use.

@andrewconnell?

[andrewconnell]

My thoughts don't change; I'm not convinced this is a wise thing to do when there are existing solutions.

Potential benefits don't outweigh complexity added to the codebase IMHO.

[waldekmastykarz]

Even for things like JSON files of JS scripts?

[baywet]

@waldekmastykarz to reply to your comment around the sample command I provided, yes in PS I'd have to use a % {$_ } syntax (a foreach basically). The equivalent syntax in bash looks much more verbose and from my readings people tend to use scripts then when they want to do something like that as AC mentioned.
So yeah maybe we could start with trivial ones, like the files and see from there?

[waldekmastykarz]

If I look at the amount of trouble quotes are causing, it would be helpful if we could alleviate it.

[waldekmastykarz]

Closing this for now as we don't have a specific use case for implementation. Let's revisit in the future if need be.