Thursday, September 25, 2014

Why spaces in filenames are dangerous

There seem to be more files with spaces in their names on Windows machines than in Unix. Both Windows and Linux have allowed spaces in their names for decades now, so why the difference?

I think part of the answer is that more people work at the command line in Unix than Windows. And spaces in filenames make it easier to lose files on Unix. Lose, as in, gone forever.

Really? Yes, ask anyone who has used Unix for more than a few years. The famed UNIX-HATERS Handbook at http://richard.esplins.org/static/downloads/unix-haters-handbook.pdf even has a note about this problem on page 19.

Step by Simple Step

When you do things on the command line you rarely type a file's full name. Instead you type the first
few letters and hit the Tab key and the command line shell fills in the rest of the name of the file. So

ls operTAB 

and the line changes to

ls operations.txt

Neat and fast. If there's more than one file that starts with "oper" then the choices are shown and you simply type a few more characters to choose the exact one you want.

If I want to remove all the files that match some name I can type

rm operTAB

which expands and then add a *. The * character means that the rm command will match operations.txt, operations2.txt and similar files.

But let's see what happens when we have spaces in the filenames.

-rw-r--r--   1 mdoar  staff     0 Aug 29 15:27 your_lifes_work
-rw-r--r--   1 mdoar  staff     0 Aug 29 15:21 some file
-rw-r--r--   1 mdoar  staff     0 Aug 29 15:21 some music

Here we have two files that both start with "some ".  And one file that contains all your life's work.

When I try to work with them I type 

ls soTAB

and the line changes to

ls some\  

Keep watching that trailing space that you can't see in the line above. 

When I want to remove the two files that start with "some", I type the same thing by habit:

rm someTAB*

And this completes to 

rm some\ *

Now to the command line that actually looks like two commands:

rm "some\ "

which fails because there is no such file, and more interestingly the command

rm "*"

which succeeds all too well. It removes all the files in that directory including the ominously-named file your_lifes_work

What Can I Do?

The first thing is to double check every destructive command you type. You know what you think you typed, but maybe you fat-fingered it. Anyway, look again t what is in front of you

You can alias rm to rm -i which will prompt you before removing any file. But this rapidly becomes tedious when removing more than a few files

You can alias rm to a move command (mv), so the files are moved to a Trash bin from where they can later be recovered. This is not a bad idea but there are edge cases if a file or directory of the same name already exists in this custom Trash directory

You could use the OS trash bin which is designed for jsut this case. That's true, but it's slower and not so convenient to use from the command line. 

Perhaps the best approach is to work out how to invoke the OS trash feature from the command line. 
  • http://apple.stackexchange.com/questions/50844/how-to-move-files-to-trash-from-command-line refers to some OSX apps that do this. This app looks good: http://hasseg.org/blog/post/406/trash-files-from-the-os-x-command-line/ but I haven't tried it
  • http://askubuntu.com/questions/6698/can-files-directories-deleted-from-terminal-be-restored/6703#6703 has a suggestion for the same idea in Linux

Friday, October 7, 2011

Curiosity and Control

I've also been thinking about why some people write code and some don't. I think there is indeed the creative aspect, and that's often expressed in other kinds of creative efforts. But there's also the aspect of curiosity about the software that we use.

Some people really like to know how things work, including their software. It seems to me that this is connected to a desire to control one's environment. So perhaps part of coding is about being control?

I must see what Computer Power and Human Reason has to say about this.

Life is Diff and Patch, Diff and Patch

There are two common Unix tools named 'diff' and 'patch'. Diff tells you what the difference is between two files. Patch takes what diff told you and merges those differences (aka changes) to another file. Now every tool I've used in the last twenty years has its own need for diff and patch functionality. Consider:

Word or text documents - show me what's changed, aka 'track changes'. Merge (patch) text from one document to another

Java API - what changed between two versions of an API

