Search Results: "cas"

11 November 2005

Uwe Hermann: Lots of 22C3 stuff

22C3 Logo Tim Pritlove Jens (argh, need some sleep!) from the Chaos Computer Club (CCC) has asked for more english blog posts about 22C3, the upcoming hacker conference in Berlin. So here you go. Reminder:
The 22nd Chaos Communication Congress (22C3) is a four-day conference on technology, society and utopia. The Congress offers lectures and workshops on a multitude of topics including (but not limited to) information technology, IT-security, internet, cryptography and generally a critical-creative attitude towards technology and the discussion about the effects of technological advances on society.
The congress (sub-titled "Private Investigations") will be held from December 27th to 30th, 2005, in Berlin, Germany. Some noteworthy bits and pieces: This is gonna be one of the highlights of this year, I'm really looking forward to the congress.

10 November 2005

John Goerzen: Amtrak's Best President in Years Fired

Yesterday, Amtrak's board of directors fired Amtrak president David Gunn. Here's something unusual about this firing. David Gunn actually was the best thing to happen to Amtrak in years. He improved the physical condition of the railroad's equipment, raised ridership, cut costs, and even ended this year with a net surplus despite a crippling brake problem on Amtrak's high-speed Acela equipment that took the entire fleet out of commision for most of the summer. The Amtrak board knew this too, and even testified to that fact before Congress a few months ago. The board, though, is made up of Bush appointees. You might remember that Bush's budget proposal contained a plan to bankrupt Amtrak as a way of "reforming" it. That failed to pass Congress, and David Gunn failed to be incompetant. So you have the odd case of firing David Gunn for improving things on the railroad. Yikes. I will be so glad when this administration is gone.

Sam Hocevar: [code] Finding a specific instance of a given day in the month in PHP

Andrew: to work out the fourth Thursday of the month, use this instead:
function nth_day($instance, $dow, $month, $year)

  $first_dom = date("w", mktime(0, 0, 0, $month, 1, $year));
  return 1 + ((7 + $dow - $first_dom) % 7) + 7 * ($instance - 1);
Or, using Zeller s rule and avoiding function calls:
function nth_day($instance, $dow, $month, $year)

  if($month < 3) $year--; $D = $year % 100; $C = (int)($year / 100); $m = 1 + (($month + 9) % 12);
  $f = 1 + (int)((13 * $m - 1) / 5) + $D + (int)($D / 4) + (int)($C / 4) - 2 * $C;
  $first_dom = $f % 7;
  return 1 + ((7 + $dow - $first_dom) % 7) + 7 * ($instance - 1);
Update: thanks to Andrew for spotting the error in the second version. Due to my misunderstanding of a hack in Zeller s rule, I had forgotten to decrease the year when the month was January or February. Also, PHP was not doing proper integer divisions and I had to cast results back to int despite all operands being ints.

Martin F. Krafft: Yes, Edd...

Dear Edd, you are not alone. I am going through the exact same process. No wonder that company never made it onto soil. Due to my tendonitis, at least they gave me a free case number. I'll try to call them, and if that ends up being a pain, I'll do as you did.

9 November 2005

Ian Murdock: No good deed goes unpunished

One of the big Debian stories of the week is that a company called Nexenta Systems has made a version of Ubuntu that’s based on OpenSolaris rather than the Linux kernel. Personally, I find the emergence of a Debian-based OpenSolaris distribution exciting, as it promises to vastly improve Solaris installation, packaging, and overall usability. Solaris is great technology with an incredible pedigree and some very compelling features (DTrace, in particular, sounds like a godsend, as I’m sure anyone who’s debugged kernel code via endless iterations of inserting printfs at strategic places would agree), not to mention that it’s now open source. However, when a Linux developer eager to have a look at all this neat new open source stuff boots up Solaris for the first time, it’s a bit of a throwback to an earlier time (not to mention the fact that apt-get is a hard habit to break..). And, so, I’m more than a little embarrassed at how certain members of the Debian community reacted to Nexenta’s work. The vitriol surprised even me, knowing as much as I know about how, uh, strongly the Debian community feels about certain issues. The issue in this case: Nexenta links GPL-licensed programs (including dpkg) with the Sun C library, which is licensed under the GPL-incompatible but still free software/open source CDDL license. Granted, Nexenta didn’t go about introducing themselves to the Debian community in the best way, and there may (may) be issues around whether or not what they are doing is permitted by the GPL, but couldn’t we at least engage them in a more constructive manner? In terms of the actual issue being discussed here, am I the only one who doesn’t get it? It seems to me the argument that linking a GPL application to a CDDL library and asserting that that somehow makes the library a derivative work of the application is, to say the least, a stretch—not to mention the fact that we’re talking about libc here, a library with a highly standard interface that’s been implemented any number of times and, heck, that’s even older than the GPL itself. It’s interpretations like this, folks, that give the GPL its reputation of being viral, and I know how much Richard Stallman hates that word. It’s one thing to ensure that actual derivative works of GPL code are themselves licensed under similar terms; it’s quite another to try to apply the same argument to code that clearly isn’t a derivative work in an attempt to spread free software at any cost. I’ve been a big GPL advocate for a long time, but that just strikes me as wrong.

