LJ Archive


Pipes and STDs

Just a comment [regarding Shawn Powers' “Pipes and STDs” article in the April 2015 issue]:

find / -iname '*.jpg' -exec rm {} \;

Will do the trick also.

Gary Artim

Gary, you are absolutely correct. It's probably even more efficient to do this with find's exec flag. I found it surprisingly difficult to come up with an easy to understand example showing what xargs actually does. While it's not actually the best way to do the job, I hope my example at least demonstrated the concept.—Shawn Powers

An Old Trick

In the May 2015 issue of Linux Journal in the Letters section, Jeremy asks for help with a script that recurses directories, as he experiences problems with filenames starting with a dash.

An old trick from the command-line-only times was to prefix relative filenames with ./ to prevent unfortunate misinterpretations of entries starting with a dash. Based on that trick, I have created a modified script that should do what Jeremy set out to do:

function recurse_dir()
  local Dir
  local DirLevel
  local OldDir


  # Go to the wanted directory
  cd -- "$Dir"
  # Recurse through all files, including "hidden", 
  # i.e. starting with a dot
  for Entry in * .*
    # Skip current directory, parent directory 
    # and non-existing files
    if [ "$Entry" != "." -a "$Entry" != ".." -a -e "$Entry" ]; then
      # Add ./ prefix if needed (i.e. starting with -)
      if [ "${Entry/#-*/-}" == "-" ]; then
      # A file -- Do whatever is needed with a file!
      if [ -f "$Entry" ]; then
        echo "File:$Entry:"
      # A directory -- Do whatever is needed with it 
      # and recurse down it!
      if [ -d "$Entry" ]; then
        echo "Directory:$Entry:"
        recurse_dir "$Entry"
  # Set current directory to initial value
  cd "$OldDir"
recurse_dir ~

The script uses bash-only features to avoid extra/external processes. The current version (as shown) managed to recurse through 12,000 files/directories in five seconds on an old machine.

Torben Rybner

Hacking a Safe with Bash

I really enjoyed Adam Kosmin's article “Hacking a Safe With Bash” in the May 2015 issue.

One notoriously difficult part of getting encryption right is all the different ways data can leak out of the encrypted area. For example, the user should be careful not to store his safe on something like Dropbox, because the sync engine may upload temporary or unencrypted files as deleted files for future restoration. Additionally, some common utilities may create temp files in /tmp when working with data (sort, for example).

The ideal is a program that works directly with encrypted data, only unencrypting in memory and never committing plain text to disk. Unfortunately, these are application-specific. Alternate paths to safe creation would be either encrypted filesystems or encrypted containers that can be mounted, such as TrueCrypt, though the user still needs to guard against plain-text leaks outside the safe.

I hope that in the coming years, encryption solutions will be more deeply woven into the operating systems and be less hackish. In the meantime, it's good to have hacks (in the good sense of the word) such as Adam's.

Andrew Fabbro

Photo of the Month

Thought you might like to see Leonardo getting to grips with Linux at the age of four months. Keep up the great work guys! (I've been reading LJ since the early days and using Linux since it came on a bunch of floppies.)

Nick Taylor

LJ Archive