Re: Like grep? sed? awk?
>>"While you may find xargs to be difficult to understand"
What did I ever do that indicated I was having difficulty understanding xargs. I said that this:
find . -print0 | xargs -0 stat -c "%U"
was less intuitive than this:
DIR -Recurse | Get-Acl | Select-Object Owner
That isn't me having trouble understanding xargs, it's me making a correct statement. I replied to someone who criticized Powershell for having unmemorable names and inconsistent output. And you took up their cause. You're honestly trying to make the case that to someone new to both systems, your example has easier to remember names and that unstructured text that varies from command to command is more consistent than a consistent array of objects? Please drop all the snide little comments about what I am and am not familiar with. I have been using UNIX and then GNU/Linux for around fifteen years. And that's really your problem - you're trying to argue the case with someone who is familiar with BOTH and can therefore make informed comparisons. Whilst you appear to have little familiarity with Powershell. That's fair to ask, isn't it? You don't have much familiarity with Powershell, do you?
>>"Yes stat has a lot of formatting options, but the alternative would be dozens of individual commands which I would have to remember which still wouldn't be able to as much."
Well, no. The alternative would be that it returns an object and allows the caller to decide what to do with that. Why do find, ls, stat, printf all have their own and different formatting options? Doesn't it make a great deal more sense to have all your different commands pipe an object to the same formatting tool and thus be more consistent and flexible? Basically, do one thing and do it well. Not create a drawer-full of swiss army knives.
>>"And let's be honest here, "Get-Acl" also has loads of parameters to choose from. It's inherent to the problem domain"
Then you're missing the point. It's not about how many parameters Get-Acl has, it's that all of them apply to what it's actually designed for and none of them are for text-mangling to fudge its ability to pass on its results to the next item in the pipeline. You had to use xargs to effectively build a new command line because stat wont accept the output of the previous command directly. And you had to alter that previous command based on knowing that the next command wouldn't be able to handle its output. You had to add a special switch so that it would terminate elements with a null rather than whitespace, purely because you knew the next command wanted it that way. And if you changed the next command in the sequence you might have to set a different flag. Whereas whilst Get-Acl has a number of parameters, none of them are to do with trying to get it to talk to another command via text mangling. It has only what it needs to do its job. That is what makes it simpler.
>>"The advantage of using a formatting string is that I can do more than just things like "%U". I can combine the codes (more than 2 dozen just for files, plus more for devices) in multiple ways, and even include arbitrary text in the output"
Text is a subset of objects. You can do all the same with cmdlets in Powershell so your:
"stat -c "%U some random stuff %a" *"
becomes
Get-Acl * | %{Write-Output "$_.Owner some random stuff $_.Group"}
It's not particularly complicated. The chief differences are (a) that rather than remember special switches that are specific to the stat command (such as %a being octal permissions), you just refer to the actual properties of the object; and (b), you're piping to a dedicated formatting command that is consistent between all programs that you choose to use it with.
>>I might be piping this output directly into a report which is to be read by someone rather than using it as input to more system administration scripts
All the more reason to have that separation between formatting and the tool itself, then. Instead of the string I used above, you could just as well pipe the output of Get-Acl to Format-Table, ConvertTo-Csv or whatever else you wished. I wouldn't have to change anything about the Get-Acl command. Remember we're dealing with very simple examples here. If one person had written a powershell script that returned a specific array of file objects according to some criteria, I would want to just pipe the output to my own formatting choice, not worry about what data they included as part of its textual output.
Basically, it's that consistency of outputs that we keep coming back to. Unstructured text simply doesn't have that.
>>To be honest, I would have to dig through a lot of documentation and examples to even figure out how your bash example even works. Yes I can see that you are chopping up the output of "ls", but you are doing it in ways that I've never seen, let alone tried.
The output of ls -l is in the format
-rwxrwxrwx number_of_links owner group bytes last_updated filename
awk '{print $3}' gets the third column of the textual output, which is owner.
To be honest, given that you are arguing so much for the superiority of Bash, I'm surprised you're not more familiar with awk.
>>"The problem with your example is that you are comparing apples to oranges."
No, I'm not. I'm comparing two solutions for achieving exactly the same thing.
>>In your MS PowerShell example you are using the standard command for getting file information and processing the output of that, but in your bash example you used a command which was not intended for that instead of using the correct one, which is "stat".
Nope, I happily switched to the one you asked me to use when you proposed it, and have been using it as my basis for comparison ever since. As you can see from my posts. The only reason I used the one I did originally was because I actually think it is clearer to read and thus actually fairer to the Bash case. But it doesn't matter - the instant that you said it would be better a different way, I resumed my argument in every post since using your own one that you were happy with.
>>>I've hit the maximum post length so I'm carrying on my reply in the next post.