Adeodato Sim : Learning

Though rarely, interactions of mine with other members of the Debian community have been punctually more aggressive than I would have liked, and I have (almost) always regretted afterwards. I have no doubts there’ll be further occasions in the future in which re-reading posts like these, together with remembering my feelings while reading some of the surrounding posts, will positively affect the outcome of the situation. NP: Ant nia Font, Patxanga

8 November 2005

Lars Wirzenius: Debian: My BTS spam rant

In recent times, the Debian bug tracking system has been suffering from slowness due to having to handle much spam. When it takes many hours to get a response from the system, usability and productivity hurt a lot. Having waited for a response for an hour again, I wanted to rant about the evilness of spammers, but luckily I did not. My aunt had called me and I had forgotten to press "send" (specifically, I had pressed control-backspace, instead of control-Enter). Oops. So, instead, I'd like to express my gratitude to Blars Blarson for coping with the BTS spam load. Despite occasional hickups, he and others make sure spam is not something BTS users need to worry about much. Thanks!

Wouter Verhelst: That's why C is usually preferred.

As I wrote earlier, I've been playing with m68k assembly lately. My first program looked somewhat like this:
.LFORMAT:
	.string	"%c"
	.text
	.align	2
.LENDL:
	.string	"\n"
	.text
	.align	2
	.globl	main
	.type	main, @function
main:
	link.w %a6,#-4		  allocate a stack frame		
	moveq #65,#-4(%a6)	  Move 65 (ASCII A) to an address on our
				  local address space
.L0:
	move.l #-4(%a6),-(%sp)    push the address to the stack
	pea .LFORMAT		  push the format to the stack
	jbsr printf		  run printf
	add.l #1,#-4(%a6)	  add one to the letter
	cmpi.l #91,#-4(%a6)	  compare with 91 (ASCII Z + 1)
	jblt .L0		  if less, jump to label L0
	pea .LENDL		  push format to the stack
	jbsr printf		  run printf
	unlk %a6		  clear stack frame
	clr.l %d0		  store 0 in %d0 (return value)
	rts			  return
	.align 2
	.size	main, .-main
IOW, print out the alphabet. Nothing spectacular, and it worked. Then I decided to take it one step further, and rather than using an address in memory, I switched to using a register, which is supposed to be a tiny bit faster—even if that shouldn't be noticeable in this case:
main:
	link.w %a6,#-4		  allocate a stack frame		
	moveq #65,%d0		  Move 65 (ASCII A) to %d0
.L0:
	move.l %d0,-(%sp)	  push the address to the stack
	pea .LFORMAT		  push the format to the stack
	jbsr printf		  run printf
	add.l #1,%d0		  add one to the letter
	cmpi.l #91,%d0		  compare with 91 (ASCII Z + 1)
	jblt .L0		  if less, jump to label L0
	pea .LENDL		  push format to the stack
	jbsr printf		  run printf
	unlk %a6		  clear stack frame
	clr.l %d0		  store 0 in %d0 (return value)
	rts			  return
	.align 2
	.size	main, .-main
