Site Map - skip to main content - dyslexic font - mobile - text - print

Hacker Public Radio

Your ideas, projects, opinions - podcasted.

New episodes Monday through Friday.

hpr2278 :: Some supplementary Bash tips

Finishing off the subject of expansion in Bash (part 1)

<< First, < Previous, Latest >>

Host Image
Hosted by Dave Morriss on 2017-04-26 is flagged as Explicit and is released under a CC-BY-SA license.
Listen in ogg, spx, or mp3 format. | Comments (11)

Part of the series: Bash Scripting

This is an open series in which Hacker Public Radio Listeners can share their Bash scripting knowledge and experience with the community. General programming topics and Bash commands are explored along with some tutorials for the complete novice.

Some supplementary Bash tips

Pathname expansion; part 1 of 2


As we saw in the last episode 2045 (and others in this sub-series) there are eight types of expansion applied to the command line in the following order:

  • Brace expansion (we looked at this subject in episode 1884)
  • Tilde expansion (seen in episode 1903)
  • Parameter and variable expansion (this was covered in episode 1648)
  • Command substitution (seen in episode 1903)
  • Arithmetic expansion (seen in episode 1951)
  • Process substitution (seen in episode 2045)
  • Word splitting (seen in episode 2045)
  • Pathname expansion (this episode and the next)

This is the last topic in the (sub-) series about expansion in Bash. However, when writing the notes for this episode it became apparent that there was too much to fit into a single HPR episode. Consequently I have made it into two.

In this episode we will look at simple pathname expansion and some of the ways in which its behaviour can be controlled. In the next episode we’ll finish by looking at extended pattern matching. Both are included in the “Manual Page Extracts” section at the end of the long notes.

Long Show Notes

I have written out a moderately long set of notes about this subject and these are available here.


Subscribe to the comments RSS feed.

Comment #1 posted on 2017-04-28T21:56:56Z by unverified

You Rock

I've been meaning to comment somewhere on the site about how great a resource the site is but if were nothing but "Dave Morris Reads The Manpages" I'd gladly listen.
Your attention to detail and calm mannerism is very pleasant and that it happens you cover the good stuff any nix user needs to get a handle on is just perfect.

When there is a lull I'll go through them all again.....and again.

Thanks for holding up far more than your end of the podcast.

Ill try to break past the public speaking phobias and help.
And help with tags too.

Comment #2 posted on 2017-04-29T11:16:32Z by Dave Morriss


Well, that's a great comment! Thank you.

My principle is to find stuff I don't understand (or didn't in the past) and share what I have learnt to help anyone who wants to grasp whatever it is.

I have just uploaded part 2 of this two-parter, so there's more to come :-)

I hope you manage to make episodes of your own. For my first one I wrote notes for HPR, but also made myself a list of the points I wanted to cover, and rehearsed the episode before the final recording. Whatever gives you enough confidence to do it!

Comment #3 posted on 2017-06-15T08:14:35Z by clacke

How people record

It would be interesting to have an overview of how various people choose to prepare and record their episodes, for newcomers to get some idea of what might suit them.

The way I have done it recently is to write the show notes and while I do so, basically play in my head what I will say about them, and then come up with side tracks I ought to provide references to, etc.

I don't rehearse, and lately I haven't cut anything out either.

Earlier, I've cut my episodes a bit, because I had gone off track or there was too much ambient noise when I've been out walking, but now I'm aiming for as little threshold as possible before I publish. I had that one episode that I procrastinated for a year because I wanted to edit it down for length. Finally I just published it.

Worse is better. For me, anyway.

Comment #4 posted on 2017-06-15T08:24:45Z by clacke

On using echo

The tip about using echo is great, and I've used it many times. Lately though, I've started using printf because it can help me see some weird filenames, and also helps with long filenames.

One could use `ls` too, or rather `ls -d` to not expand any directories listed, and it might be the instinctive thing to do but in the case of a lot of files, actually just printing the parameters is faster, because regardless whether you just want to see the file names, `ls` also inspects each and every one of the files to figure out how to e.g. color it.

Now, here's what I do with printf:

# Show all the names with single quotes around them.

$ printf "'%s' " /some/directory/and/wild*card; echo

# Show all the names on separate lines.

