In summary:
I need to pull data from a company we're partnered with, and get it into our systems. They ship it as SQL Server backup files. OK, no big deal, we can mount those up and run queries to dump stuff out to whatever format we like and ingest it.
Except part of that data is files, which were stored in the DB as binary blobs (in a table along with filenames and metadata). Need to get those out of there and into our storage as real files. OK, no big deal, I can just query for filename and file contents, dump out onto disk and then batch-transfer into our archival storage, right?
Except no matter what kind of obvious shell-idiom method I try to use, it doesn't work because PowerShell stubbornly insists that I must be working with text data when I'm using all those handy shell constructs, and so the files end up corrupt.
So now instead of just being able to shove data through pipes like I would on Unix (which, for all its faults, doesn't really care whether I'm sending binary or text data), I have to have my script go and instantiate objects for creating a file and reading and writing binary streams, and remember to clean up after them, and my script ends up way more complicated.
What would have been a pretty simple script anywhere else now has to know a bunch of .NET libraries and how to create and work with their types, and that's less useful to me.
Invoke-Sqlcmd -Query "SELECT ..." and write it out to a file?
or avoid it and just use BCP "select blah" queryout "c:\file.jpg" etc etc ip addr show | grep inet
Edit: wrote back original command and replied below instead [kapil@localhost ~]$ ip addr show | grep inet
inet 127.0.0.1/8 scope host lo
inet6 ::1/128 scope host
inet 192.168.128.236/24 brd 192.168.128.255 scope global dynamic eth0
inet6 fe80::215:5dff:fe80:501/64 scope link
[kapil@localhost ~]$ ip addr | grep "inet " | cut -f 3 -d " " [kapil@localhost ~]$ ip addr | grep "inet " | tr -s " " | cut -f 3 -d " "
127.0.0.1/8
192.168.128.236/24
[kapil@localhost ~]$
To be honest, I don't consider this to be that bad, I was just replying to a person who thought that bash was "simple", and powershell was "complex". Also, I don't have a problem with either tool. I'm very open to the idea that Microsoft can and does create awesome tech, despite having other shitty products. [kapil@localhost ~]$ ip addr | awk '/inet / { print $2 }'
127.0.0.1/8
192.168.128.236/24
[kapil@localhost ~]$
You guys are just proving my point. _I_ already know how to do it using bash. Its just that using objects and querying properties is far simpler. And I just took a random example because its a common thing that someone would want to do.I think the idea of an object pipeline is sound for precisely this reason, but I don't think it should be connected to any one language or platform.
I can only use this feature by using a .NET language. I can't take the strongly typed objects into a Node.js script, or a perl script.
It goes without saying that a binary interface requires use of a system that understands that particular binary interface. With .NET being open source though, anyone is free to write a bridge to using the objects in COBOL if they wanted to.
>I can't take the strongly typed objects into a Node.js script, or a perl script.
Yes, because they have no concept of strongly typed objects. You can convert objects to strings if you're using an incompatible tool/language. I don't know what your point is. Sorry..
Virtually any language can already input and output text. That's the real lingua franca of computing (even if it is messy and dirty), not .Net objects...
The difference between impossible and possible is important. Please read what I was replying to. Using your argument, Anytime a project is open sourced, you could reply with "who cares about potential since nobody has actually done anything with the source". Good job.
>Virtually any language can already input and output text.
Um, you seemed to have missed the obvious point that objects can also be converted to text through powershell if the other side can only accept text. So, I don't quite know what you're complaining about. Could you detail your actual technical complaints with powershell, rather than having a philosophical argument?
>That's the real lingua franca of computing (even if it is messy and dirty), not .Net objects...
I don't agree with your opinion, nor with the idea that only a two-choice system can exist.
But it's not bash, it's coreutils
find ./ -mtime +2 | xargs rm Get-ChildItem -File | Where-Object LastWriteTime -lt (Get-Date).AddDays(-2) | Remove-Item
If you prefer shorter (and similarly obscure if you don't know the language): ls -file|? LastWriteTime -lt ((date)+'-2')|rm
I actually find PowerShell's version more readable, even if more verbose. But code is written only once and read a lot of times. I may not know what the +2 actually means with the -mtime argument. How would I change it to look for the age of two hours instead of days?Sorry, I can't agree with you.
> I may not know what the +2 actually means with the -mtime argument. How would I change it to look for the age of two hours instead of days?
If you forget or doesn't know what is mtime, you can open man find. For less granularity than days use mmin.
/Mapped-Temp-folders/Server-Asia/temp
/Server-UK/temp
/Server-Japan/temp
I guess the script wouldn't work then if you wanted to clean out data older than 2 days, as per their timezone.
For a developer writing a tool, exposing an interface as objects is far easier than having to constantly serialize data into a string. Keep in mind that once you serialize data into a string, you can never change the order of the data or else other tools will break. Not so with a object based interface.
In other system-admin type tasks PowerShell hides complexity. For e.g. finding the IP address of a network interface is simply
compared to something horrendous like