Drop down link menu, script-free!

This is just a tidbit, but I found it a real pain to find. So, here it is to save you the trouble. I wanted a drop-down menu in a web page, filled with links, and without using JavaScript. Why no scripts? It just seems to me like it's a simple enough thing that it shouldn't need it. But, all of the sources I found in my initial search either 1) just covered the drop down menu ("select" box) and didn't mention links, or 2) used JavaScript to implement the drop down menu. But, I finally found what I was looking for here. The site even has a little "wizard" where you can choose various settings and then generate the html. And, here is a little demonstration:

Please chooseFreeBSDPC-BSDPython

The code for which looks like this:

<form name="form1">
<select name="menu" onChange="location=document.form1.menu.options[document.form1.menu.selectedIndex].value;">
<option value=''>Please choose</option>
<option value="http://www.freebsd.org/">FreeBSD</option>
<option value="http://www.pcbsd.org/">PC-BSD</option>
<option value="http://www.python.org/">Python</option>
</select>
</form>

(... For simplicity, though, I left out the "style" part of the select tag above.)

Quick enable passwords for svnserve

I sure love Subversion. What a great tool. But, I'm more a user than an administrator of it. So, when I went to set-up another of my own repositories, I couldn't remember squat about how I'd done it before. I do recall there was a lot of reading involved. (With great power comes ... longer manuals. :p) First, you must create the new repository with a command like this, "svnadmin create /svnrepos/brandnew". And, in this case, the part that's difficult to remember is how to enable net access and password protection. So, here's the short answer, diff'd from my previous effort:

# diff /svnrepos/someapp/conf/ /svnrepos/brandnew/conf/
diff /svnrepos/someapp/conf/passwd /svnrepos/brandnew/conf/passwd
6a7,8
> kace = s3cret
> jack = pr1vate
diff /svnrepos/someapp/conf/svnserve.conf /svnrepos/brandnew/conf/svnserve.conf
12,13c12,13
< # anon-access = read  
< # auth-access = write  
---  
> anon-access = none
> auth-access = write
20c20
< # password-db = passwd  
---  
> password-db = passwd
32c32
< # realm = My First Repository  
---  
> realm = main

... And, yes, it's done per repository. After making changes like the above to the configuration files for the new repository, you just need to start (or restart) svnserve. On FreeBSD, that should be as easy as "/usr/local/etc/rc.d/svnserve start" (... with "svnserve_enable='YES'" already in "/etc/rc.conf"). ... Also, you must have either created an 'svn' user or set another user to run the server as -- again using shell variables in "/etc/rc.conf", as per the appropriate variables found in the start-up script. ... Yeah, and you probably want to run something like "chown -R svn /svnrepos/brandnew" on your new repository so the svnserve process can actually make changes to it.

Details, details. Anyway, those configuration files were the part that took some research. Enjoy.

X on FreeBSD amd64

I've gotten an amd64 desktop and started running FreeBSD/amd64 on it. I've had an amd64 capable machine before, but chose to run the i386 version of FreeBSD on it so I could use Nvidia drivers and have hardware accelerated graphics. (I think the linux flash player only runs on i386 too, but am not sure.)

So, I installed without issue. I included X in the installation and it worked fine. But, as I often do on new machines, I updated the ports tree and then began to install everything else I wanted and upgrade what I had there already, including X.