(that's only the main section, but please assume the rest is still there:-) When I ran that, it bombed. It would print out the A, and then whole lines of nothingness. When I ran it inside gdb, it wouldn't even print out the A. It took me quite some time to figure out what went wrong.
main:
	link.w %a6,#-4		   allocate a stack frame		
	moveq #65,%d7              Move 65 (ASCII A) to %d7
.L0:
	extb.l %d7	
	move.l %d7,-(%sp)	   push the address to the stack
	pea .LFORMAT		   push the format to the stack
	jbsr printf		   run printf
	add.l #1,%d7		   add one to the letter
	cmpi.l #91,%d7		   compare with 91 (ASCII Z + 1)
	jblt .L0		   if less, jump to label L0
	pea .LENDL		   push format to the stack
	jbsr printf		   run printf
	unlk %a6		   clear stack frame
	clr.l %d0		   store 0 in %d0 (return value)
	rts			   return
	.align 2
	.size	main, .-main
%d0 is used to store a function's return value. If I store my data in %d0, then the next time I call a function, that data is overwritten. Since I do call a function inside my loop, that function overwrites my data every time. Using a different register (say, %d7) fixes this. Right. Apart from the fact that it's totally non-portable, assembly language also has quite a few quirks that you don't learn about when taught structured programming. It'd be nice if there were a document somewhere that would explain how C functions expect to be called. I found out most of the above through trial and error, and through compiling stuff with -save-temps and looking at the result, comparing it with the 68k Programmers' Reference Manual. That works, but it's not really efficient—and not totally error-proof, too.

7 November 2005

Wouter Verhelst: Compiling belpcscd

Dear lazyweb, please tell me:
wouter@country:~/debian/eID/belpic-2.3.13.full$ LC_ALL=C make
Making all in winscarp
make[1]: Entering directory  /home/wouter/debian/eID/belpic-2.3.13.full/winscarp'
[...]
Making all in belpcscd
make[1]: Entering directory  /home/wouter/debian/eID/belpic-2.3.13.full/belpcscd'
if g++ -DPACKAGE_NAME=\"belpcscd\" -DPACKAGE_TARNAME=\"belpcscd\" \
	-DPACKAGE_VERSION=\"2.3.13\" -DPACKAGE_STRING=\"belpcscd\ 2.3.13\" \
	-DPACKAGE_BUGREPORT=\"\" -DPACKAGE=\"belpcscd\" -DVERSION=\"2.3.13\" \
	-DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 \
	-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 \
	-DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FCNTL_H=1 \
	-DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_SYS_TIMEB_H=1 -DHAVE__BOOL=1 \
	-DHAVE_STDBOOL_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FORK=1 -DHAVE_VFORK=1 \
	-DHAVE_WORKING_VFORK=1 -DHAVE_WORKING_FORK=1 -DHAVE_STDLIB_H=1 \
	-DHAVE_MALLOC=1 -DHAVE_STDLIB_H=1 -DHAVE_REALLOC=1 -DHAVE_SYS_SELECT_H=1 \
	-DHAVE_SYS_SOCKET_H=1 -DSELECT_TYPE_ARG1=int \
	-DSELECT_TYPE_ARG234=\(fd_set\ \*\) -DSELECT_TYPE_ARG5=\(struct\ \
	timeval\ \*\) -DRETSIGTYPE=void -DHAVE_FTIME=1 -DHAVE_INET_NTOA=1 \
	-DHAVE_MEMSET=1 -DHAVE_SELECT=1 -DHAVE_STRCASECMP=1 -DHAVE_STRCHR=1 \
	-DHAVE_STRSTR=1  -I. -I.    -Wall -Dlinux -I. \
	-I../ObjectsMultiPlatform/Include -I/usr/include/PCSC  wx-config \
	--cppflags  -g -O2 -MT belpcscd-wxmainapp.o -MD -MP -MF \
	".deps/belpcscd-wxmainapp.Tpo" -c -o belpcscd-wxmainapp.o  test -f \
	'wxmainapp.cpp'   echo './' wxmainapp.cpp; \
then mv -f ".deps/belpcscd-wxmainapp.Tpo" ".deps/belpcscd-wxmainapp.Po";
else rm -f ".deps/belpcscd-wxmainapp.Tpo"; exit 1; fi
wxmainapp.h:88: warning: 'class MyApp' has virtual functions but non-virtual destructor
wxmainapp.cpp: In function 'int main(int, char**)':
wxmainapp.cpp:239: error: 'wxInitializer' was not declared in this scope
wxmainapp.cpp:239: error: expected  ;' before 'initializer'
wxmainapp.cpp:240: error: 'initializer' was not declared in this scope
make[1]: *** [belpcscd-wxmainapp.o] Error 1
make[1]: Leaving directory  /home/wouter/debian/eID/belpic-2.3.13.full/belpcscd'
make: *** [all-recursive] Error 1
wouter@country:~/debian/eID/belpic-2.3.13.full$ 
(line feeds added for readability) The offending bit of wxmainapp.cpp looks like:
int main(int argc, char **argv)
 
    wxApp::CheckBuildOptions(wxBuildOptions());
    wxInitializer initializer;
    if ( !initializer )
     
        fprintf(stderr, "Failed to initialize the wxWindows library, aborting.");
        return -1;
     
    MyApp *pTheApp= new MyApp();
    pTheApp->OnInit();
    
    while(1) sleep(1); /* run */
 
which doesn't look incorrect to me, but I could be wrong. class wxInitializer is defined in <wx/app.h>, which (according to gcc -E output) seems to be included (even if only indirectly), and its use is to initialize and cleanup the library automatically, so it would seem that upstream used it properly in the above bit of code. People with more C++/wx knowledge than me would make me very happy if they'd point out what's wrong. Even if they first need more info to do so. Thanks. Update: Seems I need wxbase-2.4-config, rather than wx-config. As the upstream makefile (which I'm ignoring for the time being) showed me. Really need to learn to trust other people's judgement some time...