$ printf "%s\n" /gnu/store/*-theprogram-2.0*

The latter one is what I literally do when looking for things in my Guix or Nix store, because those file names are all so long, and it's helpful to get one per line.

Comment #5 posted on 2017-06-15T09:10:30Z by Dave Morriss

On recording

I also like to prepare notes first, and as soon as possible after they are done, record. That way the ideas are all fresh in my mind. I use the notes as a structure but mostly ad-lib the audio. Reading the notes is a big mistake as far as I am concerned. Since the first HPR show I did I do not rehearse.

Years ago (late 1970's) I used to teach evening classes in an Adult Education centre (Pascal, BASIC). I evolved a similar style there, and constructed notes which became hand-outs for the students. Amusingly they were printed on a line-printer, and I'd written my own text-processor to generate them (think early but less convenient Markdown).

As to audio editing, I do edit. I hesitate and 'um' and 'er' a lot and I deal with these by (light) silence truncation and removal of a proportion of 'um/er' patterns. I can edit a lot faster now than when I started, but it's just a personal foible. Without editing I find my audio irritating to listen to and assume others will too!

Comment #6 posted on 2017-06-15T10:03:32Z by Dave Morriss

Using echo, printf and ls

Hi clacke,

Your comment made me think about the way I have been using echo in this series. I may have said this at some point, but maybe not: I was primarily using it to demonstrate how expansion was working. I don't use it in that way to view directory contents and so forth.

Expansions like the ones here are used in many contexts, as you know. Back in my early days of using Unix (we had Sun, HP, DEC, Silicon Graphics and Apollo systems around at various times at the university I worked at), with a variety of shells. I think As an aside, I hated csh and tcsh the most!

There were time when I'd type something like:

rm *.msg

and get back an error like "too many files". That was because the expansion of '*.msg' resulted in 'rm' getting maybe thousands of file names, which it couldn't cope with. I got in the habit of doing stuff like:

echo *.msg | wc -w

to warn me of such potential problems. Maybe even 'echo' would fail sometimes with "too many files" (or similar), but I don't remember now. Maybe 'ls' would have been a better choice back then. However, for this series I felt it "got in the way" a bit more, as it were :-)

Your points about printf are well taken. I did mention it earlier in this series, and showed its use in various contexts. However, it probably deserves a show all of its own!

Yes, I had discovered:

$ printf "%s\n" *.msg

a while back and was surprised it printed out its arguments one per line. Some other 'printf' implementations reject such things because there are more arguments than format specifiers. The Bash 'printf' behaviour is better in my opinion.

Better stop - Ken will accuse me of wasting another show opportunity!

Comment #7 posted on 2017-06-16T06:45:30Z by Ken Fallon

Comment limit

What a waste of shows !

I think we should limit comments to - "Please see my show ${new_show}" :)

Comment #8 posted on 2017-06-16T13:48:04Z by clacke

printf episode

printf added to .

Comment #9 posted on 2017-08-06T02:59:23Z by clacke

A new `ls` alternative

On the topic of `ls`, there's a new player and people say it's both faster (I'm assuming it's stat'ing less eagerly than coreutils ls does) and more featureful (more coloring, info on git things, some tree visualization). Haven't tried it myself yet.

Also it's written in Rust, but that's least interesting property of it.

Comment #10 posted on 2017-08-06T19:55:42Z by Jonathan Kulp


That `exa` command does look pretty cool and powerful but it is WAY too awkward to type. i would have to make an alias for it, maybe even link `ls` to it.

Comment #11 posted on 2017-08-06T20:33:16Z by Dave Morriss

Not sure about 'exa'

Perhaps it's still too new, but 'exa' doesn't seem quite the tool for me.

Firstly I couldn't find out what the colours and underlines actually mean. Secondly I find that I need to change the screen background colour and font to be able to read the coloured text. Admittedly, this might be my eyes, but if a filename is basically a blur I don't get a lot from the feature! (I have similar problems with other commands that generate coloured output, so I don't blame 'exa'.)

Potentially the Git interface is useful, though I don't know what the symbols mean. The whole thing needs documentation - ideally in the form of a well-structured manpage. Also I was puzzled to find that:

exa -l --git db_*

didn't show the Git details for the matching files. These are only shown when there's no file argument.

My final nit-pick is that my favourite 'ls -ltr' can't be written so simply in 'exa'. The equivalent seems to be:

exa -ls modified

I'd like to see a way of setting defaults (like sort by modification time), through an environment variable or a configuration file. As Jon says, using aliases would also be a solution.

I shall be intrigued to see how 'exa' develops. It does have promise. Thanks for alerting me to it @clacke.

Leave Comment

Powered by Comment Script