Vim & Vision

Perldoc Output Permalink

Perl, Linux Added less than a day ago

If, when you look at the documentation for a core-builtin, like so:

$ perldoc -f system

you get some funny characters in the output (long dashes, 'smart' quotes, etc) - and you wish to remove them (to make copy-pasting of code easier,) then simply:

$ perldoc -tf system

The -t flag avoids any fancy formatting and just outputs plain text.

Yum Permalink

Photo, Yum Added about three weeks ago

Yum 01

Potato rosti with salmon and a dill and caper sauce.

Served with a side of roasted capsicum and prosciutto.

About a fortnight ago a possum broke into my office and ran around peeing on my keyboard and printer. He'd come in from a tree that has branches close to my windows. I ended up chasing him out - he jumped back out the window onto the tree.

We just had a minor blackout so I went walking around the apartment - only to see some brown fur near the window of the bedroom.

It turned out to be this guy:

Possum

I think this guy is a ring tail possum, and the office possum was a brush tail... but I'm no possum expert. All I know is that I have to close these two windows at night!

Git's Index Permalink

Git Added about a month ago

Plasmasturm has some excellent things to say about git's index, including:

So what is the index good for? The key to understanding it is how it interacts with git diff. Once you add something to the index (also referred to as staging it), it disappears off the diff. You can pass --cached to see what changes you have staged, but by default, it doesn’t show you the changes that you have asserted are ready for commit. When I first read about this, it sounded outright stupid to me. Why would anyone want that? Turns out: because it is hugely helpful. Consider: when a merge fails, the successfully merged diff hunks are staged, but conflicted hunks are not – which means that git diff will show only conflicts, and the successfully performed part of the merge doesn’t cloud the diff. Furthermore, the way to mark files with conflicts as merged is to stage them after manual resolution, which makes them too disappear from the diff. Maybe this is why Linus introduced the concept in the first place, being that the main part of his job is to perform merges all day long. But that’s far from the only circumstance in which the index has been useful to me.

Jira Project Keys Permalink

Jira Added about two months ago

To edit a project's key after you have created it, you must do an XML export, then change all instances of the key in question in the file, then import it again.

I got myself into trouble by trying to change to a key with a dash in the name... the XML imported correctly again, but when I went to view a ticket using the KEY-TICKETID format, the page broke.

Make sure you don't put dashes in your project keys!

The Coffee Shop Permalink

Cool Added about two months ago

So I did sit down, and everywhere I looked I saw customers of every description being received with love. To the waitress everybody was "honeybunch" and "darling" and "dear". It was like an emergency ward after a great catastrophe. It did not matter what race or class the victims belonged to. They were all given the same miracle drug, which was coffee. The catastrophe in this case, of course, was that the sun had come up again.

Kurt Vonnegut, "Jailbird"

Git GUI Permalink

Git Added about two months ago

The GUI you get from:

$ git gui

... is a good way to look at all your changes (with diffs), selectively stage them, commit and push. This is mostly just an easy shortcut but I find it easier to compose a commit message this way, while you can see the diffs for changed files.

It is more important... Permalink

Rant Added about two months ago and last edited about two months ago

It is more important not to be a bigot than to win an argument against one.

Questioning Unix (and Other) File Times Permalink

Shell, Linux Added about two months ago and last edited about two months ago

stat displays three times:

atime (last access time)
mtime (last modify time)
ctime (last inode change time)

atime is fairly obvious, where do the others differ? This article tells us that mtime and ctime change when you alter the file's contents - but ctime alone changes when you alter the file's permissions or owner.

What about file creation time? Historically, Unix did not store file creation time.

How do I find the creation time of a file? You can't - it isn't stored anywhere.

Why doesn't old Unix store creation time too? The linked article suggests that creation time is a human concept not a system one - it raises this question: when does file creation time get set when file operations that completely remove, create links to, create copies of, or replace the file in question occur?

To explain that last paragraph with an example, consider these two files:

10:00PM $ echo "hi" > yourfile
10:05PM $ echo "hello" > yourfile

10:00PM $ echo "hi" > myfile
10:05PM $ rm myfile
10:05PM $ echo "hello" > myfile

The two sets of commands both initially create a file at 10:00PM, and at 10:05PM they are both in the same state - but one has been completely removed and re-added. When was it created? Some human interpretation is needed. (See the full email for other shell commands/programs that the poster is concerned as to the interpretation of.)

So does that mean creation time is meaningless and can not be measured? Nope.

More recently certain file systems have started storing file creation time. Consider the UFS2 under FreeBSD.

What about Mac OSX? Yep, the Finder knows about these three file times:

Created
Modified
Last opened

... and if you use stat you will find four values listed: atime, mtime, ctime and birthtime (creation time). Do a man 2 stat and look for the section on st_birthtime which does store the file 'creation time'... if it is available on the current filesystem!

If you are on Windows you will note that NTFS stores:

file times when applications create, access, and write to files.

... so ... I suppose that these filesystems etc have some rules for creation time that the Unix guys couldn't fathom? Let's try things out in the Finder:

% date && echo "hi" > yourfile
Sat  9 Jan 2010 00:39:15 EST
% # I check the Finder and it says creation time is: Today 12:39 AM
% # ... now i wait a minute ...
% date && echo "hello" > yourfile
Sat  9 Jan 2010 00:40:33 EST
% # I check the Finder and it says creation time is still: Today 12:39 AM
% # (but the modified time is 12:40)

% date && echo "hi" > myfile
Sat  9 Jan 2010 00:42:42 EST
% # I check the Finder and it says creation time is: Today 12:42 AM
% rm myfile
% date && echo "hello" > myfile
Sat  9 Jan 2010 00:43:56 EST
% # I check the Finder and it says creation time is: Today 12:43 AM

So, despite the file getting completely blatted both times with new content, only the time when it was rm'ed first caused the Finder to reset its creation time.

I think that makes sense. Consider what happens when you rm:

the directory entry is set to point at 0 instead of the inode it did point at, and the link count for the inode is decremented by one. If the link count has reached 0, and no process has the file open, then the inode itself is marked us unused, and the disk blocks that the file used are returned to the free list.

So, at this point, your data is still there until some other process needs disk blocks and these happen to get reused.

So the inode is still there... with the data... but the inode has been marked as being unused - this is when a file's creation time is lost.

What is my conclusion? I guess I don't know why the old Unix guys thought creation time was immeasurable - perhaps I'm misunderstanding their stance. But I do know that modern filesystems keep the creation time... perhaps I should do a full experiment on all these commands, comparing the file creation times over systems that do store them.

The Frog King Photo Permalink

Photo Added about two months ago

The Frog King

Older Posts ... (Nothing Newer)

Colophon

Django Python 960.gs Git Vim NetBSD Nginx

The Author

The author is a software engineer living in Australia. He sux at guitar, loves camping, doesn't like cake, does like coffee and is a lazy home brewer.

Links

ChoppingBoard, Project365, RageQuit