You probably actually want strtoul. There’s nothing you’re doing that will be problematic with an unsigned long, after all.

2. free(NULL) isn’t a great idea (you do it if malloc fails)

3. pre- versus post- increment. Umm. In most cases, the compiler will happily optimise the difference away. In some cases it might not be able to, although with out of order compilation (ie: independent actions happen out of sequence) it can still get it right in a lot of cases. You can probably trip it up with something horrible, and you can always force the issue using volatile, providing you don’t mind people looking at you strangely.

In C++ it makes more of a difference, because your type might be a class not a primitive, and most people implement pre-increment in terms of post-increment, so you’re paying an extra method call.

It’s a stylistic thing that under certain circumstances will make things faster, and shouldn’t ever make them slower. I’ll freely admit that I don’t always bother

4. that ruby doesn’t work for me – you want ARGV[0].to_i on line 3.

#!/usr/bin/env ruby

# Prints out the last n dirs of current directory

# The number of dirs to show in path
dirnum = (ARGV[0] || 2).to_i
# Grab current directory path and convert to array
pwd = Dir.pwd.split("/")
# Chop off the first element if its an empty string
pwd = pwd.slice( 1, pwd.length ).compact if pwd.length > 1 && pwd[0].empty?

if pwd.length > dirnum
 # The path is truncated
 puts ".../" + pwd.slice( -dirnum, dirnum).join("/")
else
 # The path is absolute
 puts "/" + pwd.join("/")
end 

The printf was PHP eating slashes – fixes that now so it displays correctly.

Re: pre-increment isn’t the small performance increase removed by the compiler?

Fixed the bug in the python version – that’ll teach me for throwing the comparison together

Some stylistic things: you should use strtol() in preference to atoi(); also ++n is generally better practice than n++ (it makes no difference in a lot of cases, and certainly shouldn’t in this, but it’s good practice unless you actually need post-increment). You have char* slash, delim; when you only need delim (I think). Finally, you have one if(…) without using braces, which I’d advise against because of the potential for a dangling else in future.

One buggette in cut and paste: printf(“n”); probably wants to be printf(“\n”); two lines from the end of main().

You aren’t handling errors from things like malloc, pathconf (unlikely), getcwd (change permissions underneath the calling shell) — this will result in abends (I was expecting a segfault from getcwd failure, but I actually got a bus error; whichever, it isn’t good).

Your python script has a bug in it as well: invoke without parameters and you get an IndexError. This isn’t the case in the C version, because argv will always be terminated by a NULL pointer at the end of the list (at argv[argc] — at least in C99, see 5.1.2.2.1 2 of WG14/N1124 for instance). In theory argc can be 0, in which case argv[1] isn’t valid; however that’s not going to happen on any Unix I’m aware of. (While talking about this, main should really have a return type of int.)

All minor things, though. I love the fact that the C code will be more readable to people with no knowledge of the language than the PS1 value that uses it