From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26344 invoked by alias); 13 Jul 2010 17:01:44 -0000 Mailing-List: contact zsh-users-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Users List List-Post: List-Help: X-Seq: 15186 Received: (qmail 20188 invoked from network); 13 Jul 2010 17:01:32 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 Received-SPF: pass (ns1.primenet.com.au: SPF record at benizi.com designates 64.130.10.15 as permitted sender) Date: Tue, 13 Jul 2010 13:01:04 -0400 (EDT) From: "Benjamin R. Haskell" To: Atom Smasher cc: zsh-users@zsh.org Subject: Re: zsh portable script In-Reply-To: <1007140253330.5546@smasher> Message-ID: References: <1007130241570.5546@smasher> <201007121737.21296.joke@seiken.de> <201007121745.20332.joke@seiken.de> <20100712161519.GO1499@prunille.vinc17.org> <1007140055140.5546@smasher> <1007140253330.5546@smasher> User-Agent: Alpine 2.01 (LNX 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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