ITT we post weird bugs we've encountered on *nix systems.
like this:

$ cd /usr/ports

(about 3 1/2 hours later)

$ pwd
.
$ ls -a
$

wtf?!?!

>>1
oh, and i also did this...

$ ls -d ..
ls: ..: No such file or directory

That means something nuked your $PWD ... or you've got some serious file system b0rkage there.

Did anything happen between the cd and the pwd command, or did you actually have your machine chewing its cd (lol lol) for three and a half hours?

$ ls
YKK.kmz
$ gunzip -S "" YKK.kmz 
gunzip: YKK.kmz already exists; do you wish to overwrite (y or n)? y
$ ls
$ ls -la
total 0
drwxr-xr-x    2 dag  dag    68 Dec 13 15:43 .
drwxr-xr-x   94 dag  dag  3196 Dec 13 15:42 ..

Awesome behaviour, gzip!

>>5 It probably tried opening the same file for both reading and writing, as separate file handles. That sort of thing is not wise....

Perhaps zcat was what you were after?

$ zcat < YKK.kmz > YKK.kmz.decompressed
$ mv YKK.kmz{.uncompressed,}

>>4
i went to answer the phone after the cd and when i came back later it was messed up like that

>>3
nuking $PWD doesn't do it...

>>8 Well, nuking the directories above $PWD does...

stuartl@beast ~ $ mkdir -p /tmp/foo/bar
stuartl@beast ~ $ cd /tmp/foo/bar/
stuartl@beast /tmp/foo/bar $ rm -fr /tmp/foo
stuartl@beast /tmp/foo/bar $ ls
stuartl@beast /tmp/foo/bar $ ls -a
stuartl@beast /tmp/foo/bar $ pwd
/tmp/foo/bar
stuartl@beast /tmp/foo/bar $ cd ..
cd: error retrieving current directory: getcwd: cannot access parent directories: No such file or directory
stuartl@beast /tmp/foo/bar/.. $ pwd
/tmp/foo/bar/..
stuartl@beast /tmp/foo/bar/.. $                     

>>6

No, I think there wasn't a filename in the file, so it tried to use the original minus .gz, except there was no .gz, so it unpacked the file with the same name as the original, and then deleted the original. That is to say, the unpacked file. This is so horribly retarded it's not funny.

I ended up using zcat, but of course "zcat YKK.kmz > YKK.kmz.decompressed" doesn't work, because the zlib tools obsessively check for file name extensions. Why they don't actually check the file itself to see if it's compressed or not is beyond me.

>>10 Indeed... that is screwy. file seems to have no problems identifying gzip files...

file extensions is a Microsoft thing mostly, why on earth Unix tools are obsessing themselves over that pasttime is beyond me.

The mg editor in OpenBSD segfaults if you press M-s C-g (e.g. start a non-incremental search, then abort it). I was surprised as hell when I first ran into that -- a program that comes with OpenBSD, segfaulting? Other than that though, I don't have any real bugs to report.