🌞 [Other]: Opinion about 2.0.2

[LazyRichard]

Description

First of all, I really appreciate the review of my MR.

However, I think the change in 2.0.2 makes no sense.

The purpose of this #4 was not to base64 encode each element of the array one by one.

As you know, when using the Get-Content function and a pipe, the file is parsed and piped with string array based on NewLine.

That's why I needed array support and I wanted to encode them as a single base64. because this is how linux base64 utility works.

If you need line-by-line results, I think it's better to just use a powershell loop.

Let's assume we have a file like the one below. The file is named test.txt.

hello some world!

here is my decoded content

Using the Linux base64 utility, we can get a single encoded string from this file

$ cat test.txt | base64
aGVsbG8gc29tZSB3b3JsZCEKCmhlcmUgaXMgbXkgZGVjb2RlZCBjb250ZW50Cg==

This is how it should be encoded

But with your utility it is output as an array

I wanted a single base64 encoding of the file output.

Please take a look at #4 test code again.

Thanks.

[MariusStorhaug]

So think its just different ways the tools work, i.e. bash and pwsh.
Pwsh works with objects, and commands and ways you define objects matter.

I think its correct that the function should just take a string or an array of strings and do the same things for all of these, and instead use the ecosystem to achieve the output you want.

When you use Get-Content, as you say, you get an array of strings, line by line of the file. When this is piped to the Convert-Base64 it will take line by line as you have seen. But if you tell Get-Content to actually get the content as a single string (using the -Raw parameter) then the results are as you expect.

Can also be examplified with a here-string in powershell.

@'
hello some world!

here is my decoded content

'@ | ConvertTo-Base64
# OUTPUT:
# aGVsbG8gc29tZSB3b3JsZCEKCmhlcmUgaXMgbXkgZGVjb2RlZCBjb250ZW50Cg==

You could use the pipeline to aggregate, and you can use it to process a list, but in this case I think using the strengths of the eco-system as is might be better. Else, it would be like the Copilot PR suggests, using a parameter to specify this new behavior, but not sure I agree to do it. :/

Any thoughts from your end?

[LazyRichard]

I agree with some of it and disagree with some of it.

The difference between powershell and other shells is why I wrote that MR in the first place.

Other shells just deal with strings, so there's no need to have this debate in the first place.

As you said

Get-Content -Raw file.txt | ConvertTo-Base64 would certainly work as intended, but I don't think that's powershell-like syntax.

If you're writing a function that reads a file and writes it elsewhere (which in most cases is copying, of course), you might want to write

• Get-Content file.txt | Out-File -FilePath some-other.txt

I'd only use this in special cases (like if I had a NewLine problem).

• Get-Content -Raw file.txt | Out-File -FilePath some-other.txt

And if you want to process each line by line, you can use

• Get-Content file.txt | ForEach-Object { ConvertTo-Base64 -String $_ }

I think this is more powershell-like syntax.

Like you said, most powershell cmdlets are designed to handle objects.

So in my opinion

• Get-Content file.txt | ConvertTo-Base64 is more natural than
• Get-Content -Raw file.txt | ConvertTo-Base64

For example, Out-File is supposed to take an InputObject.

@('123', '456') | Out-File -FilePath test.txt

and, obviously, the content of test.txt file is

123
456

And I don't think this is the same as aggregation as you said.

Furthermore, it's weird to go further and get additional parameters as copilot suggested.

Conclusion is

• ConvertTo-Base64 should be able to handle both simple strings and the result of Get-Content.
• I think it's strange that a separate parameter is added for this.
• It would be more natural if the parameter was an InputObject type instead of a string.

[MariusStorhaug]

You are welcome to have your own opinion!

However, I am not going to implement this way of aggregating strings from an array as the default behavior for these functions at this time. The object type that this function takes is designed to be single strings. Pipelining after 2.0.2 works as intended, processing item by item as its passed from the pipeline to the functions, sending the output to the pipeline as its processed the item.