firecat53 / keepmenu

Dmenu/Rofi frontend for Keepass databases
GNU General Public License v3.0
203 stars 33 forks source link

Make dmenu_command work with `sh -c "dmenu (...)"` and other non-dmenu commands that end up running dmenu #30

Open wishfort36 opened 5 years ago

wishfort36 commented 5 years ago

Hi there! I was looking around for dmenu-based keepass interfaces and found this, which looks like exactly what I was looking for; but I have an issue with keepmenu.

The issue for is on how dmenu_cmd parses dmenu_command. For some context, I want to set the font size by hostname. The ini configuration file format does not support this, so I thought that i'd just set it in dmenu_command. So, I tried something like this:

dmenu_command = sh -c 'dmenu -fn "$([ "$(hostname)" = "machine1" ] && {echo font1; exit; }; [ "$(hostname)" = "machine2" ] && {echo font2; exit; }; echo fallback)"'

This works in the command line, but not in dmenu_command. I tried this with various quoting patterns, but to no avail. I took a look at the code, and found out that dmenu_cmd blindly assumes that the first part of dmenu_command is dmenu or rofi. This is rather unintuitive and makes it impossible to do what I wanted.

I therefore suggest that dmenu_cmd see dmenu_command as magic and not parse it, and rather only do a substitution with some magic string to insert arguments like ´-l´, allowing the user to place the magic string where appropriate. If you don't want to make this magic string mandatory, then it would be possible to assume that it'll work by appending the args to dmenu_command.

I'm aware that it's possible to write a wrapper script to dmenu, but making a file for something that can be done inline sounds like a script that shouldn't be.

firecat53 commented 5 years ago

I see what you're interested in doing, but I think that is adding way more complexity and potential for breakage to the script than is warranted.

How about using something like GNU Stow to manage your dotfiles and use a different config file for different machines. Example:

~/.dotfiles
├── laptop-keepmenu
│      └── .config
│          └── keepmenu
│              └── config.ini
└── desktop-keepmenu
       └── .config
           └── keepmenu
               └── config.ini

 cd ~/.dotfiles
 stow laptop-keepmenu

Now there will be a symlink created from ~/.dotfiles/laptop-keepmenu/.config/keepmenu/config.ini to ~/.config/keepmenu/config.ini. Repeat for desktop-keepmenu on your desktop. There are a bunch of ways to manage different configurations, any of which will be a better option for you in the long run for all of your dotfile needs.

wishfort36 commented 5 years ago

I already use stow to manage my dotfiles (the repo I haved named dotfiles is something I forked once and forgot). It is however, not the solution as I see it. The reason I'm averse to having multiple files / configurations in my dotfiles for a single program is that I used to do so in my previous setup, where I'd have different git branches per machine. That was tedious to maintain, so I decided on moving to a one-repo-for-all approach. That is why I am averse to using stow in the manner you have proposed.

As i've stated before, it is possible to make a dmenu wrapper script; but having a single-line script is not a script that is strictly necessary, and thus should not be.

On a more philosophical level, it may not be a good idea to parse and edit user input, as it is unpredictable; becasue the meaning of "dmenu_command" is vague and will be interpreted differently by different users, as with me trying to run sh -c dmenu as my dmenu_command.

By the way, it doesn't look like the options fn, nb, sf, sb, sf, b, and m are used for other purposes than being parsed by dmenu_cmd. As they can all be set in dmenu_command, they might as well not be there to be configured, as it adds extra options and a bit extra code on keepmenu's side. The exception to this is l, which is used by keepmenu outside of dmenu_cmd.