Recent changes to bugs

BASHRUN_XDOCLASSNAME bugs

2010-11-09T08:26:23Z

The variable BASHRUN_XDOCLASSNAME is not exported, so it is not picked up by other commands that use it. This results in a serious problem - since the window name matching is not done specifically against the class name, any window with the word bashrun in its title may get selected, and cause it to get unmapped instead of bashrun! The matching should always be done by xdotool using --classname. In light of the above issue, I don't see the need to set this variable to --name either, since it can lead to unpredictable results.
I've changed the relevant line to
export BASHRUN_XDOTOOL BASHRUN_CLEARMODS BASHRUN_XDOCLASSNAME
to make sure that all functions get the the right value of $BASHRUN_XDOCLASSNAME="--classname"

'xdotool search' causes delay in window mapping

2010-11-09T08:16:52Z

Hi
bashrun uses xdotool to map its window if it is hidden. To do this, xdotool first needs to obtain the window id, which it searches for using the 'xdotool search' command. However, this causes a noticeable delay every time it is invoked, since the search for the window id is repeated every time. To make the bashrun prompt show up quicker, an alternative is needed.
I've currently fixed this by caching the window id in a file every time bashrun starts, and mapped my hotkey to a small script, bashrunner, which reads this and runs xdotool windowmap directly:
---bashrunner---
#!/bin/sh
xdotool windowmap `cat $HOME/.cache/bashrun/bashrun.wid`
[ $? -ne 0 ] && bashrun
------

I've modified bashrun to write to bashrun.wid by adding this line near the end:

echo $BASHRUN_WID > $CACHE_DIR/bashrun.wid

This solves the problem for me. Now bashrun shows up instantly when I press the hotkey. The bashrunner script can also be integrated into the main file, or one may consider a more elegant solution instead.

seg fault

2010-09-07T10:58:10Z

hello, just upgraded to 0.16 and now bashrun won't run, with the following error:

$ bashrun
/usr/bin/bashrun: line 600: 14991 Segmentation fault $XTERM -name 'bashrun' -title 'bashrun' -geometry $GEOMETRY +sb -bg $BGCOLOR -fg $FGCOLOR $XTERM_OPTIONS -e "/bin/bash --rcfile $BASHRC $bashopts"

any ideas?
thanks

Please cd to $HOME

2010-05-01T22:02:01Z

I just noticed on my newly upgraded Ubuntu Lucid system that when I run bashrun from a hotkey on the desktop, it seems to be run with cwd "/" (before it was run with cwd "$HOME"). This means that when I use it to start an xterm, the shell inside the xterm starts with cwd / too, which is a bit unfriendly. It would seem sensible for bashrun to cd to $HOME when it starts up.

shopts passed to /bin/sh

2010-05-01T22:00:25Z

If I make a LOGFILE, I get an error for every command I run that shopts cannot be found. It seems that the "shopts extdebug" command is being passed to /bin/sh, which is dash on my system. This is clearly incorrect. Turning on debugging, I see that is_executable? is run on shopts, and hence it decides to pass it to "execute" and run it as a command. I am not sure why exactly this is happening.

However, it doesn't seem to be very important.

Broken with Bash 4.102

2010-01-28T20:41:51Z

Exits with "line 534: BASHOPTS: readonly variable"

Bug 2807287 not fixed

2009-11-20T22:29:35Z

(Sorry, I can't re-open the original bug, nor find the source code so I can check whether it's been fixed since 0.14.)

install.sh still runs bashrun using sh, so it doesn't work.

Meta doesn't work in key bindings

2009-10-04T19:06:28Z

With key bindings such as \e\C-m for term-run, I can't press Meta-Ctrl-M, I have to type Escape, Ctrl-M. I'm not sure why, as similar bindings in my regular ~/.inputrc work fine.

Terminal Hold Infinite Loop

2009-08-31T23:58:42Z

The while true loop done for the terminal hold feature is very wasteful on resources. I had two terminals held for a while and never realized that it was using 100% of my two processors and single-handedly brought up the temperature by 20C.

I changed all instances of "while true; do :; done" with "read" instead. This way it holds on to the terminal until I press Enter. I like this way better, but if you prefer it to only be killed manually with a ^C you could at least stick a sleep in there.

install and uninstall can be used by non-root users

2009-06-16T17:39:41Z

I often install programs under ~/local rather than /usr/local. If I remove the check for running as root, install.sh and uninstall.sh work perfectly well for this case.

I think the simplest solution is to remove the check: if you run as a non-root user and try to install under the default location of /usr/local, you will get a perfectly comprehensible error message of "permission denied".