This comment made me realize that there are a lot of really good posts on Google Plus by people like Rob Pike, Greg Kroah-Hartman, Linus Torvalds and others. For whatever reason, systems programmers liked Google Plus.

Anyway, I hope someone is archiving them somewhere, because there's a lot of knowledge there that will otherwise be lost in a few months.

My immediate thought when they announced they were shutting down was "What about Linus's posts?!"

Google Plus played less with people's emotions, that's why it sucked as a social media but was quite okay to follow content makers and to manage/participate in groups.

I always wondered about the "dot files" convention. That's a really good story! If I knew there where posts like this one I would join in a heartbeat. Where can I find communities like this today !? I always seem to be too late ...

Isn't he talking about something different, though? Specifically the convention that file names starting with "." are hidden?

Yep, nowhere in the post does he suggest regretting chosing "." to denote the current working directory.

Reading that post indicates that he regrets the existence of hidden files, not the existence of '.' and '..'

Yes, though Plan9's implementation of ".." Is incredibly different to Unix. It's treated as a lexical token rather than an actual directory entry, and so therefore certain strange cases with symlinks are handled differently (though Plan9 doesn't have symlinks either). From memory Rob Pike had a blog post about this problem and why Plan9 does lexical path cleaning on all paths before resolution.

I had no idea .. wasn’t treated as a lexical token in POSIX. Why the hell is it not and what would break if it suddenly was? Also, why do you need a new syscall to do it when it seems like string manipulation is all that’s necessary?

The most obvious example of something that would break is any code that uses symlinks. Here's an example:

  % ln -s foo/bar/baz link
  % ls ./link/..

This resolves in POSIX to "./foo/bar", not "." (which is how it would resolve in Plan9 if Plan9 had symlinks). If you treated ".." as a lexical token you'd have to sanitise it before doing anything else and thus you'd end up with Plan9-like semantics. You could also make the argument that Plan9's ".." semantics actually cause inconsistencies between "cd $path; ls .." and "ls $path/.." -- and this is especially true for Linux's "magic links" in procfs. So if you prefer a consistent VFS then making ".." a lexical token is not the best idea.

> Also, why do you need a new syscall to do it when it seems like string manipulation is all that’s necessary?

I'm not sure what you mean -- Plan9 is a separate operating system which does the above path sanitisation with each path-related syscall.

I think you'd have to treat `.` as a lexical token as well. So parsing `./link/..` would first resolve to `/home/me/link/..` then '/home/me/`, no?

> I'm not sure what you mean -- Plan9 is a separate operating system which does the above path sanitisation with each path-related syscall.

From http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames

> A new kernel call, fd2path, returns the file name associated with an open file, permitting the use of reliable names to improve system services ranging from pwd to debugging. Although this work was done in Plan 9, Unix systems could also benefit from the addition of a method to recover the accurate name of an open file or the current directory.

> I think you'd have to treat `.` as a lexical token as well. So parsing `./link/..` would first resolve to `/home/me/link/..` then '/home/me/`, no?

You could, but that doesn't really change the point of my comment -- "." is very trivial to handle either lexically or as a directory entry and generally Linux's handling of it is basically a no-op (though it should be noted that it's a no-op compared to $path/ not $path -- which is an important distinction with symlinks-to-directories or mountpoints).

The key difference is whether the symlink is actually resolved (and thus ".." applies to the partially-resolved prefix of the path resolution) or if it applies to the symlink component itself (and thus it never gets resolved).

> A new kernel call, fd2path, returns the file name associated with an open file [...]

fd2path goes from fd -> path, which is the inverse operation to path resolution. All path resolution in Plan9 goes through cleanpath() (as far as I know). fd2path is similar to readlink(/proc/$pid/fd/$fd) on Linux.

The two things are separate concepts.

I am starting to see why symlinks screw everything up. I guess I come at it from the URI standpoint: `https://example.com/foo/../bar/` should be resolvable client-side to `https://example.com/bar/` without having to worry about what's on the server, right? So I'd say the path should be processed the same way: without looking at the filesystem first. I'd advocate that the `/../` should be applied before the symlink is resolved because when I am in `/home/me/bar/` and I say `cd ..` I mean "go to `/home/me`" not to some arbitrary part of the filesystem.

Actually, in the case of "cd .." shells will often try to fake how symlink resolution actually happens. You can see this if you "cd" into a symlink, you shell's $PWD and built-in pwd command will tell you that you're inside the symlink but not the actual directory you got thrown into. This results in "cd .." actually doing what you describe -- even though it's a complete fantasy invented by your shell. Try it out.

Yes, that's right. He does have issues with how ".." works in Unix though. There's a pretty detailed explanation from him here: http://doc.cat-v.org/plan_9/4th_edition/papers/lexnames (scroll down to about the third appearance of "..")

Your comment is a bit misleading. He is regretting introducing a bug which resulted in creation of hidden files. He isn’t regretting using . and ..