JIRA (the issue tracker) - show me what's new in this bug, merge this configuration to another instance of JIRA

So diff and patch seems to be a common theme of what I do for a living. But life is also diff and patch at some level - see what's different between two people and merge those differences to another generation of people. There's more in this analogy than I can get into words right now, I think.

Friday, September 16, 2011

Accounting for Bugs in Agile Development

There's always some discussion about how to account for the time spent fixing bugs in a project. I think it helps to view bugs as incomplete features, as in:

"I expected the feature to behave like this, but instead it behaves like that"

So the time spent fixing bugs can be measured in exactly the same way that features can be measured.

Friday, September 2, 2011

Joining CustomWare


My status at CustomWare has changed from subcontractor to a permanent employee. We celebrated with a surprise ice-cream cake with "Chief Toolsmith" iced onto it. I suspect that's something that people are rarely asked to write on a cake.

Thanks for the welcome!

Saturday, March 26, 2011

The Incomplete Image

I find it remarkable how the same piece of music can touch me deeply at one time and yet barely affect me at another. The recording hasn't changed, so it must be me. This ties into the idea that art is not just what is created by another, but also depends how it is received at a certain time.

That's all.

Wednesday, March 9, 2011

On Anonymous Bugs

Anonymity is a wonderful thing for many serious matters in this world. But posting unexceptional comments anonymously on a bug (or webpage) because you just can't be bothered to fill in your name is not wonderful. It just makes the anonymous author appear to lazy to register. And then the person reading the comment thinks less of the comment because it was made anonymously.

It's not just what you say, it's how you say it.

Filing a bug doesn't fix a bug

"I filed this bug a year ago and it isn't fixed yet".
"Other bugs were more important than your bug"
"But, but, *I* filed it!" (tantrum follows)

I'm always surprised by the number of people who think that that a bug should automatically be fixed just because they bothered to file it. All that can be expected is that the reporter is thanked, the bug is looked at, and possibly moved to the next stage of its life. That might be closure or marking as ready for more work.

A better approach is for the project to explain prominently how their bugs are triaged and how limited their resources are. Details of how to provide more cash resources and what that buys is also helpful.

~Matt

Monday, November 29, 2010

What if Christmas became a world-changing event again?

I came across the Advent Conspiracy today and I like it. And its ideas can be applied to any special day that has become poisoned by profit.

"What was once a time to celebrate the birth of a savior has somehow turned into a season of stress, traffic jams, and shopping lists.

And when it's all over, many of us are left with presents to return, looming debt that will take months to pay off, and this empty feeling of missed purpose. Is this what we really want out of Christmas?

What if Christmas became a world-changing event again?"

Tuesday, November 9, 2010

Word for the day: Disintermediation

From Wikipedia: the removal of intermediaries in a supply chain: "cutting out the middleman"

I've been working as a JIRA specialist for some larger consulting businesses recently and this matter has come up in discussion a few times. I'm glad to see there's a nice long word for such a nasty practice. It's a sensitive matter for everyone but I naturally err on the side of caution, even if I've had existing business with the same customer that is now using the other consulting business.

I wonder if I can get my 14-year old to use it correctly in class. I reckon it would make her English teacher's day.

Friday, October 29, 2010

Because it is awesome!


"Why did you bring it to share?"
"kus it is osum."

A standard part of US education is show-and-tell. Some classes have the children fill in a form before bringing something in, both to encourage their writing and stem the flow. My 6-year old Luke found a chunk of crystal and filled in a form. His quick and simple dude-style answer to the question "why?" was a lovely explanation of the wonders of our world.

Thursday, October 28, 2010

Another job that I have more respect for, the more I know of it

Gear Designers

Some clever people at NASA put together a document describing what goes into making a gear. The tooth shape and material questions I was aware of from my undergraduate days, but their calculations about just how different lubricants work around complicated shapes, expected gear lifetimes and dynamic force calculations are impressive. And it's all pretty modern knowledge apparently, mostly since the 1920's.

