I just add four details to Paul's answer:
- there is a nickname for cat when using it in "cat > myscript" : the Guru Editor. As Paul wrote, once you have hit the Enter key, it's too late to correct the previous line.
- if you want to add lines to an already existing file you have to "cat >> previous" two adjacent superior". If you just hit one >, you erase your previous file.
- all this depends on the redirection mechanisms in the Shell you use (all of them for this).
- vi also works on a copy of your file (usually in /var/tmp): if you kill your vi session (or your system crashes), you have a copy of what you did (vi -r ...).

And me too, even after 40 years, I also didn't use every vi command. The more funny is when I learned after maybe 10 years, that I could copy some line(s) with "yy" instead of what I used (dd then P).

Answered

Sorry! Something went wrong on our end. Please try again later.

Jaco Bezuidenhout

August 23, 2017 10:22 AM

HAHAHAHA, YES fkCzAdine, vi was designed to keep us interested.
Firstly it was for us to slowly learn how to actually use it.
Then it was to have us gradually learn more about it in time.
Then it was to surprize us years later.
The magic of unix....

Oh , yeah, I also got surprized a few times with vi, like this one:
take the cursor to where you want to start
press escape to start (vi starts recording)
do whatever you do to change text (like 'dw' to delete a word, then x x x x to delete 4 characters, then shit+a to go to the end and shift+j to link the line below to the current line)
then once finished, press escape again. Now everything I did is recorded, I can now safely browse around with the cursor to a new start point and once there...
I press the dot (".") to repeat all the recorded instruction
When I found this out it made my week/month.

vi might seem like the biggest load of crap to a noob, but it is definitely an entertaining intelligent editor.

Jaco Bezuidenhout
Senior Compute Engineer

Answered

Sorry! Something went wrong on our end. Please try again later.

Jaco Bezuidenhout

August 23, 2017 10:22 AM

Oh yeah, if you want to yy 10 lines, just go:
10yy
p

or yank 15 lines and paste it 40 times:
15yy
40p

LOL

Jaco Bezuidenhout
Senior Compute Engineer

Answered

Sorry! Something went wrong on our end. Please try again later.

Paul Pedant

August 23, 2017 02:01 PM

Have to admit I still hate working blind on vi. I don't use named buffers, or recorded macros, or the tag (cxref) tools.

For dealing with big blocks of lines, I enable line numbering, and use "ed" commands.

:set nu
:14,132m730
:set nonu

This is (from memory) dos2unix inside a vi session.
: goes into ed mode.
1,$ selects all lines in the file.
! runs the given external command process
awk gets given the range of lines as stdin, and whatever awk outputs then replaces those lines in vi.

:1,$ ! awk '{ sub (/\015$/, ""); print; }'

The u (undo) command is most helpful when you mess up a powerful command, but doing :w before you get adventurous is also highly recommended.

Answered

Sorry! Something went wrong on our end. Please try again later.

Jaco Bezuidenhout

August 24, 2017 03:21 AM

See now this is where I get lost.
What does 14,132m730 mean?

And this is something I don't grasp at all:
sub (/\015$/, "");

:( I wish I can find time to sit down and learn sed and awk thoroughly.

14,132m730 : move lines 14 to 732 after line 730
Note : 17,.m/there are/ : moves line 17 to current line after next line containing "there are"

For the second, Paul is a bit Pedant :)
:1,$s/^V^M$//
would avoid another process (awk) just doing it in vi
From line 1 to last line (could also be simplified), substitute CR at the end of each line ($) by nothing. To type a carriage return, you have to first hit ^V (so control V control M)

The awk does exactly the same find pattern octal 015, that is CR (see man ascii) at the end of line and substitute it by nothing.

Answered

Sorry! Something went wrong on our end. Please try again later.

Paul Pedant

August 24, 2017 07:50 AM

We started out with Teletype Model 33: https://en.wikipedia.org/wiki/Teletype_Model_33

This was originally used as an offline paper tape editor. You could read/copy a paperpape, stopping and moving it by hand, and punching up changes in the tape itself.

It also came with a serial interface (and a cradle adapter modem for a standard phone handset), so it could be used to input or output from a computer with papertape, or input from the keyboard and output to the integral 8-inch roll-paper typewriter.

This would work as a programmer's terminal on Unix: you could type username and password, and you got a shell prompt. Without a screen, you only got one "window", which is why Shell has stuff to deal with background jobs, stop jobs, nohup, and so on.

First thing anybody needed was an editor. But it couldn't use control characters because the serial interface used a lot of them, and the shell used a few more. And because you wanted to print as little as possible (at 10 chars per second), it needed lots of good search, mark and edit commands -- there was nothing to cut and paste from! You were generally working blind, seeing only 5 lines of your code at a time.

