Hacker News Reader

Comment by amenod | Hacker News Reader

Is this really so useful in practice? I have never used PowerShell before (nor do I have plans to do so in the near future), but I would imagine the downside is complexity, both for user and especially for developers. With text you just read and parse, while with objects you need to know the object type, its fields,... Whatever happend, I hope text stays here (and I have a bad feeling about it ever since I met systemd).

View on HN

Could you elaborate on what the actual complexity is, rather than what you imagine?

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

  Get-NetIPAddress | select IPAddress

compared to something horrendous like

  ifconfig | perl -nle 's/dr:(\S+)/print $1/e'

What about:

    ip addr show | grep inet

Edit: wrote back original command and replied below instead

That doesn't work on my CentOS box.

  [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 ~]$

Correction then:

    ip addr | grep "inet " | cut -f 3 -d " "

It still doesn't work (you forgot to add the tr back in your reply after your edit)

  [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.

Thanks, too many edits indeed!

Nice way to prove the point that object based is far more reliable than text based.

ip addr | awk '/inet / { print $2 }'

That doesn't work either.

  [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.

You really couldn't have asked for a better chain to demonstrate the validity of your point. Having been blinded by my own world view and biases in the past I sympathize with them but this is too funny not to have a little laugh at their expense.

I think what others might be demonstrated is that there isn't a reliance on what object Microsoft decides to ship to you, in *nix we can combine commands and builtins and get the information in the structure we need without having to wait 8 months for a system reboot (or worse a paid for upgrade) that will give us what we need.

Well, to be fair, what was demonstrated here was that people didn't actually extract the data after multiple edits and tries, regardless of what tools they had at their disposal.

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.

First of all you are incorrect in your assumptions. You are reliant on the author of the tool in both cases. Just as there is no "UNIX Person" who decrees that all executables on UNIX must output text, there are vendors other than Microsoft who write software for Windows. You can write one too, it takes about 5 minutes to expose a powershell interface. And I'm not even a .NET developer. I write embedded software for a living.

But once again, you're simply scraping text, instead of querying an object for properties.

It is parsing text, but that text does have some consistent structure. Contained within it are properties. One can make the same comment of reading JSON or XML but I'll admit those are more like what you'd choose for an API. In general there is a not-entirely-obvious (to me) question of where does "formatted for machines" end, and "formatted for humans" begin? We can't say "it's for machines if and only if it must conform a schema that's defined in advance", not any more.

You would have to be aware of that fact in order to write the command. The question is about relative advantage, not about what the tools do.

> Could you elaborate on what the actual complexity is, rather than what you imagine?

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.

>I can only use this feature by using a .NET language.

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..

I guess the point is the point. Potential bridges that do not exist already and probably never will do not matter -- extending that idea of potentiality I could say that you are free to reimplement the CLR in Fortran, so PowerShell is compatible with Fortran? Oups sorry you already reached that ridiculous point, only with Cobol.

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...

>Potential bridges that do not exist already and probably never will do not matter

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.

The point is that this thing is less valuable by being limited to only being used by things that Microsoft created (in reality). Text, with all of its flaws, can be used by everything.

That's not really true, you can serialize as json in all of those

As someone who recently got his first exposure to PowerShell, I'll chime in that the case I needed to deal with was one where it added complexity.

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.

Its true that powershell being a new tech probably doesn't have the large library of "known ways" to do things that the UNIX world has. And BTW I'm not even a powershell person. I write embedded software in C++ for a living ! Having said that, I'd imagine you would parameterize something like

  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

I just now have the chance to use Powershell on Linux, with that Powershell command you demonstrated, I get a command not found.

And how to delete files older 2 days? Get-Files / | select olderThan 2 | Delete-File ?

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?

> I actually find PowerShell's version more readable, even if more verbose.

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.

    ls|? LastWriteTime -lt (date).AddDays(-2)|rm

Just as an aside (and this probably applies to powershell as well), what if you have mapped folders from multiple servers into your file system and those servers are in different timezones? Something like

  /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.

> With text you just read and parse, while with objects you need to know the object type, its fields

parsing is actually a huge pain in general. a lot of unixy tools produce different output when their stdout is not a terminal to be more pipeline-friendly. That output is generally easier to parse (often tab-separated or so), but you still need to know the same things about the output (the "type" could be whether it came from `ps` or from `ls`, and the fields are just in some static order that was usually chosen decades ago, and if it's extensible it's cumbersome).

If `ps`, `ls`, etc produced typed output, I would be sooo happy.

When I worked at google I thought about what it would be like to have a unix userland where all the parts communicate with protobufs instead of raw text. There are some problems (like portability of message definitions, which was a solved problem within google, but which is harder when you have multiple parties/entities/companies contributing message definitions).

edit: accidentally a word

I wrote a bash script to sort processes by age on an old redhat 4 machine.

What sounded like a very simple thing, quickly ended up being a complete nightmare of bash, python, and an unholy bunch of linux commands.

It was ugly, and a terrible way of doing it, but we got it working.

It would have been amazing if i could pipe PS into something that could sort by the dates on the 4th column, and return the last column in the sorted order.

You could probably hack something together with awk, but this sort of thing is exactly why I like powershell a lot.

Yeah i ended up using awk, some python for the date parsing and sorting, back to bash for grep and another thing i can't remember, then into the program that actually needed the data.

It was a mess, and I remember thinking it would be such a simple thing that was so much more complicated than i thought it would be.

It's entirely possible this is a recent development, but "ps -o cmd --sort etime" seems to do what you're asking for.

sadly that wasn't available, and researching an easier way to do it without that was met with pages and pages of people saying to do that...

There's literally an example in 'man ps' that does exactly this. It's right there in the output formatting section.

    ps kstart_time -ef

Pretty sure the section in the `ps` man page called OBSOLETE SORT KEYS indicates that even the `ps` on very old redhat machines could do this out of box... see the field `start_time`.

Failing that, consider the `etimes` field (seconds since process was started) used in conjunction with the -o feature (control output format) so you can put `etimes` up front then simple pipe the output to `sort`.

Those things being said, the situation you describe is indeed hairy. `ps` output was designed for human consumption, that's why the process age field format varies (1w vs 10:15) and that's presumably why you wanted to bring python into the mix!

...You might have had an easier time looking in /proc...

Indeed, this looks promising:

    cat /proc/[0-9]*/stat|sort -n|less -S

EDIT: hm, I don't know how old /proc is!

EDIT #2: But try doing ANY of this on an ancient Windows machine! The "peer" of your old Redhat machine would be what, a Win2k3 machine, or a Win2k? How old is PowerShell? :)

Honestly it was a quick and dirty one-time project, and I just needed to cobble something together.

I was more just commenting on the fact that with a "strongly-typed" shell some of this stuff becomes much easier without every single tool needing to add all these options.

It gets much more "Unix Philosophy" when every command doesn't need it's own sorting logic, and doesn't need it's own date display logic, and doesn't need it's own way of displaying it to the user.

It can output an object, which can be piped into another program to use what it needs which can be piped to something else to do some sorting which can pipe it out to another to display it in a nice table.

I hear you. I myself was impressed by some things PowerShell can do easily.

But let's not throw out the baby with the bathwater... The unix shell ecosystem is powerful magic. There are LOTS of things that can be done there with great ease.

Not to mention--and I understand full well that this stance is falling out of fashion--MICROSOFT ... KILLED... my PAPPY! :|

PowerShell was released after Win2k3, however you could install it on Win2k3/XP, even PowerShell 2 afterwards: https://support.microsoft.com/en-us/kb/968929

I find it massively useful in practice, even for mundane tasks.

For example, the other day I was trying to search the columns of a very large SQL Server table¹ but also needed information about the column type.

  …\dbo.site> ls Columns | select Name, DataType, {$_.Properties['Length'].Value} | where {$_.Name -like '*int*'}

  Name            DataType $_.Properties['Length'].Value
  ----            -------- -----------------------------
  internal_end    datetime                             8
  internal_start  datetime                             8
  interval_code   varchar                              5
  prod_intv_start int                                  4
  prod_intv_stop  int                                  4
  working_int     decimal                              5

Quick, easy. In a *nix shell that would be very tricky.

¹ SQL Server installs a Powershell extension so that you can essentially treat databases like a fancy object filesystem. It's wicked cool actually.

> Quick, easy. In a *nix shell that would be very tricky.

You'd probably need to make an explicit SQL query since you wouldn't have the database integration.

Well, yeah, but I mean the concept (grepping in tabular data).

If, hypothetically, bash had database integration, ls Columns would probably return something like

  foo	varchar	30	NOT NULL
  bar	decimal	 8
  baz	int	 4

Which would be a royal PITA to search for anything in—if I were to search for ‘int’ I'd get all int columns and any columns with int in the name….

I could've used an example involving process lists, but I didn't want to trigger PTSD in anyone who's had to grep the output of ‘ps’ for anything non-trivial. (Plus, the database thing was something I actually did a few days ago.)

But thats why there are tools like awk.

awk is rather similar in many ways to powershell, actually, but untyped. I agree most of what powershell does you can do with awk, but it's often less pleasant than powershell (in my experience).

ps aggregates /proc info for human viewing. Why grep the formatted output rather than the source data?

Maybe on Linux. OpenBSD doesn't even have procfs, FreeBSD deprecated it, DragonFlyBSD doesn't mount it by default.

/proc is a race condition waiting to happen, so I can't really say I recommend using that.

How would that be hard in a *nix shell?

    mysql > SELECT  column_name, data_type, numeric_precision FROM information_schema.columns WHERE table_schema = ? AND table_name = ? AND column_name LIKE "%int%"

Imagine for a second that the DB can't do it and you need to filter the STDOUT output.

Okay, I've imagined it. It does seem terrible.

Fortunately, that's not a world any of us live in.

OK, but now imagine it's not a database, because there are programs that do act this way.

And those programs usually emit proper CSV. You could use regex to match on what you want, but AWK was literally built for this. It's fantastic, it works great, and if you don't use that tool that was built to solve your problem, that's your own lookout.

I don't think awk is actually capable of parsing CSVs in all cases.

It doesn't parse escapes, IIRC, but those are rarely emitted.

Er, it's a world all of us live in. Say, for example, ‘ps’ or ‘ls -1l’.

Then you end up using awk, which is rather like a half-assed version of powershell to work around shortcomings with the unix everything-is-a-string design.

Parent comment was talking about parsing the raw output from a database in stdout. That's what I was responding to, and I'm not wrong.

AWK isn't a workaround. It's a tool for processing tabular data, in a textual format. The fact that it can solve so many problems is actually a strength of the EIAS design.

That doesn't sound hard at all. AWK, anyone?

Writing awk to do it is definitely more work than calling obj.Property though.

  $mysql_cmd|awk -F\| '$2 == "what you want the second row to match" {print $0}'

Not that much more work. And you can do better if you can coax mysql to emit proper DSV.

That kind of stuff adds up fast in an interactive shell.

...Which is why you write a script to do it if it comes up often.

Extendable tooling!

The reason I chose that particular example was not for the database integration (which is very cool) but for the fact that it's actually something I did.

Point is, imagine trying to grep anything tabular in bash. Hypothetically, the output of ls -la for files with execute permission that have been modified in the last day. Or, more realistically, anything involving ps.

Imagine trying? Sir/Ma'am, I have done so.

When boxed in-between the fearsome foursome--`bash`, `sed`, `awk`, and `emacs`--every problem involving tabular data (2D) is trivial. Hm, I'll give a shout-out to `sort` and `uniq`, too! When you go 3D, you might need to bring in `join`.

But anyway, you'd use

    find ~/bin /usr/bin -mtime 1 -executable -type f -ls

..to provide `ls -la` output for every executable, ordinary files (not directories, which are often +x) modified in the last 24 hours, under the directories /usr/bin or the bin/ under your home directory.

Hey, don't forget cut and xargs!

    *gulp* I've heard people say that, but I haven't delved into them!!  :-S

cut doesn't match awk, but it's handy for the little stuff. And xargs is the most usefull thing ever.

And paste for tasks requiring the opposite of cut, then there's tr, the lightweight sed. And jq for structured queries on JSON. But, all these are built in to poweshell, essentially.

No they're not. PS can't process text all that well...

Most users do not find awk trivial. Most people basically use it for {print $colnum} when simple columns are available.

PowerShell's integrated query syntax that you can patch into various things is a lot more consistent and reasonable. It is difficult to imagine volunteering people into a world of awk, sed and cut with good intentions in one's heart.

I didn't call awk trivial, I meant to say that the prudent application of powerful tools makes quick work of otherwise intractable problems.

Forgive my being frank, please, but I think that given the context of this conversation, it's appropriate: Most users don't HAVE non-trivial problems!

There aren't features in sed nor awk, nor regular expressions in general that weren't put there for some specific reason in the past.

When you wield your shell, well, you wield a tool honed through the ages by people who think like you! Do so with pride! :)

I have no time for tool worship, language worship, and other sentiment like that. These are tools, not people. I'll use the best I can buy, borrow, or make until I see another better one comes along.

A corporation has no incentive to give you (let you keep forever) the best possible tools.

If that is true, then it is equally true of the authors of shells.

But of course, it's not true. Many great and lasting tools have been founded out of corporate work in a bid to improve mindshare and ease recruiting by increasing the esteem of corporate engineering efforts. Many of the things we think of as "open source" and "free" were built subsidized either directly or indirectly by capitalistic interest.

But I'm not concerned about keeping it. Ossifying my process so that I can give myself the luxury of time of from learning is not something I'm prepared to do, because I think it will make me soft and less capable as an engineer. I regularly rotate my editors and learn new languages because I don't want to become like the sad specters of the previous generation of software engineers I see now, starched shirts and ties and a fanatical devotion to the dated technologies they stomach in order to collect huge consulting fees from corporations.

I've switched off Fish to Powershell as my primary shell for awhile. It's interesting.

I think this speaks to the difference in mindset I've seen a lot in this thread. It basically comes down to people who have gained and honed experience with these tools vs. people that haven't. Yes, for someone with a lot of experience with these tools something like Powershell is redundant... for them.

Some people just want to get shit done because this is just a footnote in a task that's a small part of a project. Utilizing gained proficiency in several tools is cool but if you have a choice between doing that and just taking advantage of a simple tool that streamlines things and lets you move on to your next task quickly the correct choice is obvious.

It could be that these tools are better and may be more valuable in some situations but asking someone to spend time gaining proficiency or mastery when another path is available is just premature optimization.

Pretty much all databases will support "describe tablename" to do exactly that.

Objects are discoverable in powershell. Enter the object, and lists the object out as text.

Yes, this is so awesome. Can't remember the exact parameter/field? Just dump it to the console.

That what you would do with text? If you have no idea what its outputting, explore it by putting it to the console.

Sure, but with text you might have empty fields that are just omitted. With Powershell you can see that the field exists but is empty.

There's a bunch of subtle distinctions like that which don't sound impressive but end up being really nice when working with it.

What you can't do so easily with text is also just auto-convert that object directly to JSON or YAML or CSV, for that matter, and forward that easily into your favorite JSON/YAML/CSV exploration tool.

Ok, that sounds good. But what if some developer decided that some field would have prefix "ABC" in all values, then the value I am interested in, then some value I am not interested in at the end? (you say this can't happen? Clue: WMI.) Can I take the value, convert it to string, make some magic on it and convert it to another object entirely?

I don't know, I never had any problems with text parsing. I love strong types in programming languages, but in system administration I think it would only get in the way. But as I said, never tried it, so I might be missing something.

> "But what if some developer decided that some field would have prefix "ABC" in all values, then the value I am interested in, then some value I am not interested in at the end?"

I don't see why this would be a problem for PowerShell. Just use Select-String to strip away the characters you're not interested in. The advantages that derive from passing around objects aren't based on all data being automatically in the format you want.

Yep! There's a few ways to accomplish such a thing, but probably the most straight forward would be the Foreach-Object command (aliased as "%") to do a mapping from source object to something else. Free form objects/dictionaries are easy to make and consume.

Select-Object also makes it very, very easy to make new objects

There are many ways to accomplish this (in general). My favorite is that you can create 'computed' properties on the fly which means you can continue to keep the strongly typed object in the pipeline, and still have access to the data you care about.

https://technet.microsoft.com/en-us/library/ff730948.aspx

You use the exact same functions (first, last, substring, replace, etc) as you would normally. Then the rest of the pipeline has it available if needed.

I spend about half my job inside Powershell and had no idea bout this. Very cool.

The default regex functionality is absolutely terrible (maybe this can now be fixed with a PR). You'd write your own cmdlet[1]. A few things are demonstrated in the cmdlet: functions that take pipes, functions that return pipes, anonymous functions, actions to perform before processing a pipe and dynamic objects. The Powershell syntax gets ridiculed for being ugly, but it's beautifully expressive.

> Can I take the value, convert it to string, make some magic on it and convert it to another object entirely?

    Get-ChildItem *.js | Get-Content | Select-Regex 'require\("(?<Require>.*?)"\)' | Select-Object -ExpandProperty Require

In other words: find JS files | read lines | turn regex capture groups into an object (another object entirely) | select a single capture

Ultimately, Microsoft provides WMI cmdlets[2]. You'd have strong types from the get-go and wouldn't need resort to this string silliness.

[1]: https://gist.github.com/jcdickinson/cee4582448300c0d404bbff1... [2]: https://technet.microsoft.com/en-us/library/ee176860.aspx

The default regex functionality is absolutely terrible

How so?

Replicate the above without using [Regex]:: (i.e. use -matches and $matches). It forces you to radically depart from a typical Powershell mindset and approach.

I'm not certain what you're getting at; -match doesn't handle multiple matches so you can't replicate the above just with it? Yes, that's a bit annoying. You could match line by line:

    gci *.js | foreach { gc $_ | foreach { if ($_ -match ..) { $Matches...

which is ugly, but doesn't use [regex]::Matches. But you can do:

    sls 'require\("(.*?)"\)' *.js | select { $_.Matches.groups[1] }

or other variants of Select-String, depending on exactly what data you want, without departing into the .Net Framework too far.

More specifically, you can find out all of the type information about anything you get access to by piping it to 'get-member'

  get-netadapter | get-member

Which gives the following output http://pastebin.com/bM0cBeXb about the type information for the result of 'get-netadapter'. In addition to this, tab completion for properties is available.

Alternately, you can get all of the current properties of any existing object by piping to 'select' (to get a general subset) or 'select * ' to get all properties. Note that this gives all information for the objects in the pipeline.

  get-netadapter | select
  get-netadapter | select *

The first will provide a short list of fields for all network adapters, and the second will provide all properties.

'Select' can also be used to easily filter the properties of items in the pipeline to ones you care about.

  get-netadapter | select Name, MacAddress

You can also just generally filter the pipeline based on generic filters (give me all of the network adapters that are currently not enabled, and have a driver provided by Mellanox).

And ultimately, if you want to use powershell to do the stuff that typed objects are good at, and then leverage command line tools to do the rest, you can if you like.

  get-netadapter | select Name, MacAddress | exportto-csv

Which will take all of the network adapters, gather their name and mac address, and spit it out to stdout as CSV which can then be sent to any number of external tools, or using the '-expandproperty' flag to 'select' can give just a bare list of properties one on each line.

Yes, it's quite useful in practice, because the alternative is knowing exactly the format of text some command is going to produce and munging it, which is hardly better

It's nice when it works, but it's a pain to write a command-line utility that outputs into objects. Whereas in Unix, everything automatically outputs into text, so you have to work hard to prevent it from being chainable to the system.

There are also details of Powershell that are very annoying, such as the lack of < redirect, and the difficulties it has on binary output sometimes.

difficulties with jumping through hoops to consume and produce binary output are really the only "problem" I've had with powershell

Pipe anything to Get-Member. For example:

(ls)[0] | gm

will list every field and its type on a File object. Wicked easy.

You can even just do

    ls|gm

and get the lists for both FileInfo and DirectoryInfo. There will be no duplicate types listed because Get-Member already sees to that there won't.

It's not about complexity; it's about robustness, and avoiding insane hacks like this:

    REASON=$(echo "$line"|tr ' ' '\n'|grep reason= |cut -d= -f2)

I've done some Powershell work in my brief time as a Windows sys-admin. I personally struggled with it. The object interaction can be complex and the naming feels less scriptable and more directly out of the C# world.

That being said, I can see the appeal and I know people who love it. I have seen some amazing shit written in it, like this security tool that was just open sourced this year:

https://github.com/adaptivethreat/bloodhound

I have used Mono/GTK# for years on Linux and prefer it over other GTK wrappers. Powershell might be worth a try on Linux, but it will take time to build up the libraries and wrapper needed to interface with most of the Linux subsystems (unless Microsoft as ported a lot of useful stuff in this initial release).

People don't (or shouldn't) use bash/zsh/fish for really complicated stuff anyway. I have a feeling most sys admins/devops people will continue to use Python/Ruby for complicated tasks; and they both have a ton of libraries that help avoid the stdin/out/parsing situation you have with chaining together regular shell scripts.

Python and ruby for the big stuff, bash and the Holy Trinity (sed, grep, and find) for the small stuff. AWK for anything in between.

You can just use the Mono bindings for the Linux-specific API's, I hope.

Reply on news.ycombinator.com