After reading it I'm amazed that helicopters don't crash more often!

Monday, October 25, 2010

I signed an oath



Alistair Cockburn is a well-known programmer who is fed up with
infighting in software development. So he came up with an Oath of Non-Allegiance.

"I promise not to exclude from consideration any idea based on its source, but to consider ideas across schools and heritages in order to find the ones that best suit the current situation."

Makes sense to me, and for more than software development.

Tuesday, September 28, 2010

Hidden depths, and Things That Will Never Be


A favorite xkcd cartoon and some things that will never be.

  • Unicode book that is both concise and useful
  • A protocol with "Simple" in its title that has remained simple - SNMP, SMTP, SDLIP are just a few that have not.
  • Revision control merges with absolutely no conflicts
~Matt

Friday, September 24, 2010

Appearances and Expectations


I've found that a spaghetti server is a great tool for scratching my back. We have one in the kitchen for food and different one on a shelf elsewhere. Of course, children like to copy their parents so 6 year-old Luke scratches his back just like his Dad, which I find rather endearing.

But sitting at the dinner table a few nights ago, he went very quiet, his eyes widened and asked "Dad, why is your back scratcher in the pasta?".

Just because two things look the same, they aren't necessarily the same.

Monday, September 20, 2010

Jobs that I have more respect for, the more I see of them

Statisticians

99% of everything written about statistics is wrong, including this. So when people really do understand how to set up proper clinical trials or fit their data to useful distributions, I'm impressed. What most of us learned in school and university really wasn't enough to understand the traps for the unwary and naive in this area.

Statisticians also get to use some great words like homoscedasticity and kurtosis.

~Matt

Thursday, September 16, 2010

Here comes AtlasCamp 2010!

If you develop or maintain Atlassian products (JIRA, Confluence, etc), this event is a great place to be (October 11th - 13th, California, $200).

I'm looking forward to it again with a relish I rarely find for many group events.

http://www.atlascamp.com

Wednesday, September 15, 2010

JIRA articles are now at jiradev.blogspot.com

I've started a new blog for JIRA-related posts over at jiradev.blogspot.com. Future technical JIRA content will appear there instead of in this blog

~Matt

Wednesday, September 1, 2010

My Review of Practical Development Environments

Originally submitted at O'Reilly

Everyone wants a good technical environment for developing their software, and Practical Development Environments contains helpful guidelines for how to create and maintain a great development environment. It discusses some of the current tools that are available, covering different areas...


Good advice, tools sections dated now

By Matt Doar from San Jose, CA on 9/1/2010

 

4out of 5

Pros: Concise, Well-written, Accurate

Cons: Partly outdated

Best Uses: Intermediate, Toolsmith, Novice

Describe Yourself: Consultant, Sys Admin, Developer, Author, Toolsmith

I'm the author and the book still works as intended. Each chapter has a section on using software development tools (version control, builds, bug trackers etc). The second half of each chapter refers to tools in each area that were current five years ago, so these parts have aged correctly.

I've run a consulting business for the past four years based around many of the ideas in this book and find that, for the most part, they are working well for my clients.

~Matt

(legalese)

Action, Expectation, Observation

I remember writing some parts of Practical Development Environments vividly, despite the sleep deprivation that writing a book and having a new child will produce. One such section summarizes what goes into a good bug report:

The three key points to bear in mind when creating a bug report should be:


  • How to reproduce the bug, as precisely as possible, and how often this will make the bug appear

  • What should have happened, at least in your opinion

  • What actually happened, or at least as much information as you have recorded


I still like what I wrote. And now I think it's good advice for other situations. For example,

  • Action: I was taking my brother's toy from him. It was his new toy.

  • Expectation: He should have let me take it because he wasn't using it anymore

  • Observation: He hit me!



Maybe I'll get it printed on my next batch of business cards:
Action, Expectation, Observation.

~Matt