I’ve needed to see updated information related to nearby Bluetooth devices.

When using < hcitool scan > command, the output is not updated on every run, and even when used with the –flush option, the obtained results did not reflect the reality because the data is cached.

The solution seems to be < hcitool scan –flush –info > . This forces a detailed inquiry that is not cached.

One minor disadvantage would be the bigger amount unuseful data obtained, if we are looking only for the Bluetooth discovery name.

I’ve plugged a card reader in a USB socket on my Linux box and it’s not that trivial to know if it’s on /dev/sda or /dev/sdb or elsewhere. That can be even dangerous – I know someone who just erased his hard drive, trying to reformat a card. (Yes, he used a script that assumed the card reader is /dev/sda… and it worked so well on his old machine).

Here’s a method to find it out.

$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 00 Lun: 00
Vendor: ASUS     Model: DVD-E616A        Rev: 1.08
Type:   CD-ROM                           ANSI  SCSI revision: 05
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: ATA      Model: WDC WD2500KS-00M Rev: 02.0
Type:   Direct-Access                    ANSI  SCSI revision: 05
Host: scsi4 Channel: 00 Id: 00 Lun: 00
Vendor: GENERIC  Model: USB Storage-CFC  Rev: I19B
Type:   Direct-Access                    ANSI  SCSI revision: 00
Host: scsi4 Channel: 00 Id: 00 Lun: 01
Vendor: GENERIC  Model: USB Storage-MSC  Rev: I19B
Type:   Direct-Access                    ANSI  SCSI revision: 00
Host: scsi4 Channel: 00 Id: 00 Lun: 02
Vendor: GENERIC  Model: USB Storage-SMC  Rev: I19B
Type:   Direct-Access                    ANSI  SCSI revision: 00
Host: scsi4 Channel: 00 Id: 00 Lun: 03
Vendor: GENERIC  Model: USB Storage-SDC  Rev: I19B
Type:   Direct-Access                    ANSI  SCSI revision: 00

So here they are – the DVD-ROM, the hard drive, and readers for various types of cards. I’m interested in the SD card reader, so that would be the device identified by “scsi4 Channel: 00 Id: 00 Lun: 03″ – that’s 4:0:0:3 .
The second piece of magic

$ ls -l /sys/bus/scsi/drivers/sd/4:0:0:3/block*
lrwxrwxrwx 1 root root 0 2008-11-03 15:03 /sys/bus/scsi/drivers/sd/4:0:0:3/block:sde -> ../../../../../../../../../block/sde

So the SD card I’ve just plugged is in /dev/sde .

Did you ever saved file names in a bash parameter, and everything crashed down when they contain spaces?

The script started simple:

1
2
3

FILENAMES="log-file-1.txt log-file-2.txt"
cp $FILENAMES logs
rm $FILENAMES

When you have spaces, it becomes a nightmare. You’ll probably add a lot of quotes and try first something like this:

1
2
3

FILENAMES='"log file 1.txt" "log file 2.txt"'
cp $FILENAME logs
rm $FILENAME

Don’t try it at home, it does not work. Bash applies its dreadfully complex parameter expansion rules and you will end up useless errors about things called “log”, “file” and “1.txt” which cannot be found.

Solution: use arrays:

1
2
3
4
5
6

FILENAMES=(
"log file 1.txt"
"log file 2.txt"
)
cp "${FILENAMES[@]}" logs
rm "${FILENAMES[@]}"

They work only on bash. Here’s a page about how they work.

I just wrote a C application where I had to create a directory and let everyone read and write it.  That should be plain easy:

1

int result_code = mkdir("/usr/local/logs", S_IRWXU | S_IRWXG | S_IRWXO)

Apparently it’s a bit more complex, and I made a beginner’s error. I did forgot about the UMASK (http://www.tech-faq.com/umask.shtml).

Briefly: When you create a new file or directory, some of its permissions are restricted and cannot be set. Each process has a set of restrictions called the umask, and you must use the umask system call to disable or enable those restrictions. In my case, I set the umask to 0, that is no restrictions, created the directory, then restored the umask to its previous value:

1
2
3

mode_t process_mask = umask(0);
int result_code = mkdir("/usr/local/logs", S_IRWXU | S_IRWXG | S_IRWXO)
umask(process_mask);

The code above is not reentrant and it gets a bit more complex if your program is multithreaded, but you get the idea.

Do you have Bluetooth on your computer? Is it a Linux machine? For some weird reason, do you need it to have a different address?

If you answered yes to the above, here’s the magic command:

bccmd -d 0 psset -s 0 bdaddr 0×44 0×00 0×66 0×55 0×33 0×00 0×22 0×11

…and your Bluetooth device address (BDA) becomes 11:22:33:44:55:66. Of course, you will replace the underlined numbers with the actual address that you want to write.

It does not always work. You need bluez-utils 3, and you need a CSR chip in your computer or USB dongle. To find out, type hciconfig hci0 version and the manufacturer should be Cambridge Silicon Radio. Last time I checked, they had~70% market share, so you have a good chance of having one.

If you have more than a single device, use “bccmd -d 1 …” for hci1, and so on.

The option -s 0 stores it into the default memory, which is usually RAM – so the new address may be lost after reboot. Your chip may have various ROM stores – use -s 1 to -s 3. If you want specifically to write your new address in ram, use -s 4. Note that the store with the highest number has priority (e.g. if an address is stored in both RAM and flash, RAM has priority)

For gory details about programming CSR chips, you can get documents from http://www.csrsupport.com/