Hacker News Reader

Comment by whalesalad | Hacker News Reader

I want to give this 10 upvotes. This is one of those things you only see on HN occasionally, and it's full of all kinds of awesome little nuggets. That command to get the count from the information_schema in and of itself is gold (I now know about the tee command)

View on HN

I ran this select from information_schema to get the count of a table with aprox 1.2 million rows. each time I run the query, though, the number returned is different. it seems to vary by about 200k either way. does anybody know why that would be happening?

It's just an estimate for the query engine, not a true row count. But good enough for a progress bar.

From http://dev.mysql.com/doc/refman/5.0/en/tables-table.html:

> For InnoDB tables, the row count is only a rough estimate used in SQL optimization.

If you run it a dozen times, it converges on the truth.

aha, thanks

Also the while; do; loop could probably be replaced with 'watch'.

I tried 'watch' first (love that lil' command), but for some reason it parses incorrectly and doesn't work.

While it is possible to beat that command with backslashes until it works, I often just give up and make it a shell script, on the grounds that usually by the time I have something that complicated I want to "watch" I ought to be checking it into source control, or at least have it on disk for the next time I want it. For database stuff like that I've had nearly a 100% hit rate of either reusing such things, or at least consulting them later for the crafting of a related command.

Setting a really large $HISTSIZE can accomplish some of this.

Though I'll admit to occasional traumatic moments when my workstation crashes and bash history is polluted with multiple shells filling it and the stuff I've been ctrl-R invoking (recursive reverse search) for months evaporates.

You should set up a simple cron job to backup your history file (to somewhere else in your home directory) on some schedule (hourly?) and then when this happens just have an short alias that restores the last backup.

No.

The problem is curation.

It's really handy to have stuff in history. But there's a ton of crap I don't need.

What I need to do is get better about scripting the stuff that I'm invoking frequently. Though zsh probably has an extension that does this for you, and scratches your back.

Mind: virtually all my shell scripts start off as one-liners that I've invoked and re-edited (M-x M-e FTFW) until I've realized I have something worth saving.

> Setting a really large $HISTSIZE can accomplish some of this.

Or making your history permanent. I have a reasonable sized history in my shell, but also dump out each line I typed to an eternal history file.

See if bash's ignoredups and erasedups helps.

iirc, watch calls /bin/sh to execute what you give it. Maybe there was a quoting issue?

Reply on news.ycombinator.com