From: "Benjamin R. Haskell" <zsh@benizi.com>
To: Atom Smasher <atom@smasher.org>
Cc: zsh-users@zsh.org
Subject: Re: zsh portable script
Date: Tue, 13 Jul 2010 13:01:04 -0400 (EDT) [thread overview]
Message-ID: <alpine.LNX.2.01.1007131234090.4808@hp.internal> (raw)
In-Reply-To: <1007140253330.5546@smasher>
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
next prev parent reply other threads:[~2010-07-13 17:01 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-12 14:46 Atom Smasher
2010-07-12 15:35 ` Sebastian Stark
2010-07-12 16:10 ` Joke de Buhr
2010-07-12 16:17 ` Vincent Lefevre
2010-07-12 15:37 ` Joke de Buhr
2010-07-12 15:45 ` Joke de Buhr
2010-07-12 16:01 ` Frank Terbeck
2010-07-12 16:15 ` Vincent Lefevre
2010-07-12 16:18 ` Vincent Lefevre
2010-07-12 16:31 ` Joke de Buhr
2010-07-12 16:43 ` Vincent Lefevre
2010-07-12 16:22 ` Sebastian Stark
2010-07-12 16:39 ` Vincent Lefevre
2010-07-12 16:47 ` Frank Terbeck
2010-07-13 13:02 ` Atom Smasher
2010-07-13 14:29 ` Benjamin R. Haskell
2010-07-13 15:28 ` Atom Smasher
2010-07-13 17:01 ` Benjamin R. Haskell [this message]
2010-07-14 1:11 ` Atom Smasher
2010-07-14 11:45 ` Atom Smasher
2010-07-14 15:00 ` Atom Smasher
2010-07-13 13:43 ` François Revol
2010-07-20 14:01 ` Thorsten Kampe
2010-07-20 14:13 ` François Revol
2010-07-20 13:53 ` Thorsten Kampe
2010-07-20 14:07 ` François Revol
2010-07-21 8:34 ` Thorsten Kampe
2010-07-12 15:37 ` Vincent Lefevre
2010-07-12 16:06 ` Peter Stephenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.LNX.2.01.1007131234090.4808@hp.internal \
--to=zsh@benizi.com \
--cc=atom@smasher.org \
--cc=zsh-users@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).