Open wishfort36 opened 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.
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.
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.