> It's a bit sad that [we're parsing output] ... generated by a 6000-line C program[2] ...
> That's something I miss from Windows, at least PowerShell has built-in commands that give you structured output.
It sure is something to disparagingly point to the LoC of 'ss' in one sentence, then pine for both PowerShell and the Windows infrastructure that supports it in the next.
You mentioned processing the output with regexes. That's definitely a code smell, but this is one line of the data from the 'ss' command in question, with fancily-aligned header line included, but with vast tracts of whitespace removed. The regex you pointed out is processing the column whose comma-separated data is enclosed in parens:
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
tcp LISTEN 0 666 [::]:22 [::]:* users:(("sshd",pid=1337,fd=7)) ino:1338 sk:2024 cgroup:/openrc.sshd v6only:1 <->
They definitely didn't have to use a regex to process that, but chose to.
You could argue that a system that let you write client code that goes something like
is superior to one that requires writing something that makes use of the moral equivalent of 'cut'. I'd argue two things, one of them informed by my professional experience with PowerShell
1) What happens when the "structured" data you rely on changes shape? When that system that produces that "structured" data changes 'users' to 'user_list', 'cmd' to 'local_command', or deletes 'process' and moves 'users' up into its place, you're just as screwed as if 'ss' changed its output format in a way that wasn't backwards-compatible.
2) The core Microsoft tools might all produce "structured" data, but -in my professional experience- so, very, very little "community-provided" PowerShell code does. Why? I don't know for sure, but probably because it's notably more difficult to make a script or library produce that sort of data than it is to just emit regularly-formatted text.
The problem of data changing shape can happen regardless, but with text you have the added danger of escaping characters and ambiguities. Not to mention there are ad-hoc text formats for each and every tool, which can change from one version to another.
And you're right, PowerShell is far from perfect. I miss some of its design goals, not the whole thing.
> That's something I miss from Windows, at least PowerShell has built-in commands that give you structured output.
It sure is something to disparagingly point to the LoC of 'ss' in one sentence, then pine for both PowerShell and the Windows infrastructure that supports it in the next.
You mentioned processing the output with regexes. That's definitely a code smell, but this is one line of the data from the 'ss' command in question, with fancily-aligned header line included, but with vast tracts of whitespace removed. The regex you pointed out is processing the column whose comma-separated data is enclosed in parens:
They definitely didn't have to use a regex to process that, but chose to.You could argue that a system that let you write client code that goes something like
is superior to one that requires writing something that makes use of the moral equivalent of 'cut'. I'd argue two things, one of them informed by my professional experience with PowerShell1) What happens when the "structured" data you rely on changes shape? When that system that produces that "structured" data changes 'users' to 'user_list', 'cmd' to 'local_command', or deletes 'process' and moves 'users' up into its place, you're just as screwed as if 'ss' changed its output format in a way that wasn't backwards-compatible.
2) The core Microsoft tools might all produce "structured" data, but -in my professional experience- so, very, very little "community-provided" PowerShell code does. Why? I don't know for sure, but probably because it's notably more difficult to make a script or library produce that sort of data than it is to just emit regularly-formatted text.