On:
In: learning, old school, toolchain

Bash logo
image source

As someone who is interested in programming and Linux, I feel it’s important to be comfortable on a command-line. I guess I subscribe to an old-school mentality. I really enjoy being able to interact with my computer through a keyboard.

Recently I decided to go further back to basics and focus more on what a stock system can do. So I uninstalled Zsh, and Tmux, and have been running just plain-old Bash again for a while now.

Before I go any further, I’d like to acknowledge that most of what I’m going to talk about below, I learnt from Peteris Krumins‘ blog. He has several excellent pages and cheat-sheets that I will link-to throughout this post.

So, here’s what I should have learnt first, things that Bash has built-in:

GNU Readline

GNU Readline is a library that can be used with any software project. It is built-in to Bash. It has two main features:

  1. Editing of command lines
  2. Maintain searchable/editable history of previously entered commands

A note on Vi/Emacs

GNU readline has two editing modes; Vi, and Emacs. And (I guess because it’s GNU) the default mode is Emacs. This means that the keyboard shortcuts are Emacs or emacs-style ones. I am a Vim user. I don’t want to get too-much into the eternal Vi/Emacs holy war; but I am in fact happy to stick with the default Emacs setting, for two reasons:

  1. There really aren’t that many commands/use-cases to learn for single-line editing
  2. I think Vi-style modal editing might be a little overkill for single-line editing. Admittedly I haven’t given this a lot of thought, it just seems slightly more clunky

Editing of command lines

Peteris has this page about Bash Emacs editing mode, and an awesome cheat-sheet there too.

Bash command-line history

Peteris has this page, entitled ‘The Definitive Guide to Bash Command Line History’

So, I have been focussing on this page and it’s cheatsheet. And in particular, the Emacs-mode keyboard shortcuts. Here’s how I understand manoeuvring the history:

Incremental vs non-incremental search.

As far as I can tell non-incremental search means search once. i.e. I type Alt+p, and then e, and then hit Return, it gives me exit, which is the first command backwards in (my) search history. if I then try to type Alt+p again, to get the next-command-back that matches e, the search resets. So really this command is useful for going to the first matching command only.
With incremental search, If I type Ctrl+r, then e and Return, I get exit (as expected), but if I then type Ctrl+r again, I get vim /etc/inputrc. Each time I subsequently type Ctrl+r I go back through the history to the next matching command. Of course this works forwards as well as backwards. Here’s a summary:

Do one search (non-incremental):

Alt+p backwards << + >> forwards Alt+n

Do an incremental search – allows you to hit the command again to move through matches:

Ctrl+r backwards << + >> forwards Ctrl+s

 

Wait! Ctrl+s doesn’t work, it just hangs my terminal!!!

Ah yes, on a lot of terminals / terminal emulators (and on Gnome-terminal in Ubuntu by default at the time of writing this) Ctrl+s is used to send the XOFF instruction. According to this Stack Exchange question it is a legacy of (very) old terminals which was something to do with pausing the terminal output. This was useful on terminals that did not allow scrolling; presumably you could use XOFF and XON like a pause button. But I guess nowadays it’s a lot less relevant. I disabled it by adding the following line in my ~/.bashrc file, as recommended by the Stack Exchange answer:

stty -ixon #Disable XON

 

That’s all for now. I’ve only scratched the surface here of what Bash is capable of, but already I feel more productive being able to call-up frequently used commands from history, and more competent not resorting to mashing the up/down arrows so much!

On:
In: learning, programming

karate belt

I have been learning a new language lately, which has given me cause to consider the needs of a self directed learner:

  • Textbooks. There’s a plethora of material from publishers such as O’Reilly, and Packt. There is also freely available material at sites such as MIT OpenCourseWare.
  • Feedback. I struggle with feedback. The Stack Exchange network covers this, but not in every situation. I may discuss this further in another blog entry.
  • Tutorials. No problems here; the internet is awash with tutorials on every conceivable subject.
  • Practice. Now, practice…

I can’t put it any better than Dave Thomas on his Code Kata site:

How do you get to be a great musician? It helps to know the theory, and to understand the mechanics of your instrument. It helps to have talent. But ultimately, greatness comes from practicing; applying the theory over and over again, using feedback to get better every time.

Code kata

A few sites provide code practice, some of them are less beginner-oriented than others though. I like the idea of writing coding exercises of my own someday. Until then, here are some links to sites I have found:

  1. Good article discussing all things code kata – Coding Horror.
  2. Code Kata – Problems on this site are more in-depth and considered. Probably more for intermediate level learners.
  3. Code Wars – A very interactive, ‘gamified’ site, with feedback. Requires login (can use your Github login if you have one). This site looks promising…
    UPDATE! – I’ve now been using the CodeWars site for a while, and I like it. If you fancy signing yourself up, please consider using this link (it just means that I’ll get some extra ‘Honor’ points)
  4. Adrian Neumann’s collection – A list of problems. Suitable for beginners upwards. (Also provides a lot of the links I have here)
  5. John Dalbey’s collection – More listed problems. From beginner upwards. Also: His Computer Science course projects.
  6. Rosetta Code Tasks – Large list! With solutions too.
  7. Project Euler – Very popular site. More for advanced programmers – heavy on maths. To quote – “Project Euler exists to encourage, challenge, and develop the skills and enjoyment of anyone with an interest in the fascinating world of mathematics.”
  8. Code Abbey – Problems, and fun artwork. Requires login to submit solution, but problems can be viewed without.
  9. Sphere online judge – To quote – “SPOJ – Sphere Online Judge – is a problemset [sic] archive, online judge and contest hosting service accepting solutions in many languages.” Apparently there are over 20,000 coding problems to solve.
  10. 99 Lisp problems.
  11. 99 Haskell Problems.

Code Golf

It’s not code kata, but I feel I should mention it. A lot of people will be familiar with code golf. Basically the idea is to solve a coding problem making the source code file as small as possible, i.e. solving the problem in as few lines of code as you can. Stack Exchange has a site dedicated to code golf. It’s a good idea, and a lot of fun, but I think it is much more suited to experienced programmers. It’s always said that beginner programmers need to learn good habits like documenting their code, and using good design patterns etc. This does not seem to gel well with code golf. Also, a lot of the answers to code golf problems are written in esoteric programming languages that are not really designed for mainstream programming.

I include code golf here because the problems themselves may be of interest, even if their mode of solution should not be pursued by the beginner.

Vim Golf is another thing. From the quote at the start of this entry – “It helps to know the theory, and to understand the mechanics of your instrument.” All programmers should understand their tools. Whilst lots of Java programmers will use IDEs such as Netbeans, or Eclipse,  some will prefer Vim (myself) or Emacs. Vim golf is a useful site for improving one’s knowledge and speed with this.

 

I hope you find this useful. Leave a comment and let me know what you think.