Tag Archives: programming

UNIX find writeable files – more creative

In a follow-up to my previous post, I got tired of typing things.  And so I came up with this script:



# Put arguments into an array

# If no arguments, set firt value to current dir.
if [ -z "${args[0]}" ]; then

# Loop over supplied paths and find writeable files
for arg in $args; do

  find $arg -type f -perm /u=w  | grep -v "\.class" | grep -v tmp-bin | \
grep -v aTest | grep -v fixToStuff | grep -v build/ | grep -v gensrc/ | \
grep -v Reference | grep -v "~" | grep -v "classes" | grep -v "buildtree"



My only detail to sort out was exactly how to refer to $@.  Apparently if you quote it (being exactly “$@”) that takes all the arguments as a single string.  Unquoted, it takes them separately and gets what I’m looking for.

As you can see, I also have a lot of cruft I don’t want to see in my results, so I use good ol’ “grep -v” to weed it out.  Yes, I know there is a way to use egrep to make that all one command, but for some reason it doesn’t always want to play nicely for me.  So in a classic “eff it, let the script deal with it” I just chain some pipes.  I think if I had thousands of files to sort through, this would suck.  But I don’t, so it doesn’t.

UNIX find writable files

Way back when, I posted about using find and grep.  I have learned a couple of things since then.

1) find your critiera | xargs grep your grep criteria … is nicer to your processor, memory, and quickly returning the results.

2) finding writable files.  This has been particularly useful when using a really backwards SCS that doesn’t integrate nicely, cleanly, or usable with an IDE.

My command:  find . -type f -perm /u=w

So simple. So elegant. So simply says “find all files in this directory, recursively, that are writable by the user/owner”. The one confusing thing I had about this was /u instead of /o. I figured “owner, group, world”, but it is actually “user, group, other(s)”.

Anyway, this has improved my programming life.  Yeah, I’m gonna say it… take that, Windows.

Interview Techniques

Interview Techniques… you are probably wondering what that has to do with technology.  This is partly to do with technology, partly a way for me to remember these, and partly, well, a ramble as usual.  I have been exposed to some simple interview techniques for “software engineering” positions and they are worth remembering.  These have come in a variety of difficulties, so I will attempt to organize them as such.

First, technology!  See Mike Code, is cool.  It is a way an interviewer can ask simple questions over the phone and see the person write the code.  That gets a darn cool in my book.  Perhaps it is as modern as VHS is these days, but who says a technology needs to be on the order of Star Trek to warrant recognition?

Also, I recently found this:  http://formatmysourcecode.blogspot.com/.  It is excellent for automatically formatting HTML/XML and code for posting in a blog.

Beyond the technology is the questions I have either been asked or found in my own prowling around.  These are thing ones I find to be the most interesting.

Practical Questions:

  • fizz-buzz, written in any language — basically, for some multiplier of a loop print “fizz”, for a different multiplier write “buzz”.  For a multiplier equal to one divisible by A and B, write “fizzbuzz”.
  • given two lists (e.g., friends lists), and assuming list-2 represents changes affected upon list-1, who was added, who was removed, who is the same.  Written in any language.
  • Extend a standard Java class (e.g., HashMap) such that it meets new constraints such as, and using HashMap as an example:
    • limit the number of values that can be stored popping off the oldest when a newer one is inserted
    • disallow overwriting an existing key; key/value must be removed first
    • lock the list if three unsuccessful attempts are made to retrieve a value
    • lock the list if three unsuccessful attempts are make to insert a value (e.g., inserting an existing key)
  • web application to retrieve basic statistics from somewhere like flickr, using web app technology of choice

Conceptual Questions:

  • What information should a bug tracking system have?  How should it be stored?
  • What project did you make the most difference on?  What did you learn?  What would you do differently?
  • Create an interface from a legacy system to a newer UI.  Assume an API or web service exists.  Describe the architecture you would use; describe high-level design considerations; define milestones.
  • A database has been demonstrating progressively degrading performance (either via an application or reports).  What diagnostic steps would you take?

Mean Questions:

  • I file lists like this as mean because they contain a lot of questions that either a person knows from practical use, or can look up.  To put someone on-the-spot to answer deep details like this in an interview is merely a test in making the interviewee squirm.  To me, these questions are a lot like asking a mechanic about metallurgy — while they use metal in their daily work, but they don’t need to know the minute details about the metals they use to get their job done or do their job well.

Steps in the KDE development direction

I embarked on a simple investigation today:  get kdevelop setup on one of my machines so I could start learning how to develop under KDE.  The first lesson was to get my environment right (Kubuntu 64-bit 10.04):

525  export KDEDIR=/usr
527  export KDEDIRS=/usr
535  export LD_LIBRARY_PATH=/usr/lib/kde4:/usr/lib/qt4:$LD_LIBRARY_LIB
537  export LD_LIBRARY_PATH=/usr/lib/kde4:/usr/lib/qt4:/usr/include/KDE:$LD_LIBRARY_LIB
539  export KDE4_INCLUDES=/usr/include/KDE

Then came the actual coding which, once the above was done, was quite easy.  I followed the tutorial here and modified it slightly to add a custom “No” button.  Simple small step, but progress nonetheless!