Adam Rosi-Kessel: Boston City Council 2005 Endorsements

Hey, no one asked me, but here are my endorsements for tomorrow’s city council election: In any case, if you’re a Boston voter, be sure to participate tomorrow, whomever you choose to support.

Adeodato Sim : New email address

From now on, I’ll be using dato(at)the-barrel.org as my main address, instead of asp16(at)alu.ua.es. (But this second one, provided by my Uni, will continue to work for some more years, and not unlikely forever.) I was not that dissatisfied with the MX host for alu.ua.es, but it has been getting on my nerves on occasion during the last five years, so I decided it was better for my health to make the change. Kudos to Alberto Gonzalez Iniesta (agi@d.o) for being my postmaster from now on, since I really didn’t feel like running my own mailserver. The story behind the-barrel.org is certainly not unrelated to this Google search.

6 November 2005

Philipp Kern: Happy Meal Ethernet

Probably it’s very old, but hey I had a good laugh...
Actually, it is a Sun engineer joke. The 10 Mbps predecessor was a chip called the “Big MAC Ethernet” in this case, it was a mere pun, since MAC stands for Media Access Control, i.e. the Ethernet data-link layer. When they designed the 10/100 Mbps chip later on, they decided to turn the pun into a full-out joke, and they called it the “Happy Meal Ethernet.”
528 static void happy_meal_tcvr_write(struct happy_meal *hp,
529                                   void __iomem *tregs, int reg,
530                                   unsigned short value)
531  
532         int tries = TCVR_WRITE_TRIES;
533         
534         ASD((“happy_meal_tcvr_write: reg=0x%02x value=%04x\n”, reg, value));
535 
536         /* Welcome to Sun Microsystems, can I take your order please? */
537         if (!(hp->happy_flags & HFLAG_FENABLE))  
538                 happy_meal_bb_write(hp, tregs, reg, value);
539                 return;
540          
541 
542         /* Would you like fries with that? */
543         hme_write32(hp, tregs + TCVR_FRAME,
544                     (FRAME_WRITE   (hp->paddr << 23)  
545                      ((reg & 0xff) << 18)   (value & 0xffff)));
546         while (!(hme_read32(hp, tregs + TCVR_FRAME) & 0x10000) && --tries)
547                 udelay(20);
548 
549         /* Anything else? */
550         if (!tries)
551                 printk(KERN_ERR “happy meal: Aieee, transceiver MIF write bolixed\n”);
552 
553         /* Fifty-two cents is your change, have a nice day. */
554  
[Taken from drivers/net/sunhme.c in linux-2.6]

Andrew Pollock: [code] Obfuscating email addresses with JavaScript

So I got pet peeved by Carlos Laviola in relation to by recent pondering about how MacOS X's SSH agent starts up on login. Perfectly reasonable grounds for complaint. I have had people contact me in relation to blog posts in the past, so it's obviously not impossible. People know I'm a Debian developer and can put two and two together and wind up at db.debian.org. Anyway, I'm the first to admit that my blog probably has too many of the Weblog Usability Top Ten Design Mistakes (something for me to work on). To date, I've been avoiding plastering my email address on my website because I didn't want to get it harvested. I try and use a per-list email address for this reason as well, and I haven't enabled blog comments because of comment spam, and because I haven't been clever enough to implement comments with Blosxom full stop. So I started getting an idea for reversibly encrypting my email address on my blog after reading about Hashcash for Wordpress the other day. I first started playing around with the Vernam cipher in High School, when I wanted to easily reversibly obfuscate some data for something. I'd read about this cipher in a magazine or something and seen it implemented in Pascal (it's not exactly hard). So I happened upon the idea of encrypting my email address with the Vernam cipher. Turns out another chap's already got a page for encrypting and decrypting on the fly with JavaScript. It even generates the JavaScript for putting in your own web pages. I had to use a different key to avoid getting dollar signs in the encrypted string, as this confused the tripe out of Blosxom (and me for a while when I tried to figure out what was going wrong). Then I thought it'd be nice to explain to people who had JavaScript disabled what they might be missing out on, so I fiddled around with some DOM stuff, and had some text get displayed if JavaScript was disabled. When JavaScript is enabled, this text is replaced by the decrypted text. So of course, like the Wordpress Hashcash, this is largely relying on the inability of spam bots to grok JavaScript. Once they can, this obfuscation technique is all for naught. Meanwhile, you can email me bit more easily now if you get the urge. View the source of my blog for an example of the implementation.

5 November 2005

Joe Wreschnig: Paint a bikeshed!

So we’re trying to come up with a name for the Podcast subscriber/player part of Quod Libet. For obvious reasons, we don’t want to call it “Podcasts” any more than we called the paned browser “Please Sue Us For Patent Violations, Apple”. “Audioblogs” and “Blogcasts” both have the disadvantage that I’d want to claw out my eyes after seeing the word “blog” every time I click on the View menu. While we’ve gotten plenty of suggestions that are perhaps even worse than blogcast (”Webtap”, “Audio Planet”, “Quodcast”, “Oggregator”), the only marginally good one we’ve found is “Audio RSS” or “RSS Audio”. Which is to say, that’s the only pair I’ve liked. Anyone got a better idea? Update: Many people have informed me that there are actually podcasts out there using Atom, which I was unaware of. “Audio Feed” seems to be the most popular. “RoggSS” is even worse than the ones I mentioned.

Mike Hommey: Nasty bugs

Recently, I’ve been going through mozilla-firefox’s list of bugs and took a look to some of them. I got interested in #336411, since I’m regularly hit by this one myself (remember ? I said I got strange crashes with 1.5beta1). It appears that this strange crasher is in fact due to extensions using binary components. ColorZilla was the one killing my firefox. Why does it crash on debian’s firefox and not on upstream’s ? Simple : upstream’s is built with gcc 3.4, debian’s with gcc 4.0. Both C++ ABIs are incompatible. Now the question is : what can we do for that ? A quick fix could be to check before loading the component, if it’s linked to the incompatible libstdc++.so.5, but it’s almost as nasty as the bug itself… I’ve not really investigated possible solutions yet, but if you have some better ideas, you’re welcome. Another bug I got interested in is #211010 and its dupe, #256384. This one was really nasty. One of the kind I hate : bad programming practices. The interesting thing with this bug, though, was that it’s been revealed because of 3 other issues in 2 separate programs. The first issue is that autoconf decides to use echo 'something\c' over echo -n something when both ‘\c’ and -n are understood by echo. The second issue is that when giving some options with spaces to configure (like in --enable-optimize="-pipe -w -O2"), the associated variable gets backslashed spaces (i.e. "-pipe\ -w\ -O2") (thus, being an autoconf feature) The third issue is that the mozilla configure.in script tries to get rid of these backslashed spaces with echo $enableval sed -e 's \\\ g', triggering the nasty dash bug. A simple workaround, as stated in #256384 is to quote $enableval Now, for the dash bug itself. What happens with dash is that whenever you echo a ‘\c’ escape sequence, all subsequent echo commands stop printing after the first argument containing a backslash. For example echo test1 'test2\ttest3' test4 outputs test1 test2<tab>test3. In the case of our echo $enableval, since its value was -pipe\ -w\ -O2, it printed -pipe\ without any space after the backslash, so that it was not removed by the sed call. This value was then substitued in config/autoconf.mk.in to create config/autoconf.mk, where the ending backslash was interpreted as its shell meaning (continue on next line), thus breaking the variable, and build command lines. And for the bad programming practice ? The dash bug is due to a global variable that never got re-initialized, leaving the “terminate echo” (kinda) flag turned on (which is only checked when there is a backslash in the argument, since it is used to stop printing after, guess what… ‘\c’). No wonder why one of the first things you learn in programming classes is : never use global variables. (or at least, be very very very careful about what you do with them)

Dirk Eddelbuettel: Smokes, that ain't pretty

