Re: [dwm] [dmenu] OPTFLAGS in config.mk + patch
Daniel Bainton --> dwm (2009-04-08 17:05:28 +0300):
> 2009/4/8 Jan Blazek :
[...]
> > # flags
> > CPPFLAGS = -DVERSION=\"${VERSION}\" ${XINERAMAFLAGS}
> > -CFLAGS = -std=c99 -pedantic -Wall -Os ${INCS} ${CPPFLAGS}
> > +OPTFLAGS = -Os
>
> This wont make any difference, you can't pass it from the command line
> like this anyway.
> You're overwriting OPTFLAGS here all the time to -Os.
No, command arguments override ordinary assignements in makefiles:
$ cat Makefile
A=a
t:
@echo $A
$ make
a
$ make A=b
b
This is required by SUS (IIRC); at least BSD and GNU make(1) work like
this.
Regards, Jukka
--
This email fills a much-needed gap in the archives.
Re: [dwm] Java patch
Anselm R. Garbe --> dwm (2008-04-27 14:45:58 +0200): > On Sat, Apr 26, 2008 at 02:05:34PM -0300, Luiz wrote: > > I've made a simple hack (based on the xmonad one) to get Java > > applications (which use the XToolkit/XAWT backend) working. With this > > patch you won't get any grey windows anymore. > > > > The patch for dwm-4.9 is available here: > > http://files.luizribeiro.org/dwm/dwm-4.9-java.diff > > Does this really work for everyone? I remember I evaluated a > similiar solution last year without success. ;( It doesn't work for me. Just tested with jdk 1.5.0 and netbeans... Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] dmenu, slock patches; slock DPMS crash
Peter Hartlich --> dwm (2008-04-10 19:07:34 +0200): > Hi Jukka, > > > BTW, $exe should also be quoted (see attached patch). > > But with unquoted $exe you can e.g. enter: firefox suckless.org True. Hmm, changing dmenu to output a properly quoted shell string and then using `eval exec $exe' is probably too much effort for supporting command names with whitespace characters... Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] dmenu, slock patches; slock DPMS crash
Anselm R. Garbe --> dwm (2008-04-08 10:57:20 +0200):
> Hi,
>
> On Mon, Apr 07, 2008 at 10:51:15PM +0200, Peter Hartlich wrote:
> > dmenu_run.patch:
> > - replace $* with "$@" so dmenu_run -p "foo bar" works
>
> I applied this patch with Jukka's remark.
Thanks.
BTW, $exe should also be quoted (see attached patch).
Cheers, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
diff -r 787ec648ffef dmenu_run
--- a/dmenu_run Wed Apr 09 23:32:46 2008 +0100
+++ b/dmenu_run Thu Apr 10 17:31:51 2008 +0200
@@ -1,2 +1,2 @@
#!/bin/sh
-exe=`dmenu_path | dmenu ${1+"$@"}` && exec $exe
+exe=`dmenu_path | dmenu ${1+"$@"}` && exec "$exe"
Re: [dwm] dmenu, slock patches; slock DPMS crash
Hello,
Peter Hartlich --> dwm (2008-04-08 00:22:13 +0200):
[...]
> >> uptodate() {
> >> - test ! -f $CACHE && return 1
> >> + test -f "$CACHE" &&
> >>for dir in $PATH
> >>do
> >> - test $dir -nt $CACHE && return 1
> >> + test ! $dir -nt "$CACHE" || return 1
> >>done
> >> - return 0
> >> }
>
> > Why? This is equivalent...
>
> Besides the quoting, one and a half lines less. :)
;-) (I missed the quoting; that's fine of course.)
> > Not all sort(1)s have a -u option.
>
> Whoops, sorry then. I had checked SuS, heirloom toolchest, the autoconf
> portability manual and DJB's portability notes and none of them mentioned
> a missing -u option.
http://www.suckless.org/pipermail/dwm/2007-February/002128.html
Regards, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] dmenu, slock patches; slock DPMS crash
Hello,
Peter Hartlich --> dwm (2008-04-07 22:51:15 +0200):
[...]
> diff -r 612d48273009 dmenu_run
> --- a/dmenu_run Thu Apr 03 21:56:19 2008 +0100
> +++ b/dmenu_run Mon Apr 07 22:17:29 2008 +0200
> @@ -1,2 +1,2 @@
> #!/bin/sh
> -exe=`dmenu_path | dmenu $*` && exec $exe
> +exe=`dmenu_path | dmenu "$@"` && exec $exe
Makes sense. I'd prefer
exe=`dmenu_path | dmenu ${1+"$@"}` && exec $exe
though to make sure dmenu is not passed an empty argument in case
dmenu_run is called without arguments.
> diff -r 612d48273009 dmenu_path
> --- a/dmenu_path Thu Apr 03 21:56:19 2008 +0100
> +++ b/dmenu_path Mon Apr 07 22:17:24 2008 +0200
> @@ -3,24 +3,24 @@
> IFS=:
>
> uptodate() {
> - test ! -f $CACHE && return 1
> + test -f "$CACHE" &&
> for dir in $PATH
> do
> - test $dir -nt $CACHE && return 1
> + test ! $dir -nt "$CACHE" || return 1
> done
> - return 0
> }
Why? This is equivalent...
> if ! uptodate
> then
> for dir in $PATH
> do
> - for file in "$dir"/*
> + cd "$dir" &&
> + for file in *
> do
> - test -x "$file" && echo "${file##*/}"
> + test -x "$file" && echo "$file"
> done
Hmm, for few directories and lots of files this is indeed slightly
faster.
> - done | sort | uniq > $CACHE.$$
> - mv $CACHE.$$ $CACHE
> + done | sort -u > "$CACHE".$$ &&
> + mv "$CACHE".$$ "$CACHE"
>
> -cat $CACHE
> +cat "$CACHE"
Not all sort(1)s have a -u option. However, the '&&' is a good idea,
as is the quoting.
Cheers, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] focus changes with recent dwm
Hello, Anselm R. Garbe --> dwm (2008-04-07 11:06:20 +0200): > Hi Jukka, > > you are right, I removed the selscreen stuff, but if there are > still some classical multihead users I would reconsider this > decision. I'd appreciate to see it backported if it's not too much work. Xinerama doesn't seem to fit everybody's needs... ;-) Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
[dwm] focus changes with recent dwm
Hi, I haven't really followed dwm development during the latest weeks or even months. Somewhere between 4.7 and current tip focus behaviour changed: when starting a program on a different screen (e.g. running `DISPLAY=:0.1 xclock' from terminal on screen 0), focus now moves to that program. Previously it did not move. Is this considered a feature? Is there an easy way to get the old behaviour back? Glancing at the code revealed that selscreen is gone... Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] I like Dmenu a little simpler
Joerg van den Hoff --> dwm (2008-03-09 11:22:54 +0100): [...] > I would think a similar modification should be done "upstream": enforcing > `sh' explicitly seems much better than assuming everybody has set SHELL to > `sh'. Sure. But "upstream" already does enforce /bin/sh (see dmenu_run). Cheers, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] dmenu_run problem
I notice that this has been reverted in the meantime, but just as a comment: Szabolcs Nagy --> dwm (2008-02-11 12:08:20 +0100): > there was recently two dmenu problems on irc and both was due to > 'name=value' does not work in certain shells (csh, tcsh, ..) > > i'm not a shell expert and didn't check the standard, but this works fine: > > - exe=`dmenu_path | dmenu $*` && exec $exe > + set exe=`dmenu_path | dmenu $*` && exec $exe This does not do what you want for Bourne-compatible shells: "set exe=`cmd`" sets the first positional parameter ($1) to "exe=cmd_output" (where cmd_output is the output of the command cmd) and does _not_ set $exe. Thus exec is executed without any arguments, i.e. the program you selected using dmenu is not run. Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] mail notification again
Peter Vollmar --> dwm (2008-01-19 21:51:17 +0100):
> Thank you so much Jukka, your script works great. I've tried to simplify
> it to fit my needs, now I have everything in one script. Apart from the
> in.sh with FIFO solution, I have also managed to incorporate your script
> in my .xinitrc in the usual dwm loop. (I didn't know how to get rid of
> the [if $MCK...] clause though, since I don't need the "no" option here,
> but anyhow, it's working...)
Just remove the whole line and the corresponding `fi' command.
> I have noticed that when running with the FIFO option, upon dwm shutdown
> some running programs get killed before they can save their
> configuration (resulting in repeated file corruption in some cases!).
What programs?
> This doesn't seem to happen with the direct loop, although dwm sometimes
> takes about 5-10 seconds to close down all programs (or is it the X
> server?).
> Can you explain this behaviour?
I assume that by "direct loop" you are referring to the status bar
code snippet from the dwm README. If your using something like that,
calling `sleep n' after each call to your output printing commands,
and exit dwm using its quit() function, you'll have to wait up to n
seconds until the X server shuts down, depending on for how long the
current `sleep n' command has already been running. When using the
FIFO approach, the X server shuts down as soon as you tell dwm to quit
(which is the correct behaviour IMHO).
I don't know why this causes corrupted files for you. Maybe your
programs somehow depend on those "up to n seconds", but such a setup
would be broken IMHO because you might quit dwm after `sleep 1' has
terminated but before the next loop iteration has started, thus shutting
down the X server immediately as if you had use the FIFO approach.
You'd probably see the same corruption then.
> By the way, is "dwm -q" the same as "killall dwm" (to use in a shutdown
> script)?
$ dwm -q
usage: dwm [-v]
$ killall dwm
ksh: killall: not found
> Anyway, here's my most recent .xinitrc, running dwm without FIFO, and
> showing uptime and date every 7 seconds and the number of mails calling
> "fetchmail -c" every 280 seconds in the output bar.
>
> --
> xhkeys
> feh --bg-scale /tmp/losung.pnm
> while true; do
>
> : ${DELAY:=40} \
> ${MCK:=yes} \
> ${MCK_INT:=7} # if $MCK != no, run mail check every $(( $MCK_INT * $DELAY
> )) seconds
>
> main()
> {
> local now loadavg
> local i=0 nmsgs=
>
> # loop forever
> while :; do
> now="$(date +'%a %d %b %R')"
> loadavg="$(uptime | sed 's/.*,//')"
>
> if [ $MCK != 'no' ]; then
> if [ $i -eq 0 ]; then
>
> nmsgs="$(fetchmail -c --sslproto tls | sed 's/(//' | awk '{print
> $1-$3}')"
> fi
> i=$(( ($i+1) % ${MCK_INT:?} ))
> fi
>
> echo "$loadavg" "$now" "$nmsgs"
> sleep ${DELAY:?}
>
> done
> }
>
> main
> sleep 1
> done | dwm
Hmm, this doesn't make much sense: main() never returns, thus `sleep 1'
never gets executed, and if it did, you really wouldn't need to redefine
main() on every loop iteration. It's quite constant ;-)
I'd suggest you to read about basic shell programming if you want to
learn how to do this correctly...
Cheers, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] mail notification again
Peter Vollmar --> dwm (2008-01-15 12:06:19 +0100):
[...]
> So in short, I haven't been able to implement your "loop in a loop"
> script in my .xinitrc, because I don't understand much of its syntax.
> Can you please help me?
>
> Here's your snippet again:
>
> for (i=0; ; i=(i+1)%m) {
> execute non-fetchmail commands
> if (!i) execute fetchmail
> sleep for n seconds
> }
>
> And this is my .xinitrc:
>
> ...
> while true
> do
> echo `uptime | sed 's/.*,//'` `date +'%a %d %b %R'` `fetchmail -c
> --sslproto tls |sed 's/(//'|awk '{print $1-$3}'`
> sleep 2
> done | dwm
Rereading your original message again I noticed that you're using the
in.sh script I once posted to this list (IIRC). Have a [1]look at the
version I'm currently using, maybe it fits you needs: it runs some
commands (date, uptime) every $DELAY seconds, and - iff $MCK is not
set to 'no' - a mail check command every $DELAY * $MCK_INT seconds.
DELAY, MCK and MCK_INT can be overriden using environment variables,
i.e. you can override the defaults given in the script (10, 'no', 6)
like this:
MCK=yes DELAY=5 MCK_INT=12 /path/to/in.sh /path/to/fifo
The mail check command (`mck -q') used in the script is another script
which calls `fetchmail -c' and pipes its output through [3]mck.awk.
HTH, Jukka
[1] http://salmi.ch/cgi-bin/cvs/tools/dwm/in.sh
[2] http://salmi.ch/cgi-bin/cvs/tools/mail/mck
[3] http://salmi.ch/cgi-bin/cvs/tools/mail/mck.awk
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] mail notification again
Peter Vollmar --> dwm (2008-01-10 14:12:30 +0100):
> Am 10 Jan schrieb Jukka Salmi:
[...]
> > Run all commands except fetchmail every n seconds in a loop as you
> > already do, and fetchmail only every m loop iterations. Thus fetchmail
> > will be executed only every mn seconds.
> yes, that sounds like what I need, thanks also to Martin and Antony. I
> don't have cron,
Hmm, is "Ubuntu Christian Edition" required to ship totally daemon-free?
;-)
> so I'm interested in a separate loop (or distinct loop
> iterations), but I don't know how to do it :-)
try e.g. something like the following C-like pseudo-code:
for (i=0; ; i=(i+1)%m) {
execute non-fetchmail commands
if (!i) execute fetchmail
sleep for n seconds
}
HTH, Jukka
> Computer: www.vollmar.ch/linux
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] mail notification again
Peter Vollmar --> dwm (2008-01-09 23:05:49 +0100):
> Hi everybody,
> Following the discussion earlier in December I've found a good solution
> with 'fetchmail -c' showing the number of new messages in the status bar. The
> code copied from Martin Sander's comment is:
>
> fetchmail -c|sed 's/(//'|awk '{print $1-$3}'
> 1
Hmm, this doesn't really work if you configure fetchmail to check more
than one folder... And, BTW: if you use more than one of grep, sed and
awk in a single pipline, you have almost always done something wrong
;-)
> The problem is that fetchmail accesses the mail server as often as the
> other services in the status bar are accessed - usually every few
> seconds, which is unnecessarily often for imap! I've changed it to 60
> seconds, which is about the lowest reasonable for the 'date' and 'uptime'. Is
> there anything we can do about this?
Run all commands except fetchmail every n seconds in a loop as you
already do, and fetchmail only every m loop iterations. Thus fetchmail
will be executed only every mn seconds.
HTH, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] dmenu corruption?
Peter Vollmar --> dwm (2008-01-09 12:18:54 +0100): > Hi dwm friends > I am new to the list and have been using dwm for about a month. It's a > great program. Now and then I get a strange behaviour with the command > ALT+p which is supposed to give a list of all programs and then execute > one. (I don't even know if this is what you call dmenu, but anyway it's > great and amazingly simple to use.) > Anyhow, what happens is that it won't show the programs any more, there > is just a grey bar, but it will still execute one if I type the correct > name. I have had a few computer crashes recently, and I wonder if it's > due to that. Has anyone got an idea what is happening? Try removing ~/.dmenu_cache. HTH, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] OT: which or type or what else?
markus schnalke --> dwm (2007-12-08 21:40:52 +0100): [...] > I'm writing some shell scripts these days, and a common task is to > check if a particular program is installed (for example `convert'). > > How is this check done in a sane and portable way? > > > The two alternatives that I have in mind are: > > which convert >/dev/null > if [ $? -ne 0 ] ; then > exit 1 > fi > > and > > type convert >/dev/null > if [ $? -ne 0 ] ; then > exit 1 > fi > > > `type' is a builtin in `bash', but not in `sh'. Maybe it is available > as external program aswell. > Which systems do have `which'? Use the `command' utility (which is a builtin in all bourne-compatible shells I've seen so far) with its -v or -V option. This is the way to go "on systems supporting the User Portability Utilities option" according to SUSv3. SUSv3 also mentions - as an XSI extension - is the `type' utility. The `which' utility is not mentioned at all. HTH, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] struct Client declaration
Tuncer Ayaz --> dwm (2007-10-10 12:43:37 +0200): > Is it strictly needed to move the declaration of Client after #include > config.h > as done within changeset http://www.suckless.org/hg.rc/dwm/rev/bc0929d03388? > > This breaks nmtile.c compilation as Client is unknown in config.h. Yes, this broke the way I use additional layouts, too. As a quick hack, I moved the layout stuff from config.h to a new file which I include from dwm.c after `struct Client' has been declared. I'll probably try to find a better solution as soon as I find some time... Cheers, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] [PATCH] An experiment with X resources
Chris Webb --> dwm (2007-09-24 14:30:23 +0100):
> This morning I've been thinking about run time configuration of dwm.
[...]
I only glanced at the code, but this seems to be a useful idea!
> +void *
> +erealloc(void *res, unsigned int size) {
> + if (!(res = res ? realloc(res, size) : malloc(size)))
> + eprint("fatal: could not realloc() %u bytes\n", size);
> + return res;
> +}
Hmm, why using the ternary operator? Are there systems where
`realloc(NULL, size)' does not behave identically to `malloc(size)'?
Regards, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] addtomwfact -> setmwfact proposal
Hi, Christian Garbs --> dwm (2007-08-20 00:04:20 +0200): > On Sun, Aug 19, 2007 at 11:43:46PM +0200, Jukka Salmi wrote: [...] > > No, you got it right: I'm using NetBSD, and man pages seem always to > > be formatted to not exceed 78 columns. Hmm... > > Look for a way to turn of the caching of preformatted manpages. The > caching is (at least on the linux distributions I know) always done at > 80 columns so that these cached pages are useabla by anybody. with "preformatted manpages" you mean the non-troff, ASCII with overstriking format cat pages? Hmm, even man pages for which there is no cat page are wrapped at about 78 columns... I've never really looked into this before, maybe I should do this sometime... > Not using preformatted pages uses your acutal terminal width, but > comes at a small speed cost, as the manpage is formatted every time > you view it - which is neglectible on today's systems. Sure, I could live with it ;-) Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] addtomwfact -> setmwfact proposal
Karl. --> dwm (2007-08-20 08:18:11 +1200): > Not that this answers your question, but on my system (Debian Lenny), > man pages get formatted according to the term width, so terms bigger > than 80 columns don't waste space - the extra space gets used. > > (formatting gets ugly if the term is resized after opening, though - > maybe this is what you meant and I misread you) No, you got it right: I'm using NetBSD, and man pages seem always to be formatted to not exceed 78 columns. Hmm... Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] addtomwfact -> setmwfact proposal
Jukka Salmi --> dwm (2007-08-19 20:53:40 +0200): > Antoni Grzymala --> dwm (2007-08-19 19:52:22 +0200): > > Tako rzecze Jukka Salmi (w e-mailu datowanym 2007-08-17, 12:25): > > > > > Sometimes I need a terminal window which has exactly 80 columns; > > > that's where being able to set mwfact explicitly would be nice. > > > > I sometimes need to work remotely on an extremely old DOS[emu] system > > and for this I have set up separate Xdefaults for xterm (which include a > > very large font and -geometry 80x25), also xterm has a dwm floating > > rule. For my everyday terminal needs I use urxvt. Maybe this would be a > > solution more practical than resizing your current terminal to 80 > > columns. > > Thanks for the hint. I'm already using something similar: a separate > shortcut for spawning `exec urxvtc -name whatever' and a floating rule > for /^URxvt:fterm:/. Of course this should read ...for spawning `exec urxvtc -name whatever' and a floating rule for /^URxvt:whatever:/. > However, I still resize terminals in tiling mode quite often; e.g. > while reading man pages terminals with more than 80 columns just waste > space. -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] addtomwfact -> setmwfact proposal
Antoni Grzymala --> dwm (2007-08-19 19:52:22 +0200): > Tako rzecze Jukka Salmi (w e-mailu datowanym 2007-08-17, 12:25): > > > Sometimes I need a terminal window which has exactly 80 columns; > > that's where being able to set mwfact explicitly would be nice. > > I sometimes need to work remotely on an extremely old DOS[emu] system > and for this I have set up separate Xdefaults for xterm (which include a > very large font and -geometry 80x25), also xterm has a dwm floating > rule. For my everyday terminal needs I use urxvt. Maybe this would be a > solution more practical than resizing your current terminal to 80 > columns. Thanks for the hint. I'm already using something similar: a separate shortcut for spawning `exec urxvtc -name whatever' and a floating rule for /^URxvt:fterm:/. However, I still resize terminals in tiling mode quite often; e.g. while reading man pages terminals with more than 80 columns just waste space. Cheers, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] feature freeze
Anselm R. Garbe --> dwm (2007-08-19 18:44:59 +0200): > Please recheck with hg tip. The problem should be solved now. > Actually when dwm is killed, all not-visible windows are > iconified, such windows have been ignored by previous scan() > function. Seems to work fine, thanks! Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] feature freeze
Jukka Salmi --> dwm (2007-08-19 11:34:24 +0200): > Enno Gottox Boland --> dwm (2007-08-19 11:29:22 +0200): > > But still, if I do a killall .dwm and restart dwm, all windows which > > were not visible are lost. > > By "not visible" you mean "tagged with a tag not currently viewed", > don't you? This works fine here... Sorry, I reloaded dwm instead of killing and restarting it. I can reproduce your problem now... -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] feature freeze
Enno Gottox Boland --> dwm (2007-08-19 11:29:22 +0200): > But still, if I do a killall .dwm and restart dwm, all windows which > were not visible are lost. By "not visible" you mean "tagged with a tag not currently viewed", don't you? This works fine here... Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] addtomwfact -> setmwfact proposal
Enno Gottox Boland --> dwm (2007-08-17 12:38:14 +0200):
> bloated :)
>
> A smaller version:
[...]
Indeed, sscanf(3) is smarter than I thought! Thanks for the hint.
Updated patch attached.
Regards, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
diff -rup dwm.orig/tile.h dwm/tile.h
--- dwm.orig/tile.h 2007-08-15 21:53:12.0 +0200
+++ dwm/tile.h 2007-08-17 12:48:30.0 +0200
@@ -1,6 +1,6 @@
/* See LICENSE file for copyright and license details. */
/* tile.c */
-void addtomwfact(const char *arg); /* adds arg value [0.1 .. 0.9] to
master width factor */
+void setmwfact(const char *arg); /* sets master width factor */
void tile(void); /* arranges all windows tiled */
void zoom(const char *arg);/* zooms the focused client to master
area, arg is ignored */
diff -rup dwm.orig/tile.c dwm/tile.c
--- dwm.orig/tile.c 2007-08-16 09:21:04.0 +0200
+++ dwm/tile.c 2007-08-17 12:50:07.0 +0200
@@ -9,8 +9,8 @@ static double mwfact = MWFACT;
/* extern */
void
-addtomwfact(const char *arg) {
- double delta;
+setmwfact(const char *arg) {
+ double delta, newfact;
if(!isarrange(tile))
return;
@@ -19,8 +19,17 @@ addtomwfact(const char *arg) {
if(arg == NULL)
mwfact = MWFACT;
else if(1 == sscanf(arg, "%lf", &delta)) {
- if(delta + mwfact > 0.1 && delta + mwfact < 0.9)
- mwfact += delta;
+ if(arg[0] != '+' && arg[0] != '-')
+ newfact = delta;
+ else
+ newfact = mwfact + delta;
+
+ if(newfact < 0.1)
+ newfact = 0.1;
+ else if(newfact > 0.9)
+ newfact = 0.9;
+
+ mwfact = newfact;
}
arrange();
}
diff -rup dwm.orig/config.default.h dwm/config.default.h
--- dwm.orig/config.default.h 2007-08-17 10:39:09.0 +0200
+++ dwm/config.default.h2007-08-17 12:49:18.0 +0200
@@ -46,8 +46,8 @@ Key keys[] = { \
{ MODKEY, XK_b, togglebar, NULL },
\
{ MODKEY, XK_j, focusnext, NULL },
\
{ MODKEY, XK_k, focusprev, NULL },
\
- { MODKEY, XK_h, addtomwfact,"-0.05"
}, \
- { MODKEY, XK_l, addtomwfact,"0.05"
}, \
+ { MODKEY, XK_h, setmwfact, "-0.05"
}, \
+ { MODKEY, XK_l, setmwfact, "+0.05"
}, \
{ MODKEY, XK_m, togglemax, NULL },
\
{ MODKEY, XK_Return, zoom, NULL },
\
{ MODKEY|ShiftMask, XK_space, togglefloating, NULL },
\
diff -rup dwm.orig/config.arg.h dwm/config.arg.h
--- dwm.orig/config.arg.h 2007-08-17 10:39:09.0 +0200
+++ dwm/config.arg.h2007-08-17 12:49:26.0 +0200
@@ -48,8 +48,8 @@ Key keys[] = { \
{ MODKEY, XK_b, togglebar, NULL },
\
{ MODKEY, XK_j, focusnext, NULL },
\
{ MODKEY, XK_k, focusprev, NULL },
\
- { MODKEY, XK_h, addtomwfact,"-0.05"
}, \
- { MODKEY, XK_l, addtomwfact,"0.05"
}, \
+ { MODKEY, XK_h, setmwfact, "-0.05"
}, \
+ { MODKEY, XK_l, setmwfact, "+0.05"
}, \
{ MODKEY, XK_m, togglemax, NULL },
\
{ MODKEY, XK_Return, zoom, NULL },
\
{ MODKEY|ShiftMask, XK_space, togglefloating, NULL },
\
[dwm] addtomwfact -> setmwfact proposal
Hi,
what about renaming addtomwfact() to setmwfact() and allowing for
mwfact to be set both relatively and abolutely? Sometimes I need a
terminal window which has exactly 80 columns; that's where being able
to set mwfact explicitly would be nice.
The attached patch implements this minor change. The argument passed
to setmwfact() is handled as follows:
- If the first character is either '+' or '-', the value is added
or subtracted from mwfact. This is the current behaviour of
addtomwfact(), except that a plus sign is needed to incement mwfact.
- If the first chararcter is neither '+' nor '-', mwfact is set to the
value, no matter what the current mwfact value is.
Furthermore, for large delta values mwfact currently doesn't come close
to its limits (0.1, 0.9). The patch fixes this as well.
It also prevents arrange() from being called if sscanf() fails
(shouldn't happen, but...).
Comments are welcome!
Cheers, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
diff -rup dwm.orig/tile.h dwm/tile.h
--- dwm.orig/tile.h 2007-08-15 21:53:12.0 +0200
+++ dwm/tile.h 2007-08-17 11:55:27.0 +0200
@@ -1,6 +1,6 @@
/* See LICENSE file for copyright and license details. */
/* tile.c */
-void addtomwfact(const char *arg); /* adds arg value [0.1 .. 0.9] to
master width factor */
+void setmwfact(const char *arg); /* sets master width factor */
void tile(void); /* arranges all windows tiled */
void zoom(const char *arg);/* zooms the focused client to master
area, arg is ignored */
diff -rup dwm.orig/tile.c dwm/tile.c
--- dwm.orig/tile.c 2007-08-16 09:21:04.0 +0200
+++ dwm/tile.c 2007-08-17 12:03:07.0 +0200
@@ -9,8 +9,9 @@ static double mwfact = MWFACT;
/* extern */
void
-addtomwfact(const char *arg) {
- double delta;
+setmwfact(const char *arg) {
+ char sign;
+ double delta, newfact;
if(!isarrange(tile))
return;
@@ -18,9 +19,24 @@ addtomwfact(const char *arg) {
/* arg handling, manipulate mwfact */
if(arg == NULL)
mwfact = MWFACT;
- else if(1 == sscanf(arg, "%lf", &delta)) {
- if(delta + mwfact > 0.1 && delta + mwfact < 0.9)
- mwfact += delta;
+ else {
+ switch(arg[0]) {
+ case '-':
+ case '+':
+ if(2 != sscanf(arg, "%c%lf", &sign, &delta))
+ return;
+ newfact = mwfact + (sign=='-' ? -1 : 1) * delta;
+ break;
+ default:
+ if(1 != sscanf(arg, "%lf", &newfact))
+ return;
+ break;
+ }
+ if(newfact < 0.1)
+ newfact = 0.1;
+ else if(newfact > 0.9)
+ newfact = 0.9;
+ mwfact = newfact;
}
arrange();
}
diff -rup dwm.orig/config.arg.h dwm/config.arg.h
--- dwm.orig/config.arg.h 2007-08-17 10:39:09.0 +0200
+++ dwm/config.arg.h2007-08-17 11:56:18.0 +0200
@@ -48,8 +48,8 @@ Key keys[] = { \
{ MODKEY, XK_b, togglebar, NULL },
\
{ MODKEY, XK_j, focusnext, NULL },
\
{ MODKEY, XK_k, focusprev, NULL },
\
- { MODKEY, XK_h, addtomwfact,"-0.05"
}, \
- { MODKEY, XK_l, addtomwfact,"0.05"
}, \
+ { MODKEY, XK_h, setmwfact, "-0.05"
}, \
+ { MODKEY, XK_l, setmwfact, "+0.05"
}, \
{ MODKEY, XK_m, togglemax, NULL },
\
{ MODKEY, XK_Return, zoom, NULL },
\
{ MODKEY|ShiftMask, XK_space, togglefloating, NULL },
\
diff -rup dwm.orig/config.default.h dwm/config.default.h
--- dwm.orig/config.default.h 2007-08-17 10:39:09.0 +0200
+++ dwm/config.default.h2007-08-17 11:56:28.0 +0200
@@ -46,8 +46,8 @@ Key keys[] = { \
{ MODKEY, XK_b, togglebar, NULL },
\
{ MODKEY, XK_j, focusnext, NULL },
\
{ MODKEY, XK_k, focusprev, NULL },
\
- { MODKEY, XK_h, addtomwfact,"-0.05"
}, \
- { MODKEY, XK_l, addtomwfact,"0.05"
}, \
+ { MODKEY, XK_h, setmwfact, "-0.05"
}, \
+ { MODKEY, XK_l, setmwfact, "+0.05"
}, \
{ MODKEY, XK_m,
Re: [dwm] bugfixes and some refactoring
Anselm R. Garbe --> dwm (2007-08-16 18:33:19 +0200): > I believe I fixed the issue, please recheck with hg tip! Yes, you did. Thanks! BTW, would it make sense to save and restore seltag[] across dwm restarts? And maybe clients[] and stack[]? And probably everything else? ;-) Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] flickering save file dialog of mozilla-acrobat plugin
Martin Sander --> dwm (2007-08-01 13:43:55 +0200): > Hey list. > > When I use the "save a copy" button in an adobe reader window inside a > firefox (with the mozilla-acroread plugin), the save file dialog > flickers (jumps) from left to right, so that it is hard to click save or > cancel. > When I switch to another tag and back the flickering stops, but begins > again if I move the dialog. > > I'm using dwm-4.3 with bottom-stack patch. > > This is not a very big problem (and I hope it hasn't been mentioned > before on this list, couldn't find it in the archives), but maybe you > want to look into it. Probably Adobe's fault. It's a bug in GTK+ 2.x, fixed in 2.10.13. Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] dwm-4.4 is on its way
Anselm R. Garbe --> dwm (2007-07-31 18:24:18 +0200): > On Mon, Jul 30, 2007 at 09:20:32PM +0200, Jukka Salmi wrote: > > Anselm R. Garbe --> dwm (2007-07-30 21:08:44 +0200): > > > I pushed a "fix" (rev 929), please recheck. > > > > Seems to work fine, thanks! > > Please recheck, I pushed a different fix, actually the current > one seems better than the yesterday fix. Seems to work fine, too. Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] dwm-4.4 is on its way
Anselm R. Garbe --> dwm (2007-07-30 21:08:44 +0200): > I pushed a "fix" (rev 929), please recheck. Seems to work fine, thanks! Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] dwm-4.4 is on its way
Jeremy O'Brien --> dwm (2007-07-30 00:50:55 -0400): > Hello there. A little off-topic from this thread, but I noticed in that > screenshot that you have a "messages:6" line in your status bar. How in > the heck did you get that to show there? I can't find any programs > outside of gkrellm's mail monitor that supports maildir-style mailboxes. Me neither, but luckily I don't use maildir mailboxes ;-) The `messages: n' results from running `fetchmail -c' on some IMAP mailboxes and processing its output with awk(1). Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] dwm-4.4 is on its way
Hi, Anselm R. Garbe --> dwm (2007-07-28 17:23:24 +0200): > Hi there, > > I ask you to check the current hg tip (changeset 927+) to test > dwm. Especially those using Mathematica having trouble with the > so-called greyish blobs bug. I changed the mechanism how dwm > bans resp. unbans windows. Since dwm 0.1 it banned/unbanned > windows through XMoveWindow()-ing them off- and onscreen. Now > dwm uses X[Un]mapWindow() for this purpose. When starting Firefox in tiling layout, its window is now positioned as if there were no status bar. This happens most of the time, but no always (!?). See [1]here. Starting another client on the same tag seems to fix the broke positioning. Regards, Jukka [1] http://salmi.ch/~jukka/dwm/ff.png -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] -offtopic duplicate stdout to logfile in C?
[EMAIL PROTECTED] --> dwm (2007-06-22 18:23:55 +0200): > Hackerz, > > I have one stream, that writes to stdout. Now I want to log it, works fine > with a different pointer, but what's the best way to duplicate the existing > stream that already is printed to stdout to a logfile? Of course, 2 fprintfs > is no pr0n at all :) You probably want tee(1). HTH, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] Greyish blobs
Sebastian Goll --> dwm (2007-06-20 00:14:54 +0200): > On Mon, 18 Jun 2007 17:47:16 +0200 > "Anselm R. Garbe" <[EMAIL PROTECTED]> wrote: > > > I will have a patch available tomorrow. > > I checked the patch (changeset 920:7f8c81c4bc9a) and it doesn't show the > greyish blobs anymore, but on the other hand it doesn't show any windows > at all, ie. the applications are running but their windows don't show up > (transient windows like Mathematica startup are shown though). On stderr > I get only "yes" to "does the window suck?", and not a single output has > "no" as an answer. Same here, windows always seem to be unmapped (i.e. map_state==IsUnmapped). Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] problem with dmenu3.1
Jukka Salmi --> dwm (2007-05-23 16:26:36 +0200):
> Frank Pirnay --> dwm (2007-05-23 15:37:34 +0200):
> > ok, my /bin/sh links to dash
>
> Oh, that probably explains a lot. There seems to be a bug in the NetBSD
> /bin/sh (see my previous post), and dash is a direct descendant of the
> NetBSD /bin/sh. So dash seems to be bug-compatible with its ancestor
> ;-)
>
>
> > So I changed !#/bin/sh to !#/bin/bash in the dmenu_path script. Now
> > it's working fine.
>
> A better solution would be to fix {d,}ash...
FYI: that bug in NetBSD /bin/sh is [1]fixed now, so a future dash
release might incorporate it and work as expected even with the
dmenu_path script you were having troubles with.
Regards, Jukka
[1] http://mail-index.netbsd.org/source-changes/2007/05/24/0016.html
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] Bottom Stack patch for dwm-4.1
Anselm R. Garbe --> dwm (2007-05-24 16:27:44 +0200): > I pushed a slightly different version, which seemed more obvious > to me: [...] Sure, that's cleaner. Works fine, thanks! Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] Bottom Stack patch for dwm-4.1
Anselm R. Garbe --> dwm (2007-05-24 15:44:33 +0200):
> Ok I pushed a version, which handles the problem properly for
> both master and stack areas. It's time for you guys to test this
> now!
Seems to work fine, thanks! Except for the case if nmaster > n; in
that case the calculate height of the last client seems to be a pixel
or so to small. I didn't really think about it, but the attached patch
seems to work around the problem.
Cheers, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
diff -r 6c8b43d7b616 layout.c
--- a/layout.c Thu May 24 15:40:07 2007 +0200
+++ b/layout.c Thu May 24 16:03:44 2007 +0200
@@ -40,7 +40,7 @@ tile(void) {
ny += i * mh;
nw = mw - 2 * c->border;
nh = mh;
- if(i + 1 == nmaster) /* remainder */
+ if(i + 1 == nmaster || (n < nmaster && i + 1 ==
n)) /* remainder */
nh = wah - mh * i;
nh -= 2 * c->border;
}
Re: [dwm] Bottom Stack patch for dwm-4.1
Anselm R. Garbe --> dwm (2007-05-24 11:01:19 +0200): > Hi Ross, > > On Tue, May 22, 2007 at 11:42:46PM -0400, Ross Mohn wrote: > > I've posted a new patch that works, but I don't think that the vanilla > > dwm code deals with all the cases that might need the remainder > > solution. For example, if nmaster>1, you might want to apply a remainder > > to the bottom window, but it would be different from the tiling > > remainder. How correct are we trying to get with it? Is it worth > > accounting for both these remainder possibilities? > > That's indeed an issue. So the question is, wether we revert the > algorithm to not handling any remainder or to handle it properly > for both, master and stack windows. > > What do others think? I think it might be worth to make it work > properly for any case, even if the algorithm gets a little bit > more complex, just for accuracy and aesthetical reasons. ++go_for_accuracy ;-) -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
[dwm] dmenu_path, again...
Hi,
the most recent [1]commit removed the part where the temporary cache
file was written, thus breaking the script. The attached patch fixes
this.
BTW, -maxdepth is not specified in SUSV3...
Regards, Jukka
[1]
http://www.suckless.org/cgi-bin/hgwebdir.cgi/dmenu/diff/1fed9410fbc6/dmenu_path
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
diff -r 1fed9410fbc6 dmenu_path
--- a/dmenu_pathWed May 23 19:38:23 2007 -0400
+++ b/dmenu_pathThu May 24 09:19:20 2007 +0200
@@ -18,8 +18,8 @@ then
echo "$PATH"
qfind $PATH -type f -maxdepth 1 '(' -perm -u+x -o -perm -g+x -o
-perm -o+x ')' |
sed 's,.*/,,' | sort | uniq
- }
- mv $CACHE.$pid $CACHE
+ } >$CACHE.$$
+ mv $CACHE.$$ $CACHE
fi
tail -n +2 $CACHE
Re: [dwm] problem with dmenu3.1
Sander van Dijk --> dwm (2007-05-23 23:03:10 +0200): > On 5/23/07, Marek Bernat <[EMAIL PROTECTED]> wrote: >> On the other hand kill, echo and other programs like this should of course >> be outside the shell. > > Yes, [...] ...but on a system where you suddenly notice that the process table is full and you thus can't fork new processes anymore I bet even you will be quite happy if you have a kill(1) built into your still running shell... ;-) Cheers, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] problem with dmenu3.1
Sander van Dijk --> dwm (2007-05-23 17:53:26 +0200): > As for test being a language contruct: is isn't, or at least wasn't > originally. If that's why you don't want test/[ to be shell builtins you might want to remove other builtins like echo, printf, false, true, pwd, kill, etc. as well. If executable size really matters this might indeed be a good idea, especially for "large" things like printf. But this is getting OT now... Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] problem with dmenu3.1
Sander van Dijk --> dwm (2007-05-23 16:18:34 +0200):
> On 5/23/07, Anselm R. Garbe <[EMAIL PROTECTED]> wrote:
>> Thanks! I applied it to the repo, however I'm not totally sure
>> the use of [ is a good idea. Is [ a symlink to test in any Unix?
>
> I don't know, I do know it's a symlink to test in many linux distros.
> I personally hate it though, since it obscures the fact that you are
> calling a program ("test" is much clearer in this sense thatn "[").
That's a matter of taste, of course. I prefer the latter because then
the expression is delimited by `[' and `]', making it easier to parse
IMHO.
> Btw, in bash they are _both_ builtins (don't ask me why,
Probably to give all shell scripts the same performace gain, whether
they use `test' or `['.
Regards, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] problem with dmenu3.1
Frank Pirnay --> dwm (2007-05-23 15:37:34 +0200):
> ok, my /bin/sh links to dash
Oh, that probably explains a lot. There seems to be a bug in the NetBSD
/bin/sh (see my previous post), and dash is a direct descendant of the
NetBSD /bin/sh. So dash seems to be bug-compatible with its ancestor
;-)
> So I changed !#/bin/sh to !#/bin/bash in the dmenu_path script. Now
> it's working fine.
A better solution would be to fix {d,}ash...
Regards, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] problem with dmenu3.1
Premysl anydot Hruby --> dwm (2007-05-23 13:42:58 +0200):
> So, if functions are allowed then maybe even better can be this:
>
>
> --- a/dmenu_pathWed May 23 13:22:27 2007 +0200
> +++ b/dmenu_pathWed May 23 13:37:33 2007 +0200
> @@ -1,22 +1,16 @@
> #!/bin/sh
> CACHE=$HOME/.dmenu_cache
> -UPTODATE=1
> IFS=:
>
> -uptodate() { [ $UPTODATE -eq 1 ]; }
> -
> -if test ! -f $CACHE
> -then
> -UPTODATE=0
> -fi
> -
> -if uptodate
> -then
> +uptodate() {
> +test ! -f $CACHE && return 1
> for dir in $PATH
> do
> -test $dir -nt $CACHE && { UPTODATE=0; break; }
> +test $dir -nt $CACHE && return 1
> done
> -fi
> +
> +return 0
> +}
>
> if ! uptodate
> then
>
>
>
> Which throws decision about cache freshnes to the uptodate() func.
Yes, that's probably cleaner as long as uptodate() is only called once.
Regards, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
Re: [dwm] problem with dmenu3.1
Anselm R. Garbe --> dwm (2007-05-23 13:23:43 +0200): > On Wed, May 23, 2007 at 01:14:12PM +0200, Jukka Salmi wrote: > > > > I'm able to reproduce this problem with a bourne shell on some BSD > > systems; it seems to be a bug in the test(1) code. Maybe you were > > bitten by the same bug. > > > > To make dmenu_path more robust against such problems I'd recommend the > > attached patch. Furthermore it speeds up execution time a little bit > > in case the cache has to be rebuilt because of a changed directory > > (unless it the last directory in the $PATH). > > Thanks! I applied it to the repo, however I'm not totally sure > the use of [ is a good idea. Is [ a symlink to test in any Unix? Both [ and test are shell builtins in sh and ksh at least on NetBSD, and in bash. And NetBSD also has $ ls -li /bin/[ /bin/test 42532 -r-xr-xr-x 2 root wheel 18583 Apr 25 23:18 /bin/[ 42532 -r-xr-xr-x 2 root wheel 18583 Apr 25 23:18 /bin/test Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] problem with dmenu3.1
Jukka Salmi --> dwm (2007-05-23 10:53:21 +0200):
> Frank Pirnay --> dwm (2007-05-23 09:16:45 +0200):
> > I thought about broken hardware too... I will try some memtesting today.
>
> That's probably a good idea.
>
>
> > Anyway, this is my output:
> >
> > + CACHE=/home/knarf/.dmenu_cache
> > + UPTODATE=1
> > + IFS=:
> > + test ! -f /home/knarf/.dmenu_cache
> > + test 1
> > + test /home/knarf/bin -nt /home/knarf/.dmenu_cache
> > + test /usr/local/sbin -nt /home/knarf/.dmenu_cache
> > + test /usr/local/bin -nt /home/knarf/.dmenu_cache
> > + unset UPTODATE
> > + test /usr/sbin -nt /home/knarf/.dmenu_cache
> > + test /usr/bin -nt /home/knarf/.dmenu_cache
> > + unset UPTODATE
> > + test /sbin -nt /home/knarf/.dmenu_cache
> > + test /bin -nt /home/knarf/.dmenu_cache
> > + unset UPTODATE
> > + test /usr/games -nt /home/knarf/.dmenu_cache
> > + test !
> > Segmentation fault
> >
> > The segfault always happens at this place. Any ideas?
>
> What is /bin/sh on that system? In case it a symlink to /bin/bash:
> what bash version is this? If it's another shell: what test(1) is it
> using, e.g. a shell builtin or an external command?
>
> Try replacing line 19 of dmenu_path with
>
> if test -n $UPTODATE
>
> In case the segfault still occurs, try quoting $UPTODATE on line 19,
> i.e.
>
> if test ! "$UPTODATE"
>
> or
>
> if test -n "$UPTODATE"
>
> Does any of this help?
I'm able to reproduce this problem with a bourne shell on some BSD
systems; it seems to be a bug in the test(1) code. Maybe you were
bitten by the same bug.
To make dmenu_path more robust against such problems I'd recommend the
attached patch. Furthermore it speeds up execution time a little bit
in case the cache has to be rebuilt because of a changed directory
(unless it the last directory in the $PATH).
Regards, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
diff -r d14fe4d89e3f dmenu_path
--- a/dmenu_pathMon May 21 14:36:03 2007 +0200
+++ b/dmenu_pathWed May 23 12:42:44 2007 +0200
@@ -3,20 +3,22 @@ UPTODATE=1
UPTODATE=1
IFS=:
+uptodate() { [ $UPTODATE -eq 1 ]; }
+
if test ! -f $CACHE
then
- unset UPTODATE
+ UPTODATE=0
fi
-if test $UPTODATE
+if uptodate
then
for dir in $PATH
do
- test $dir -nt $CACHE && unset UPTODATE
+ test $dir -nt $CACHE && { UPTODATE=0; break; }
done
fi
-if test ! $UPTODATE
+if ! uptodate
then
for dir in $PATH
do
Re: [dwm] problem with dmenu3.1
Frank Pirnay --> dwm (2007-05-23 09:16:45 +0200): > I thought about broken hardware too... I will try some memtesting today. That's probably a good idea. > Anyway, this is my output: > > + CACHE=/home/knarf/.dmenu_cache > + UPTODATE=1 > + IFS=: > + test ! -f /home/knarf/.dmenu_cache > + test 1 > + test /home/knarf/bin -nt /home/knarf/.dmenu_cache > + test /usr/local/sbin -nt /home/knarf/.dmenu_cache > + test /usr/local/bin -nt /home/knarf/.dmenu_cache > + unset UPTODATE > + test /usr/sbin -nt /home/knarf/.dmenu_cache > + test /usr/bin -nt /home/knarf/.dmenu_cache > + unset UPTODATE > + test /sbin -nt /home/knarf/.dmenu_cache > + test /bin -nt /home/knarf/.dmenu_cache > + unset UPTODATE > + test /usr/games -nt /home/knarf/.dmenu_cache > + test ! > Segmentation fault > > The segfault always happens at this place. Any ideas? What is /bin/sh on that system? In case it a symlink to /bin/bash: what bash version is this? If it's another shell: what test(1) is it using, e.g. a shell builtin or an external command? Try replacing line 19 of dmenu_path with if test -n $UPTODATE In case the segfault still occurs, try quoting $UPTODATE on line 19, i.e. if test ! "$UPTODATE" or if test -n "$UPTODATE" Does any of this help? Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] problem with dmenu3.1
Frank Pirnay --> dwm (2007-05-23 01:35:13 +0200): > ok, I noticed the segfault when running dmenu_path manually. So that is the > only output I get using > uxterm or bash. Actually dmenu is running fine. I am using Ubuntu 7.04, > 2.6.20-15-generic kernel on > 2 systems but I have this problem only on 1 machine...?! So that machine has a problem (broken hardware?)... Try running sh -x /path/to/your/dmenu_path several times and see if the segfault always happens at the same place. If it does not, then this really looks like a hardware problem. Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] Bottom Stack patch for dwm-4.1
Philipp Köhler --> dwm (2007-05-22 12:58:32 +0200):
> i dont know if this is dwm's fault or the stacked mode...
> but in landscapemode the second windows isnt visible,,,
Seems to be a bug in the bstack patch. Try applying the attached patch
after applying the bstack patch.
HTH, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
--- layout.c.bak2007-05-22 19:33:18.0 +0200
+++ layout.c2007-05-22 19:33:05.0 +0200
@@ -81,7 +81,7 @@
mw = waw;
th = (n > nmaster) ? ((wah * (1000 - masterw)) / 1000) / (portrait ? 1
: n - nmaster) : 0;
tw = (n > nmaster) ? waw / (portrait ? n - nmaster : 1) : 0;
- remainder = (n > nmaster) ? wah - tw * (n - nmaster) : 0;
+ remainder = (n > nmaster) ? wah - th * (n - nmaster) : 0;
for(i = 0, c = clients; c; c = c->next)
if(isvisible(c)) {
Re: [dwm] dmenu_cache patch for dmenu 3.0
Sander van Dijk --> dwm (2007-05-13 11:52:17 +0200): > On 5/13/07, Jukka Salmi <[EMAIL PROTECTED]> wrote: >> To be compatible with old shells you should be careful when test(1)ing >> a potentially unset or empty variable; i.e. use `test x$var != x' >> instead of `test $var'. > > Wouldn't `test "$var"' work as well? I've been told that there are shells which even get this wrong, leaving `test x$var ...' as the only portable way... But I've never used such a shell myself, though. Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] dmenu_cache patch for dmenu 3.0
[EMAIL PROTECTED] --> dwm (2007-05-12 20:36:44 +0200): > I created new, simpler version, withou $PATH changes, without tempfile > etc. It only check if in directories in $PATH doesn't happen something > from last recreation of cache. [...] > I used $HOME instead '~' is this ok? Your patch looks (and works) fine! To be compatible with old shells you should be careful when test(1)ing a potentially unset or empty variable; i.e. use `test x$var != x' instead of `test $var'. However, nowadays probably nobody uses such shells anymore... ;-) Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] regression with dwm rev. 867
Anselm R. Garbe --> dwm (2007-05-09 10:29:01 +0200): > On Mon, May 07, 2007 at 08:51:11PM +0200, Jukka Salmi wrote: > > Hi, > > > > the most recent change to tile() causes the last client in the current > > view to be smaller than needed, leaving a small rectangle in the lower > > right of the screen unused. Is [1]this intended behaviour? > > This was a bug, I pushed a fix this morning! Works fine, thanks! Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] regression with dwm rev. 867
Enno Gottox Boland --> dwm (2007-05-07 21:02:36 +0200): > Yes it is. This behavior saves some lines of code. Are you joking? Why not remove the whole tile() function, this would save even more lines of code... ;-) > 2007/5/7, Jukka Salmi <[EMAIL PROTECTED]>: >> Hi, >> >> the most recent change to tile() causes the last client in the current >> view to be smaller than needed, leaving a small rectangle in the lower >> right of the screen unused. Is [1]this intended behaviour? >> >> >> Regards, Jukka >> >> [1] http://salmi.ch/~jukka/dwm/root.png -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
[dwm] regression with dwm rev. 867
Hi, the most recent change to tile() causes the last client in the current view to be smaller than needed, leaving a small rectangle in the lower right of the screen unused. Is [1]this intended behaviour? Regards, Jukka [1] http://salmi.ch/~jukka/dwm/root.png -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] border problems
Anselm R. Garbe --> dwm (2007-04-18 17:29:06 +0200): > On Wed, Apr 18, 2007 at 10:19:29AM +0200, Jukka Salmi wrote: > > since the recent border handling [1]changes I see the following > > behaviour: while xterm borders are set to BORDERPX, rxvt borders are > > set to zero. Hmm. This is not intended behaviour, is it? What is the > > idea, which clients should have what border size? > > > > > > Regards, Jukka > > > > [1] http://www.suckless.org/cgi-bin/hgwebdir.cgi/dwm/rev/55691060ffa3 > > You are right, I can confirm what you notice, however it only > happens in tiled mode - and I also understand why. Will fix this > soon. Fixed with changeset 863, thanks! Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
[dwm] border problems
Hi, since the recent border handling [1]changes I see the following behaviour: while xterm borders are set to BORDERPX, rxvt borders are set to zero. Hmm. This is not intended behaviour, is it? What is the idea, which clients should have what border size? Regards, Jukka [1] http://www.suckless.org/cgi-bin/hgwebdir.cgi/dwm/rev/55691060ffa3 -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] Reloading running dwm - reload patch
Christian Garbs --> dwm (2007-03-22 23:29:37 +0100): > I like the SIGUSR1 approach (which, btw, currently does not work for > me at all, See the first comment in the message below, I bet that's the source of your problem... HTH, Jukka - Forwarded message from Jukka Salmi - From: Jukka Salmi Subject: Re: [dwm] Reloading running dwm - reload patch Date: Wed, 21 Mar 2007 13:17:07 +0100 To: [EMAIL PROTECTED] Hi, [EMAIL PROTECTED] wrote: > I created patch for reloading dwm with signal USR1. thanks! Some comments about it: - In doreload() I'd call execvp() instead of execve(), otherwise reloading will not work if argv[0] is a relative pathname. Furthermore this would save you from having to pass `environ'. - In cleanup(), instead of removing the call to close() I'd prepend "if (!reload)" to it. - Both sigusr1() and doreload() should probably be static. - The string passed with eprint() should be terminated by a newline ;-) Regards, Jukka - End forwarded message - -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] dmenu-2.4
Anselm R. Garbe --> dwm (2007-02-23 14:19:12 +0100): > On Fri, Feb 23, 2007 at 01:11:03PM +, Frederik Deweerdt wrote: > > On Fri, Feb 23, 2007 at 10:50:16AM +0100, Anselm R. Garbe wrote: > > > I did some benchmarks measuring the difference between > > > dmenu_path [...] > > Hi, > > > > On my system, this: > > for i in `echo $PATH | tr : ' '`; do find $i -maxdepth 1 -perm -100 -type > > f 2> /dev/null ; done | sort -u > > performs slightly better (~10%) than the ls | awk based approach. I made > > the measurements without cache (echo 3 > /proc/sys/vm/drop_caches). > > I'm not sure if those find arguments are portable enough, can > someone recheck if it works on BSD and other Unices? While `-perm' and `-type' are fine, `-maxdepth' is not specified by POSIX. However, it works fine on NetBSD et al. Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [hackers] [dwm] I didn't knew of c->isfixed, that should fix Jukkas issue with gkrellm ; )
Jukka Salmi --> dwm (2007-02-17 15:21:43 +0100):
> Jukka Salmi --> dwm (2007-02-14 22:04:41 +0100):
> > Anselm R. Garbe --> hackers (2007-02-13 21:57:01 +):
> > > changeset: 755:887d74605df8
> > > tag: tip
> > > user:Anselm R. Garbe <[EMAIL PROTECTED]>
> > > date:Tue Feb 13 22:53:58 2007 +0100
> > > summary: I didn't knew of c->isfixed, that should fix Jukkas issue
> > > with gkrellm ;)
> >
> > It does, thanks a lot!
>
> Revision 762 introduced a similar problem: when trying to start gkrellm
> in the bottom right corner (`gkrellm -geometry -0-0'), gkrellm appears
> in the top left corner, but as soon as I try to move the window (MODKEY
> + left button) it "jumps" to the bottom right corner... Any hints?
Additionally, since rev 762 gkrellm doesn't resize anymore if e.g. a
network interface is brought up (which causes a new monitor to be drawn
inside the gkrellm window, increasing the windows height) until I use
the mouse to move the window. The attached patch works around the
problem; not sure how to fix it correctly, though.
Regards, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
diff -r 759a5fbbd8b7 client.c
--- a/client.c Fri Feb 16 16:51:27 2007 +0100
+++ b/client.c Sat Feb 17 19:20:20 2007 +0100
@@ -267,7 +267,7 @@ resize(Client *c, int x, int y, int w, i
x = sx;
if(y + h + 2 * c->border < sy)
y = sy;
- if(c->x != x || c->y != y || c->w != w || c->h != h) {
+ if((c->isfloat || arrange==dofloat) || (c->x != x || c->y != y || c->w
!= w || c->h != h)) {
c->x = wc.x = x;
c->y = wc.y = y;
c->w = wc.width = w;
Re: [hackers] [dwm] I didn't knew of c->isfixed, that should fix Jukkas issue with gkrellm ; )
Jukka Salmi --> dwm (2007-02-14 22:04:41 +0100): > Anselm R. Garbe --> hackers (2007-02-13 21:57:01 +): > > changeset: 755:887d74605df8 > > tag: tip > > user:Anselm R. Garbe <[EMAIL PROTECTED]> > > date:Tue Feb 13 22:53:58 2007 +0100 > > summary: I didn't knew of c->isfixed, that should fix Jukkas issue with > > gkrellm ;) > > It does, thanks a lot! Revision 762 introduced a similar problem: when trying to start gkrellm in the bottom right corner (`gkrellm -geometry -0-0'), gkrellm appears in the top left corner, but as soon as I try to move the window (MODKEY + left button) it "jumps" to the bottom right corner... Any hints? Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [hackers] [dwm] I didn't knew of c->isfixed, that should fix Jukkas issue with gkrellm ; )
Anselm R. Garbe --> hackers (2007-02-13 21:57:01 +): > changeset: 755:887d74605df8 > tag: tip > user:Anselm R. Garbe <[EMAIL PROTECTED]> > date:Tue Feb 13 22:53:58 2007 +0100 > summary: I didn't knew of c->isfixed, that should fix Jukkas issue with > gkrellm ;) It does, thanks a lot! Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] Please test hg tip
Anselm R. Garbe --> dwm (2007-02-13 17:39:02 +0100): > On Tue, Feb 13, 2007 at 05:19:35PM +0100, Jukka Salmi wrote: > > Anselm R. Garbe --> dwm (2007-02-13 13:49:16 +0100): > > > If there are no complains I'll release 3.5 in the evening... > > > > Since the latest dwm changes I can't tell gkrellm where to appear using > > the -geometry option anymore; it always appears in the top left corner. > > Other programs still understand this option. > > > > Unfortunately I don't have enough time to debug this further ATM... > > In floating mode? Yes. Hmm, I just noticed that gkrellm is _always_ floating, even when started under dwm using config.default.h... Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] Please test hg tip
Jukka Salmi --> dwm (2007-02-13 17:19:35 +0100): > Anselm R. Garbe --> dwm (2007-02-13 13:49:16 +0100): > > If there are no complains I'll release 3.5 in the evening... > > Since the latest dwm changes I can't tell gkrellm where to appear using > the -geometry option anymore; it always appears in the top left corner. > Other programs still understand this option. BTW: this regression was introduced with dwm revision 752. Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] Please test hg tip
Anselm R. Garbe --> dwm (2007-02-13 13:49:16 +0100): > If there are no complains I'll release 3.5 in the evening... Since the latest dwm changes I can't tell gkrellm where to appear using the -geometry option anymore; it always appears in the top left corner. Other programs still understand this option. Unfortunately I don't have enough time to debug this further ATM... Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] Mail list
Diego Biurrun --> dwm (2007-01-25 13:25:34 +0100): > Sorry for butting in late, but .. > > On Thu, Jan 18, 2007 at 01:37:30PM +0100, Jukka Salmi wrote: > > Anselm R. Garbe --> dwm (2007-01-18 13:21:11 +0100): > > > On Thu, Jan 18, 2007 at 12:58:54PM +0100, Javier wrote: > > > > Hi there, > > > > I'm subscribed to the suckless hackers mail list and I think it could > > > > be great if hg changes mails include the patch of each revision. Is it > > > > possible? Am I the only person who thinks it's a good idea? > > > > > > What do others think about this proposal? > > > > Hmm, and if the changes are huge? I don't think this is a good idea... > > Huge changes on a small program? How? "Small" in reference to lines of program code is probably greater than "small" in reference to lines of an email message... > > The commit mail already includes the revision number, thus it's easy > > enough to get the patch (cd $dwm; hg log -r$rev -p). > > But this way nobody can discuss and comment on the patch. Review is not > going to take place. BS. I don't know of any project that includes the actual diffs with their commit messages. Nevertheless changes referenced in these commit messages are discussed and reviewed. Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] Mail list
Javier --> dwm (2007-01-18 13:42:51 +0100): > >Or maybe it should include a http link to the patch(es). For example, > >with your latest commit the commit mail would have included a reference > >to > >http://suckless.org/cgi-bin/hgwebdir.cgi/dwm?fd=94c82dffe1d5;file=config.arg.h > > I think this is a good idea. Actually I wanted to suggest to include the link to the change set, i.e. http://suckless.org/cgi-bin/hgwebdir.cgi/dwm?cs=94c82dffe1d5 which includes all patches for the change set even if multiple files were changed. Cheers, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] Mail list
Anselm R. Garbe --> dwm (2007-01-18 13:21:11 +0100): > On Thu, Jan 18, 2007 at 12:58:54PM +0100, Javier wrote: > > Hi there, > > I'm subscribed to the suckless hackers mail list and I think it could > > be great if hg changes mails include the patch of each revision. Is it > > possible? Am I the only person who thinks it's a good idea? > > What do others think about this proposal? Hmm, and if the changes are huge? I don't think this is a good idea... The commit mail already includes the revision number, thus it's easy enough to get the patch (cd $dwm; hg log -r$rev -p). Or maybe it should include a http link to the patch(es). For example, with your latest commit the commit mail would have included a reference to http://suckless.org/cgi-bin/hgwebdir.cgi/dwm?fd=94c82dffe1d5;file=config.arg.h . Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] broken pipes
Hi, Manuel Badzong --> dwm (2006-11-26 21:40:09 +): > stext is declared as global and therefore aligned in the programs bss > segment, which will be zeroed at startup. As whether read nor strncpy > use its full length (strlen/sizeof - 1) the string will be 0 terminated > in any case. You're right. So that line should probably be removed. > But I agree that it would be safer in case someone ever > moves it down into main (this time I'm not sure if necessary/wasted). Then that line should be added again ;-) > >- saves 1020 bytes from being zeroed unnecessarily (performance! ;-)) > Ok, never thought about that. Yet I didn't read much about the > implementation of the ANSI stdio functions (I presumed to understand > them). Is strncpy really zeroing up to the specified n bytes? I thought > it just copies until '\0' or n, whatever comes first (leaving dest > unterminated in the latter case). No, the destination is padded with '\0's, at least according to [1]K&R, section B3. Cheers, Jukka [1] http://cm.bell-labs.com/cm/cs/cbook/ -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] broken pipes
Hi,
Manuel Badzong --> dwm (2006-11-26 15:19:58 +0100):
> I tried several inputs (empty lines, lines with multiple '\n', all '\n'
> lines). The following patch would handle all of them correctly. Though
> I 'm not sure if this is really necessary (but it remains one line of
> code).
I'm not sure whether dwm really should try that hard to fix the input
it is given...
However, to continue the tradition of patching the patches patch I've
attached a patch. It
- '\0'-terminates the error message if read() failed (just in case
strlen(strerror(errno)) >= sizeof stext - 1)
- saves 1020 bytes from being zeroed unnecessarily (performance! ;-))
Cheers, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
diff -r 70472540c443 main.c
--- a/main.cSun Nov 26 15:43:16 2006 +0100
+++ b/main.cSun Nov 26 18:28:33 2006 +0100
@@ -277,10 +277,11 @@ main(int argc, char *argv[]) {
switch(r = read(STDIN_FILENO, stext, sizeof stext - 1))
{
case -1:
strncpy(stext, strerror(errno), sizeof stext -
1);
+ stext[sizeof stext - 1] = '\0';
readin = False;
break;
case 0:
- strncpy(stext, "EOF", sizeof stext);
+ strncpy(stext, "EOF", 4);
readin = False;
break;
default:
Re: [dwm] broken pipes
Ciao Manu,
Manuel Badzong --> dwm (2006-11-25 08:17:59 +0100):
> mkfifo dwm_pipe
> dwm < dwm_pipe > dwm_pipe
aka `dwm <>dwm_pipe', BTW...
> If dwm ever writes to stdout (does it?)
No, only some error message are written to stderr.
> After reading main.c
> I recognized that "broken pipe" actually means error or eof reading
> stdin. This definitely should be fixed.
Indeed.
> I mainly changed 5 little things in the main event loop:
[...]
> + I replaced fgets with read (I hate this FILE* crap). If for some
> reason you prefer ANSI C over UNIX IO use feof() to catch EOF.
[...]
Thanks for the cleanup. But now that dwm's reading from stdin isn't
line buffered anymore the read string shouldn't be required to have a
trailing newline. See attached patch.
Cheers, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
diff -r 010118c94013 main.c
--- a/main.cSat Nov 25 19:26:31 2006 +0100
+++ b/main.cSun Nov 26 11:07:18 2006 +0100
@@ -274,9 +274,10 @@ main(int argc, char *argv[]) {
eprint("select failed\n");
}
if(FD_ISSET(STDIN_FILENO, &rd)) {
- switch(r = read(STDIN_FILENO, stext, sizeof(stext))) {
+ switch(r = read(STDIN_FILENO, stext, sizeof(stext)-1)) {
case -1:
strncpy(stext, strerror(errno), sizeof(stext));
+ stext[sizeof(stext)-1] = '\0';
readin = False;
break;
case 0:
@@ -284,7 +285,7 @@ main(int argc, char *argv[]) {
readin = False;
break;
default:
- stext[r-1] = 0;
+ stext[r-(stext[r-1]=='\n'?1:0)] = '\0';
}
drawstatus();
}
Re: [dwm] dwm-2.3
Anthony Brown --> dwm (2006-11-24 16:44:30 +0100): > On Fri, Nov 24, 2006 at 03:50:31PM +0100, Anselm R. Garbe wrote: > > Hi there, > > > > I created http://suckless.org/download/dwm-2.3.tar.gz > > > > This release contains the occupied tag indicator and reverts > > arrange() to the reoder()-less arrangement of clients in the > > global client list (which makes the source code simplier and > > smaller). > > > > Hi Anselm, > > Thanks for this improved version. I'm very happy about the occupied tag > indicator! Just one small suggestion: In the man page the phrase "The > tags which are applied by any client are indicated..." is not very > clear. Maybe you can replace this with "The tags which are 'occupied' by > one or more clients are indicated...". IMHO this should read "The tags which are applied _to_ any client are indicated..." instead. Cheers, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] What functions do I really use?
Anselm R. Garbe --> dwm (2006-11-22 12:31:07 +0100): > I'd like to know what functions do you really use in dwm, since you pulled in Dave's patch I don't use viewall() anymore. Furthermore, I don't use toggleview() a lot, but sometimes it has been quite handy. Actually there's no function I don't use at least once a week, except for resizemaster(). Regards, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] What functions do I really use?
Jukka Salmi --> dwm (2006-11-22 18:48:03 +0100): > Enno Gottox Boland --> dwm (2006-11-22 15:45:16 +0100): > > I think the viewall function is not more as a code waster... Or does > > somebody use it? It think this could also kicked. > > I use to viewall() before shutting down dwm, just to check if there > are still some clients around which need to be closed. ...but now with dwm tip including Dave's [1]patch I don't need viewall() anymore. Thanks! Jukka [1] http://suckless.org/cgi-bin/hgwebdir.cgi/dwm?cs=427708bf5f36 -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] What functions do I really use?
Enno Gottox Boland --> dwm (2006-11-22 15:45:16 +0100): > I think the viewall function is not more as a code waster... Or does > somebody use it? It think this could also kicked. I use to viewall() before shutting down dwm, just to check if there are still some clients around which need to be closed. Cheers, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] urxvt zoom vs resize
John S. Yates, Jr. --> dwm (2006-11-06 22:13:49 -0500): > Can anyone explain why urxvt can accommodate window size > changes via zoom but not via drag-resizing? > > E.G. I have urxvt term open in master position displaying > wide lines. I zoom it away, the wide lines wrap. I zoom > it back the wide lines unwrap. Sweet! But if I resize > via MODKEY-Mouse-3 dragging the wide lines do not wrap :-( I can't reproduce this with urxvt v8.0 (and I'm sure it worked with v7.x, too); i.e. lines are wrapped when resizing a urxvt window. But only if the scrollback buffer is in [1]use... Regards, Jukka [1] http://lists.schmorp.de/pipermail/rxvt-unicode/2006q3/000327.html -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] quitting dwm-in-pipe
mikshaw --> dwm (2006-10-18 16:02:21 -0400): > My opinion is the pipe loop is not an ideal way to handle dwm status, > but it seems to be the only thing that works as it is coded. The problem > seems to be that the "while" command is actually the main X process when > dwm is run this way, so killing dwm does not end xinitrc. My choice would > have been to allow dwm to run as the final command in .xinitrc and also > allow it to read stdin...something like exec dwm < loop command, perhaps? > > In any case, my current start script for dwm looks like this: > >while pidof dwm &>/dev/null >do > date +"[%H:%M] %a %b %d" && sleep 5 >done | /opt/dwm/bin/dwm > > It's still not ideal for two reasons: > 1) i still have to wait up to 5 seconds for X to shut down > 2) sometimes it results in a broken pipe, presumably if dwm does not >start immediately (pidof exits non-zero?). I'm using a script writing status bar information to a fifo from which dwm reads. This seems to work well for both startx and xdm X initialisation and doesn't suffer from the problems you describe. The script (~/.dwm/in.sh) basically contains: #!/bin/sh -e [ $# -eq 1 ]; FIFO="$1" [ -e "$FIFO" ] || mkfifo "$FIFO" [ -p "$FIFO" ] exec >"$FIFO" 2>&1 while :; do # XXX write dwm status bar information sleep 10 done exit 1 # NOTREACHED It creates the fifo if it doesn't exist, redirects stdout and stderr to it and loops forever, writing status bar information. My ~/.xinitrc (or ~/.xsession, if using xdm) contains: WM=dwm fifo=~/.dwm/in ~/.dwm/in.sh $fifo & while [ ! -p $fifo ]; do sleep .1; done exec <$fifo $WM & wmpid=$! wait $wmpid This starts the status bar information writing script in the background and waits until the fifo is created. It then redirects stdin from the fifo (for dwm), starts dwm and waits for it. Thus exiting (or killing) dwm causes X to shut down. HTH, Jukka -- bashian roulette: $ ((RANDOM%6)) || rm -rf ~
Re: [dwm] lsx patch
Anselm R. Garbe --> dwm (2006-10-13 10:53:21 +0200):
> On Fri, Oct 13, 2006 at 10:45:17AM +0200, Jukka Salmi wrote:
> > Anselm R. Garbe --> dwm (2006-10-12 18:02:43 +0200):
> > > On Thu, Oct 12, 2006 at 05:45:21PM +0200, Cedric Krier wrote:
> > > > Here is a patch to add check for all user's groups instead of only the
> > > > real group.
> > >
> > > How portable is that? Can some BSD user check please?
> >
> > Seems fine to me: getgroups() is POSIX.1, and the patch makes lsx work
> > as expected at least on NetBSD.
> >
> > Cheers, Jukka
> >
> > BTW: lsx shouldn't need libX11...
>
> Indeed!
>
> Cedric, your patch is applied!
Why not just use access(2) (also POSIX.1) instead?
Cheers, Jukka
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
diff -r 9f363c099ba9 lsx.c
--- a/lsx.c Fri Oct 13 10:54:25 2006 +0200
+++ b/lsx.c Fri Oct 13 11:05:19 2006 +0200
@@ -7,30 +7,13 @@
#include
#include
#include
-#include
-
-static int
-ingroups(struct stat *s, int size, gid_t list[]) {
- int i;
-
- for(i = 0; i < size; i++)
- if(s->st_gid == list[i])
- return 1;
- return 0;
-}
int
main(int argc, char *argv[]) {
int i;
- gid_t gid = getgid();
struct dirent *dp;
struct stat s;
- uid_t uid = getuid();
DIR *dir;
- long ngroups_max;
- ngroups_max = sysconf(_SC_NGROUPS_MAX);
- gid_t gid_l[ngroups_max];
- int ngroups = getgroups(ngroups_max, gid_l);
if((argc > 1) && !strncmp(argv[1], "-v", 3)) {
fputs("lsx-"VERSION", (C)opyright MMVI Anselm R. Garbe\n",
stdout);
@@ -43,9 +26,7 @@ main(int argc, char *argv[]) {
if((dp = readdir(dir))
&& (stat(dp->d_name, &s) != -1)
&& S_ISREG (s.st_mode)
- && ((s.st_uid == uid && s.st_mode &
S_IXUSR) ||
- ((s.st_gid == gid ||
ingroups(&s, ngroups, gid_l))
- && s.st_mode & S_IXGRP) ||
(s.st_mode & S_IXOTH)))
+ && !access(dp->d_name, X_OK))
puts(dp->d_name);
while(dp);
closedir(dir);
Re: [dwm] lsx patch
Anselm R. Garbe --> dwm (2006-10-12 18:02:43 +0200):
> On Thu, Oct 12, 2006 at 05:45:21PM +0200, Cedric Krier wrote:
> > Here is a patch to add check for all user's groups instead of only the
> > real group.
>
> How portable is that? Can some BSD user check please?
Seems fine to me: getgroups() is POSIX.1, and the patch makes lsx work
as expected at least on NetBSD.
Cheers, Jukka
BTW: lsx shouldn't need libX11...
--
bashian roulette:
$ ((RANDOM%6)) || rm -rf ~
diff -r 0842010abe68 config.mk
--- a/config.mk Thu Oct 12 10:37:38 2006 +0200
+++ b/config.mk Fri Oct 13 10:41:10 2006 +0200
@@ -7,12 +7,9 @@ PREFIX = /usr/local
PREFIX = /usr/local
MANPREFIX = ${PREFIX}/share/man
-X11INC = /usr/X11R6/include
-X11LIB = /usr/X11R6/lib
-
# includes and libs
-INCS = -I/usr/lib -I${X11INC}
-LIBS = -L/usr/lib -lc -L${X11LIB} -lX11
+INCS = -I/usr/lib
+LIBS = -L/usr/lib -lc
# flags
CFLAGS = -Os ${INCS} -DVERSION=\"${VERSION}\"
