Re: zsh portable script

["Benjamin R. Haskell" <zsh@xxxxxxxxxx>]

On Wed, 14 Jul 2010, Atom Smasher wrote:

> On Tue, 13 Jul 2010, Benjamin R. Haskell wrote:
> 
> > But, I don't recall ever needing root to read the battery status.  
> > (In the /proc/acpi subsystem that you're using, 
> > /proc/acpi/battery/BAT{0,1}/{info,state} are chmod 0444 on my laptop 
> > and netbook; same for the /sys/class/ stuff I used above.)  And on 
> > my FreeBSD webhost where I have pretty resticted access, I seem to 
> > be able to grab a lot of hardware-related info via sysctl.
> ==============
> 
> from what i've seen, linux permissions to anything in /proc depend on 
> the distro, but the same *info* is available to anyone with local 
> access on a bsd box via sysctl.
> 
> i'm more familiar with freebsd than linux. are you saying that 
> /sys/class/power_supply/BAT0/charge_* will be readable when 
> /proc/acpi/battery/BAT0/* isn't? if that's the case, i'll update the 
> script.

No.  I'm saying that I've never seen either one of those without full 
read permissions.  I've not tried them in multiple distros, but I'd be 
surprised if the commonly-used battery monitor 'widgets' required 
permissions beyond being a local account.


> > Are permissions the reason you suggest running it under cron? 
> > Otherwise, why not just regenerate in precmd()?
> ==================
> 
> on my bsd laptop i always have at least one mrxvt with ten shells 
> open. it seems to make sense to just have root get the info once per 
> minute and let the shells read it from a file, than have a bunch of 
> shells all invoking sysctl and all figuring out about the battery.

Are those many shells all frequently generating prompts?  precmd only 
runs once per prompt.


> i suppose it can be done without privileges, and it shouldn't burden 
> the machine; then i suppose it might make sense to get rid of the 
> battery script and put the logic into precmd. i suppose the worst case 
> is a hundred or so shells all working it out for themselves... that 
> shouldn't cause any problems... except if the machine is bogged down 
> and it takes that much longer to wait for a prompt that's hung while 
> something it needs to generate a battery notice is blocked (although 
> that risk is probably there already with the load monitor). i might be 
> able to add a short timeout, in which case it will just skip it... 
> something to think about, i guess.

Just as a quick benchmark, running my perl one-liner that I posted 
before in a tight loop 10000 times only takes ~30 seconds.  But that's 
including the overhead of starting up perl (which takes ~26 seconds on 
my machine).

$ date ; for l in {1..10000} ; perl -lnwe 'if($a){print$a/$_}else{$a=$_}' /sys/class/power_supply/BAT0/charge_{now,full} > /dev/null ; date
Tue Jul 13 12:38:29 EDT 2010
Tue Jul 13 12:38:58 EDT 2010
$ date ; for l in {1..10000} ; perl -lwe 'print 1' > /dev/null ; date
Tue Jul 13 12:39:02 EDT 2010
Tue Jul 13 12:39:28 EDT 2010

And, like I said, since it's a once-per-prompt thing, merely having a 
bunch of open shells doesn't necessarily increase the load.

Worst-case, the 'installation process' for using this through precmd 
(put this wherever it'll get sourced properly) seems better than the 
cron version (put this into root's crontab).

-- 
Best,
Ben