So the standard editor (ed) was written to use short text-only commands, with no feedback (OK, if you make an error, it says '?'). I can't find the famous quote.

The ed would let you run a subshell inside it (so you didn't have to save your file, exit, use shell, ed again...), with the ! command. But it would also let you run a whole command as !command, and it integrated the stdin and stdout for that command into the ed structure. So you could use external commands to line-wrap, or translate, or spell-check your text.

Have to say, we got hundreds of different terminal devices along later. Unix was designed to use any equipment lying around (K&R started with a PDP-11 they found in a cupboard). So Unix got a package called termcap which translated capabilities for every known terminal (using a config file) and a library called curses which did optimised layout, colour, and so on for devices too.

When we got screens, we got a visual editor (vi) which let you scroll and do slick stuff. But under there, it still uses all the functions that ed provided. And you can still type any ed command you choose -- the initial : just tells vi to pass it through.

Vi also continues the ability to run a shell or an external command.

The ed commands were useful enough that a non-interactive version was built -- sed is stream editor.

One specific ed command was so useful it because a whole family of commands.
You often wanted to find all the places you used a variable or a function. So the ed command for a global regular expression search and print was like:
g/myRegExp/p ## otherwise known as grep, egrep, and fgrep.

Answered

Sorry! Something went wrong on our end. Please try again later.

Paul Pedant

August 24, 2017 09:20 AM

It all looks a bit chaotic in the ed commands, but they are quite heavily structured.

Commands that work on blocks of lines take a "start,end" line range definition. They can be plain line numbers, or . (current line) $ (last line) /RE/ (a forward search), and all can have a + or - offset. So 1,$ is whole file, and .-3,.+3 is the seven lines centred on the current line.

So the m (move command) moves that block after the line position that follows it, and the t (to command) copies them, and the s (substitute) command does a search/replace on every line in range, and the d command just deletes them. All deletions go into a stack of 10 named buffers, so you can shuffle stuff (if you can remember which is which).

There must be 50 commands, but they do consistent things and it's not too hard to learn them if you use them often enough.

It happens that awk, vi, ed, sed and shell all choke on a plain Ctrl-M because it is CR and gets treated as syntactic newline. So it needs escapes. If you are typing at a terminal, Ctrl-V disarms the readline X-windows function so the Ctrl-M gets through. Other tools recognise \c as a CR.

In awk, I use a lot of different ASCII control codes, some of which have specific escapes and some don't. So I have standardised my awk code to use 3-digit octal equivalents for data throughout.
" (\042) ' (\047) CR (\015) TAB (\011) ESC (\033) NUL (\000) DEL (\177).

I also often define awk constants using the ASCII name like DQ = "\042"; BLK = "\040"; just to clarify what I am really doing in the functions. As I said elsewhere yesterday, giving something a (meaningful) name is the first step to thinking about it clearly.

Answered

Sorry! Something went wrong on our end. Please try again later.

Jaco Bezuidenhout

August 24, 2017 10:31 AM

Paul, I think I'll rather kneel down and say "I'm not worthy" and keep re-reading to even try to start to understand.

Jaco Bezuidenhout
Senior Compute Engineer

Answered

Sorry! Something went wrong on our end. Please try again later.

Paul Pedant

August 24, 2017 11:39 AM

Jaco, don't give me that. You guru the heck out of me. I'm just uncomfortable to think how much of my client's money I wasted following my own agenda.

Answered

Sorry! Something went wrong on our end. Please try again later.

Paul Pedant

August 24, 2017 11:44 AM

I found that "famous quote" I mentioned 3 hours back, which is about Ken Thompson, not by or about Brian K.

Originally, Unix would run in 96 kilobytes along with a C compiler or ed. (Source: The Bell System Technical Journal Vol 57 No 6 Part 2 Page 1907 -- article by D M Ritchie and K Thompson). So not a whole lot of space available for verbose diagnostic messages.

The original man page for ed said:

"When an error occurs, if ed's input is from a regular file or here document, then it exits, otherwise it prints a '?' and returns to command mode. The experienced user will usually know what's wrong."

I can't find an attribution, but some wit produced a spoof response to that:

"Ken Thompson has an automobile which he helped design. Unlike most automobiles, it has neither speedometer, nor gas gauge, nor any of the numerous idiot lights which plague the modern driver. Rather, if the driver makes any mistake, a giant "?" lights up in the center of the dashboard. "The experienced driver," he says, "will usually know what's wrong."

So maybe another quote from Brian himself:

Kernighan’s law

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

Answered

Sorry! Something went wrong on our end. Please try again later.

Jaco Bezuidenhout

August 24, 2017 01:08 PM

HAhahaahaha . . . you just stamped my first smile for the day on my face... and it is 18:48 already.
I'd love to learn serious coding one day. I might be guru, but in some areas you may call me mr. noob.