Welcome to the most active Linux Forum on the web.
Go Back > Blogs > linux-related notes
User Name


Just annotations of little "how to's", so I know I can find how to do something I've already done when I need to do it again, in case I don't remember anymore, which is not unlikely. Hopefully they can be useful to others, but I can't guarantee that it will work, or that it won't even make things worse.
Rate this Entry

Customized xterm as a "run" command dialog, instead of fbrun, rofi, gmrun, or whatever

Posted 09-20-2020 at 06:40 PM by the dsc
Updated 10-11-2020 at 04:54 PM by the dsc (title got largely cut out for some reason)
Tags run dialog

WARNING: it may cause some issues with bash_history files if not set up properly. If you run a xterm from it the xterm will inherit the command dialog history and so forth. I'm not even using it anymore, but rofi again.

I've just found out that this is possible, adapting from someone who in turn shared some tweaks to use it instead of yet another terminal:

But instead of quite just that, I have this script:


HISTFILE=~/.xterm-run-history xterm -xrm "xterm*allowTitleOps: false" -T "Run..." +sb -name fvwm-run-dialog -geometry 50x1 -e /bin/bash --init-file $H
OME/.run-dialog.bash-init &

echo $! > /dev/shm/xterm-run-pid
Where the custom HISTFILE points to a separate history file for the run dialog, edited from what I had with fbrun, deleting the lines fbrun somehow half-destroyed (it's an old bug), and the PID echoed would be eventually used to kill it with my Openbox' keybinding to "esc":

     <keybind key="Escape">
      <action name="Execute">
        <command>bash -c "pkill -kill aosd_cat &amp; kill -kill $(pidof mate-notification-daemon) &amp; for p in gmrun fbrun bbrun ; do pkill -kill $p ; done ; kill -kill $(cat /dev/shm/xterm-run-pid)" </command>
Which also kills some other stuff that may be momentary annoyances cluttering the screen.

Openbox' rc file also has this:

        <application name="fvwm-run-dialog" type="normal" title="Run..." class="XTerm">
      <!--         <decor>no</decor> -->
      <position force="yes">
Besides the keybinding to run the script itself with alt+f2, which in fact runs a meaningless script, "~/scripts/af2," which in turn just runs whatever I wish to set up as a run dialog, just because I find easier to manage it than the rc.xml + menu.xml, I can change it just once.

And lastly, to .Xresources I've added:

fvwm-run-dialog.VT100*translations: #override \n\
    <Key>Return: string(" &\n exit\n")
fvwm-run-dialog.VT100*Scrollbar: false
fvwm-run-dialog.VT100*faceSize: 24
fvwm-run-dialog.VT100*eightBitInput: false
fvwm-run-dialog.VT100*faceName: Inconsolata

fvwm-run-dialog.VT100*background: #FFF
fvwm-run-dialog.VT100*foreground: #000
fvwm-run-dialog.VT100*borderColor: #343434
fvwm-run-dialog*allowTitleOps: false
Which works because xterm on the script is told to rename itself as fvwm-run-dialog.

"Allowtitleops" is set twice, on .Xresources and on the xterm command itself, probably one of them somehow doesn't work, for some reason. I have it there so that the window title can be "Run..." rather than changing to the path, as I have for normal xterm.

In order to test it without re-starting X, one can use "xrdb ~/.Xresources" and "openbox --reconfigure," depending of what has been updated at a given time.

While it seems to work fine, faster to pop than rofi and without fbrun's history bug (maybe also allowing for a more complex command line than rofi, if I recall; fbrun had that advantage), I'm not sure that having xterm as a run dialog is really a good idea, though, maybe there are some cryptic "under the roof" stuff that may create some problems. I've once heard you shouldn't call things like gksu or kdesu from a terminal, that it would tend to eventually corrupt some config files, for some reason. Doesn't seem to make much sense to me, I'm not sure if that's a combination of *su with terminals specifically, or something more general with using terminals to start applications with GUIs. Maybe whoever told me this was just mistaken.

Some updates:

#trap "rm /dev/shm/xterm-run-pid " SIGINT SIGTERM SIGKILL EXIT

# sed -ie  's|&$||;s|exit||;s|[ \t]*$||' ~/.xterm-run-history

HISTFILE=~/.xterm-run-history xterm -xrm "xterm*allowTitleOps: false" -T "Run..." +sb -name fvwm-run-dialog -geometry 50x1 -e /bin/bash --init-file $HOME/.run-dialog.bash-init &

#echo $! > /dev/shm/xterm-run-pid
#sed -ie  's|&$||;s|exit||' ~/.xterm-run-history

sed -ie  's|&$||;s|[ \t]*$||;/^$/d' ~/.xterm-run-history
#notify-send $HISTFILE
tac $hf > $hftmp ; cat -n $hftmp | sort -uk2 | sort -nk1 | cut -f2- > ${hftmp}2 ; tac ${hftmp}2 > $hf
The whole tac/cat sequence makes it so that the history will have only one instance of each command, preserving the order, but changing it by having the last issued command for last.

I have also "sed" doing some clean-up. The way it works is that xterm will actually add a "&" so that the command runs in the background, plus an "exit" to xterm itself. Somehow it was getting added to the history. I've once heard fbrun was really xterm with such kind of tweaks, maybe it's in some of those history edits to clean up that the history gets ruined. Hopefully, I'm not accidentally reproducing the bug here, though.

Credits for the whole "tac" sequence go to those responsible for this answer in stackexchange:

The whole PID file to kill it with Esc, and the trap attempt failed (/bin/sh rather than bash, I suppose), I have it instead now:

  <action name="Execute">
        <command>bash -c "pkill -kill aosd_cat &amp; kill -kill $(pidof mate-notification-daemon) &amp; for p in gmrun fbrun bbrun ; do pkill -kill $p ; done ; kill -kill $(pgrep -a xterm | grep run-dialog | sed 's|\ .*||')" </command>
Which would eventually kill any other xterm that also had "run-dialog" on its command line, but that should be very unlikely to me.

On the init file I also have:

export HISTIGNORE="&:rm *:wx*:poweroff:shutdown *:reboot:trash *:trash-put *:yes y|rm*:yes y |rm*:yes y | rm*:yes y|rm*:yes y| rm*:su:ls:lsd:unhis"
export HISTCONTROL="ignorespace:ignoredups"

bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'

bind '"\e[1;5D" backward-word'

bind '"\e[1;5C" forward-word'
I don't think the histcontrol is really working, the whole humongous tac sequence is somehow emulating it with a different command. Maybe histocontrol "works" in the sense that perhaps the "history" command itself would filter accordingly, while the file itself would show the entire "raw" history, I don't know.

I've also added history completion with the up and down arrows, starting with up (instead of tab) and down to go back an alternative. The bind things, I already had on my .bashrc, copied from somewhere.
Posted in Uncategorized
Views 5871 Comments 0
« Prev     Main     Next »
Total Comments 0




All times are GMT -5. The time now is 02:19 AM.

Main Menu
Write for LQ is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration