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.
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)
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: https://www.fvwm.org/Wiki/Tips/XTermRunDialogue/
But instead of quite just that, I have this script:
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":
Which also kills some other stuff that may be momentary annoyances cluttering the screen.
Openbox' rc file also has this:
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:
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:
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:
https://unix.stackexchange.com/a/504047
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:
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:
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.
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: https://www.fvwm.org/Wiki/Tips/XTermRunDialogue/
But instead of quite just that, I have this script:
Code:
#!/bin/sh 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
Code:
<keybind key="Escape">
<action name="Execute">
<command>bash -c "pkill -kill aosd_cat & kill -kill $(pidof mate-notification-daemon) & for p in gmrun fbrun bbrun ; do pkill -kill $p ; done ; kill -kill $(cat /dev/shm/xterm-run-pid)" </command>
</action>
</keybind>
Openbox' rc file also has this:
Code:
<application name="fvwm-run-dialog" type="normal" title="Run..." class="XTerm">
<!-- <decor>no</decor> -->
<focus>yes</focus>
<skip_taskbar>yes</skip_taskbar>
<layer>above</layer>
<position force="yes">
<x>center</x>
<y>top</y>
</position>
</application>
And lastly, to .Xresources I've added:
Code:
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
"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:
Code:
#!/bin/sh
#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
wait
hf=~/.xterm-run-history
sed -ie 's|&$||;s|[ \t]*$||;/^$/d' ~/.xterm-run-history
#notify-send $HISTFILE
hftmp=/dev/shm/hftmp
tac $hf > $hftmp ; cat -n $hftmp | sort -uk2 | sort -nk1 | cut -f2- > ${hftmp}2 ; tac ${hftmp}2 > $hf
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:
https://unix.stackexchange.com/a/504047
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:
Code:
<action name="Execute">
<command>bash -c "pkill -kill aosd_cat & kill -kill $(pidof mate-notification-daemon) & for p in gmrun fbrun bbrun ; do pkill -kill $p ; done ; kill -kill $(pgrep -a xterm | grep run-dialog | sed 's|\ .*||')" </command>
</action>
</keybind>
On the init file I also have:
Code:
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'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.
Total Comments 0
