A Handy CSS Debugging Snippet

From A Handy CSS Debugging Snippet:

* { outline: 2px dotted red }
* * { outline: 2px dotted green }
* * * { outline: 2px dotted orange }
* * * * { outline: 2px dotted blue }
* * * * * { outline: 1px solid red }
* * * * * * { outline: 1px solid green }
* * * * * * * { outline: 1px solid orange }
* * * * * * * * { outline: 1px solid blue }

This code, if placed in your stylesheet, outlines every element on the page with colored boxes. I like this because it's simple, and I learned something from it. I had no idea that you could use an asterisk for a css selector. Then, the idea of stringing them together to represent the elements that are most deeply nested with different colored outlines. Pretty slick!

I will probably still use the many functions in the Outline menu of the Web Developer Extension for Firefox, and the Internet Explorer Developer Toolbar, for most of my everyday outlining-for-debugging needs. There are also bookmarklets out there to do this type of thing. But, this snippet deserves a spot in my toolbox, because it seems like it could could come in handy someday.

Disabling Message Center in RealPlayer via a simple registry edit

Random tidbit of potentially useful information...

From a comment by Wulf on the Google Operating System blog:

While playing around in my Registry, I found an interesting entry from RealPlayer.

If you change

HKEY_CURRENT_USER\Software\RealNetworks\Msg\
Preferences\Frequency > (default)

from 1 to 0, the 'Message Center' (read: ads) won't come up anymore...

I haven't tried this, as I so rarely use RealPlayer that I don't even remember the annoyance that this tip claims to prevent. But, I did go ahead and make this registry value change, in the hopes that someday, something might less annoying. :)

I actually took this opportunity to try out REG.EXE, the "Console Registry Tool for Windows" (it came with Windows XP Pro), which I've never gotten around to messing with... So this is how I changed this particular registry key:
reg add
HKCU\Software\RealNetworks\Msg\Preferences\Frequency
/ve /d 0

screen in cygwin needs System attribute on SockDir files

This will not be of use to many, if any, but I expended effort trying to figure out how to solve this today, so I'm posting it here for future reference, if nothing else.

Today, at work, I ssh'd to my home computer, and tried to run 'screen -r -d', to reattach to an existing session of gnu screen at home. Here's what happened:

$ screen -r -d
There is no screen to be detached.

I knew this was not true, so I tried this:
$ screen -list
No Sockets found in /tmp/uscreens/S-myusername.

I didn't believe it, because I knew I had an existing session open, so I looked for myself:
$ ls -l /tmp/uscreens/S-myusername/
total 2
-rw------- 1 myusername None 54 Jul 24 14:35 1696.tty0.spugbrap-home
-rw------- 1 myusername None 54 Aug 2 14:19 3500.tty0.spugbrap-home

I saw it right there, so I looked to see if one of the processes that I had running in my existing screen session was still running:
$ ps | grep perl
3204 368 3204 1760 13 1003 14:20:05 /usr/bin/perl

Sure enough, there it was... So, I took a look at my SockDir on my laptop, at work, to see if permissions might be involved in some way:
$ ls -l /tmp/uscreens/S-myusername/
total 3
srwx------ 1 myusername None 53 Aug 2 14:18 2568.tty1.dave-laptop
srw------- 1 myusername None 53 Jul 4 01:05 3600.tty1.dave-laptop
srw------- 1 myusername None 53 May 15 15:42 960.tty1.dave-laptop

Ah hah! There was a difference! The 's' at the beginning of the permissions list on my laptop's SockDir contents, but not on my home machine's.

So, I went searching for what the heck that 's' stands for, since usually, if anything, I either see an 'l' (L) or a 'd'. I checked the help, info, and man pages for 'ls' and 'chmod', but didn't find anything that actually matched this flag. The closet thing was 'suid + executable', but when I tried to chmod that onto one of my files, the permissions showed '-rws------', which is not what I was looking for.

A google search or two, for things like 'srwx------', 'srw-------', 'srwx srw', 'cygwin srw', etc. didn't turn up anything useful - at least not in the first pages of results.

I tried looking at my laptop's SockDir in windows explorer, and looking at the advanced security properties of one of the files. Nothing looked interesting. Then I looked at it from a command prompt (4nt), and saw this:
[c:\]dir c:\cygwin\tmp\uscreens\S-myusername
[...]
0 bytes in 0 files and 2 dirs

Oops, let's try with 'attrib' instead of 'dir':
[c:\]attrib c:\cygwin\tmp\uscreens\S-myusername
__SA_ C:\cygwin\tmp\uscreens\S-myusername\2568.tty1.dave-laptop
__SA_ C:\cygwin\tmp\uscreens\S-myusername\3600.tty1.dave-laptop
__SA_ C:\cygwin\tmp\uscreens\S-myusername\960.tty1.dave-laptop

Ah hah! The 'system' and 'archive' attributes were set on these files. So, I verified that these flags were NOT set on the files on my home machine:
$ attrib "c:\\cygwin\\tmp\\uscreens\\S-myusername\*"
C:\cygwin\tmp\uscreens\S-myusername\1696.tty0.spugbrap-home
C:\cygwin\tmp\uscreens\S-myusername\3500.tty0.spugbrap-home

Sure enough, there's the difference. So, I set the 'system' attribute on those files (didn't bother with 'archive' attribute, though I'm not sure what causes it to be there on my laptop but not on my home):
$ attrib +"c:\\cygwin\\tmp\\uscreens\\S-myusername\*"

Verified that it worked:
srw------- 1 myusername None 54 Jul 24 14:35 1696.tty0.spugbrap-home
srw------- 1 myusername None 54 Aug 2 14:19 3500.tty0.spugbrap-home

Then, I tried connecting to my existing session, and it succeeded.

While preparing this post, I experimented a little bit more, and noticed that, for some reason, my home pc is not creating these screen socket files with the required 'system' attribute at all, anymore. I'm not sure why this is happening, now, because I can't think of anything I've done, recently, that might have caused any different behavior as far as permissions and such.

I will post again if I figure this out, but for now I am content with adjusting the attribute manually. In theory, I can keep each screen session alive until my next reboot (which is rare), so I shouldn't have to do too many manual adjustments like this. I also welcome any comments on how to solve this problem, or any other useful tips for effectively using gnu screen in cygwin.