mysql > SELECT column_name, data_type, numeric_precision FROM information_schema.columns WHERE table_schema = ? AND table_name = ? AND column_name LIKE "%int%"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.
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.:)
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.
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! :)
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.
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.
*gulp* I've heard people say that, but I haven't delved into them!! :-S $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.Extendable tooling!
Fortunately, that's not a world any of us live in.
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.
You'd probably need to make an explicit SQL query since you wouldn't have the database integration.
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.)
/proc is a race condition waiting to happen, so I can't really say I recommend using that.
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.
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.