Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
wishfort36 opened this issue Mar 24, 2019 · 2 comments

Comments

@wishfort36
Copy link

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
Copy link
Owner

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants