I've always connected it with "grip" (and the Norwegian translation: "gripe"). /usr/bin/grep runs through STDIN and "grips" the matching lines, while everything else flows through and disappear. That totally made sense in my head…
Grok is a term from Robert A. Heinlein's book "Stranger in a strange land."
I can see why finding out that these amazing words are not 'official' English could make you sad, but for me I find it amazing and encouraging, as this is exactly the way that some language is formed! They are so full of future potential.
I look forward to seeing what terms 'make it' into major dictionaries in the future.
Considering the rather eclectic nature of the English vocabulary, is there such a thing as a "normal" verb? Grok is exactly the same level as brobdingnagian, i.e. perfectly cromulent.
According to the Oxford English Dictionary, both grep and grok are English verbs. I'm happy about this, since the OED is about as official as you can get.
I used to do research for the OED and generally if there's evidence that a verb is common in the field (used in magazines, books, etc. by multiple authors and not just in reference to it's original usage) then the OED is willing to include it.
If there's a term that you think matches that criteria but isn't included you can gather up some relevent citations and send them in and they'll consider it for addition.
To get a transparent look at how they do this kind of thing have a look at:
The OED ran an open research project to gather evidence of science fiction terms as they figured the online SF community would be much better at finding this evidence than their own researchers.
grep, n.
Computing.
A Unix command used to search files for the occurrence of a string of characters that matches a specified sequence or pattern, and to output all the lines matching this. Also grep command.
grep, v.
Computing.
1. intr. To search for a string of characters using the grep command. Also trans.: to search (a file) in this way.
2. trans. slang (usu. humorous). Of a person: to search; to scan visually.
From Early history of UNIX: "When asked what that funny name meant, Ken said it was obvious. It stood for the editor command that it simulated, g/re/p (global regular expression print)."
There goes my theory about grep, awk, sed being named after digestive noises.
What's interesting is the history of dd and its completely non-UNIX like argument format e.g., if=/dev/null of=./foo bs=4k: the latter was designed as a prank mocking IBM's mainframe OSes (today's equivalent would be making a FactoryFactory in Python, I'd imagine)
Wow, I was thinking about this just this morning. I assumed it stood for "GNU regular expression parser" or something like that, even though that doesn't really make sense.
It was one of the first end-user programs hosted on the system and has been standard in Unix-based systems ever since. ed was originally written by Ken Thompson and contains one of the first implementations of regular expressions.
...
Famous for its terseness, ed gives almost no visual feedback. For example, the message that ed will produce in case of error, or when it wants to make sure the user wishes to quit without saving, is "?". It does not report the current filename or line number, or even display the results of a change to the text, unless requested.
One of the reasons ed is so terse is because bandwidth was really expensive back when it was written. Not necessarily in terms of money (since everyone was at a university), but in terms of time.
If your editor were to echo back everything you'd typed, you'd waste twice the bandwidth (once to send a keystroke in and once to get it echoed back). Though in reality it would be more like 4 times because each character sent through would require a TCP-ACK packet sent back. By saying nothing, ed became really fast.
sed took things to the next level. If you already had a file on a remote system, and wanted to make changes to it, all you had to do was note down the 'ed' commands to make those changes, and then tell sed to run them. You didn't have to open ed to operate on the file, you just had to send your commands over the network and sed would operate on the file remotely. A more efficient rsync, if you will.
ed preceded TCP (first ed manual I could find is dated 1971; the first TCP research paper was by Cerf and Kahn in 1974).
When ed was used, it would be common to interact with the computer on a teletype, not even on a crt monitor. So a response meant printing characters on paper.
sed was and is more about programmatic editing (i.e., editing a stream as it was generated, using a script for commands), or editing of large files that would overwhelm system memory, not about some kind of remote usage the way you're describing.
It wasn't network bandwidth actually, it was printing speed. When your terminal can only print ten characters per second, terseness is even more of a virtue than it is on a slow network.
I think everyone should spend an evening trying to write in ed. Knowing that most of unix was written in this simple editor shows the power of tight constraints in design decisions and the creativity that can come from them. It also makes the whole cascade of editors ed/vi/vim/... more understandable.
I did this exercise, and to tell the truth, it works better than "normal" editors for some tasks. For example, fixing bugs from a C compilation, checking a particular line, finding some structure on file based on regular expressions.
Nowadays, I use ed regularly whenever possible. I even wrote a blog post on my experiments:
"ed was a command-line editor that worked identically to the colon-commands in vi and vim—in fact, you can press Q to get into ed mode (then type vi to get back into vim)."
This is wrong. Pressing Q in vi quits visual mode and returns you to ex(1). ex(1) precedes vi(1) and was an extended editor, based on ed(1). That's why the commands are similar, but not identical. And ed(1) isn't dead, it still is a command-line editor. :-)