From the headers of a mail I just got:
Received: from master.debian.org ([146.82.138.7])
   by sccrmxc11.comcast.net (sccrmxc11) with ESMTP
   id <20051105044942s1100j9crge>; Sat, 5 Nov 2005 04:49:42 +0000
X-Originating-IP: [146.82.138.7]
Received: from wproxy.gmail.com [64.233.184.204]
   by master.debian.org with esmtp (Exim 3.35 1 (Debian))
   id 1E7EfR-0004zq-00; Mon, 22 Aug 2005 10:56:58 -0500
Received: by wproxy.gmail.com with SMTP id i34so340646wra
   for <edd©debian.org>; Mon, 22 Aug 2005 08:56:47 -0700 (PDT)
Translation for non-propellerheads: Someone with a Google Gmail account emailed me on August 22. It took eleven seconds to get from Gmail to Debian (once you consider the different timezones), but Debian's mail system took until today, November 5, to deliver it to Comcast, my ISP.Yikes. So if you, anonymous reader, happened to have emailed me lately and are still awaiting a reply ... please consider the possibility that I may not have received your mail yet. I should add that the underlying problem has been rectified at Debian's end as one of our hard-working admins stated yesterday.

4 November 2005

Steve Kemp: Name Overload

Name Overload?
First there was Debian Planet then along came the Planet Debian, unfortunate naming collision, but something we could mostly get used to and understand. If you’re not confused yet: well done. You soon will be: Guess which site that is? A third completely new name comprised of the two words “Debian” & “Planet”. WTF? Think that was fun? Lets try again. Stick with me: First there was Debian Help - now there’s another new site which is comprised of the two words “Debian” & “Help”: *Ugh* Now I’m personally of the opinion that competition is a good thing, but please people - can we all just get along without confusing our users/visitors? I’ll sidestep the whole trademark issue, in case my site is in trouble too ;)

Uwe Hermann: Google Creative Commons Search

Google now offers a license filter on their "advanced search" page which allows you to filter the search results according to a certain Creative Commons license. Even though Yahoo has been offering a similar facility for a quite while now, it's still great to see Google join the game, and it sure shows the importance of the Creative Commons. There's tons of Creative Commons materials out the (images, music, podcasts, videos, ...) — search facilities are essential now. (via Lawrence Lessig)

Clint Adams: People that hate zsh

Ted Leung wrote a positive review about Peter's and Oliver's book. Then came the entertaining comments. Here are two bits which made me giggle the most.
In no case should you be doing complex programming in a shell script!
Learning the POSIX standard shell is time well spent, IMO. Most shells implement it pretty well (e.g. bash, zsh, sh on most machines) and it's pretty powerful.

Adam Rosi-Kessel: randomplay 0.48 released

I’ve released randomplay 0.48. randomplay is my command-line ‘itch a scratch’ music player. It is most useful for maintaining a random shuffle over many sessions—for example, I use it to make sure I don’t ever hear the same song in any three month period. The new version fixes a bug that prevented randomplay from advancing to the next track when the player subprocess itself spawned a child process (e.g., with ‘play’ which spawns ‘sox’). I use a bit of a hack to kill the child task and it’s children, but the standard way of doing this in perl—kill HUP => -$$ doesn’t seem to work when randomplay is called from a shell script and the child process’ output is redirected to null. Here’s the code in question (with the fix to kill children and grandchildren recursively):
# KillAll recursively kills the request process ID and all of its children/grandchildren/etc.
# This is a bit of a hack--there should be a better way to do this, but I haven't found one.
# Normally, kill HUP => -$$ should do the job, except this doesn't work when randomplay itself
# is called from a shell script and all output from child processes is redirected to null.
# This subroutine assumes that shelling out to ps is going to work, which may not be totally
# safe--at the very least, it reduces the portability of the script.
# Any suggestions for a better way to do this are welcome.
sub KillAll  
  my $pid = shift;
  local $SIG HUP  = 'IGNORE';   # don't want to kill ourselves here--shouldn't happen, but just in case.
  if (open PS, "ps -o pid,ppid  ")  
     eof PS; # Force ps to run now. Otherwise it would run at the first read operation.
     kill HUP => $pid;
     foreach my $line (<PS>)  
       KillAll($1) if ($line =~ /^\s*(\d+)\s*(\d+)\s*$/ and ($2 eq $pid));
      
     close PS;
    else                  # if we can't read the process table, just try killing the child process group
    kill HUP => -$$;
   
 
Thanks to Christopher Zimmermann for the patch to kill children recursively.

Next.

Previous.