Then X wouldn't start correctly anymore. I had run it the first time without creating any config file. But, now it really wasn't happy. It would kind of hang, pointer wouldn't move and even <Ctrl>-<Alt>-<Backspace> wasn't working. (But, the computer wasn't hung. <Ctrl>-<Alt>-<Delete> still worked!) So, I created a config file (using one of those utilities, maybe 'x86config'). Still didn't work right. Then I started the process of changing different, random stuff in the config file to see if it would start working. It wouldn't.

So, I resorted to Go0gle, something I should have done alot sooner. I found this config file out there and it helped solve the problem pretty quickly. These two options in the "Server Layout" section did the trick:

Option "AllowEmptyInput" "false"
Option "AIGLX" "true"

Well, the "...EmptyInput" option rings a bell. :/ I don't really know much more. Is this a quirk of the amd64 platform? (But, if so, why did the release packages work without a config file?) Is this a quirk of the newer version of X?

Answers are hard to find when it comes to X. Be happy with a working config file.

gotbsd.net: technical difficulties ... resolved

The issues with gotbsd.net have been resolved. Yay!

Waiting for box to come back

This is a quick and easy tip, for the detail-oriented! Say a computer that you're interested in is down for some reason. Maybe you've rebooted it and you want to know the second that it's back on-line. Or maybe it's someone else's box and it's down and you (again) want to know as soon as it's up. You could just run ping and watch for the responses, but that's more traffic than is needed for a box that you know is down. And, what if you know it's going to be a while?

'ping' has a lot of great options and we can use those to send fewer packets and then quit as soon as the box responds. (So, if you're getting coffee or something when it comes back on-line, you're not just pinging it all day.) Here's the solution:

$ /sbin/ping -i 4 -o 10.1.2.3 ; echo -e '\a'
PING 10.1.2.3 (10.1.2.3): 56 data bytes

--- 10.1.2.3 ping statistics ---
35 packets transmitted, 1 packets received, 97.1% packet loss
round-trip min/avg/max/stddev = 2.856/2.856/2.856/0.000 ms

The '-i' option sets the wait between packets in seconds, which would have been 1 second by default. This was for an important box that I rebooted and needed to check as soon as it came back up. If the box was going to be down for a longer and/or unknown amount of time, you could set that higher, like 30 seconds. The '-o' option is what causes ping to exit as soon as it gets one good response. Then, I added the console beep ("echo -e '\a'") after the ping so I could go about something else and still be notified. (That form works for bash and sh, at the least.)

Hey, and I saved over 100 unnecessary packets! :) I did say this was for the "detail-oriented."

Seriously, though, I don't like the default behavior of ping -- going on forever until you stop it. I use it often and get tired of pressing '<Ctrl>-c' all the time. That's why I alias 'ping' to 'ping -nc 5'. (And, also why I used the full path above, to escape my own alias.) I think people mostly use ping for two different things: to measure the network delay to another host and to check reachability or presence a host. My alias does a reasonable job for both of those cases. The present case is what I'd consider to be a special and less common usage: waiting for a host you know is normally reachable to come back on-line.

bash history grep alias

In a previous post, I introduced many useful bash shell aliases that I use. There's one that I've made a notable improvement to that I'd like to share. If you spend a lot of time on the command-line and use bash, you should really try this out.

'bhg', for "bash history grep," was a pretty simple alias to search through your bash history file. Previously, I used it like this:

alias bhg='cat $HISTFILE | grep'

The deficiency I found with it is that I often keep a shell open for days (even weeks!) at a time. So, I may be searching for a command that has not been written to the history file. What I'd like, then, is one 'bhg' alias that will find any command from my current shell history or my history file. The bash 'history' built-in will give you all of the current shell's command history. We just need to strip out the line numbers -- easy enough with 'sed' -- and then con-'cat'-enate that with the history file and we're in business. So, this is what I use now to accomplish all that:

alias bhg="history | sed 's/^ *[0-9]* *//' | cat $HISTFILE - | grep "

As I mentioned before, if you find this useful, you can make it even more useful by increasing the history size variables in your ".bash_profile". Namely, 'HISTSIZE', which controls how many lines of current history will be available via the history command, and 'HISTFILESIZE', which controls how many lines of command history will be written to your history file. They both default to 500, I think, which I've found to be way too small for my purposes.

"Error ... ../php.vim" Update

I wrote about this annoying "E10" error once before. It doesn't crash anything, it just gives a long error message and pause (/"Enter to continue") every time you open a php file in vim with syntax high-lighting enabled. It's probably triggered by other syntax rule files as well. (Several variants of vim are found in FreeBSD ports under the editors category.)

I wrote to the port maintainer and he pointed out that the "problem" file, "php.vim", is not modified by the ports system. So, I poked around the vim site -- I couldn't possibly be the only person who's run into this -- and I found a setting that can prevent this problem. The E10 error message is described here. The issue is simply a vi-compatibility option that prevents vim from allowing backslashed line-continuations in sourced files (like the php.vim syntax rules script). The error will no longer appear when you disable this option with this vim command:

:set cpo-=C

... which can be put into your vimrc file. Which should be "~/.vimrc" for your personal startup file and "/usr/local/share/vim/vimrc" for the system-wide file. (You may need to create the system-wide file.) ... A much more elegant solution than modifying the php.vim file!

With great functionality comes great complexity.

Still, there's a better solution that avoids the error from the beginning regardless of the 'cpo' options: the vim developers ought to modify the php.vim file to remove the backslashed line-continuations. I'm all for neatly formatted code -- but not at the expense of user irritation!