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

Add 'custom' status plugin to get status texts from external scripts. #163

Merged
merged 4 commits into from
Apr 27, 2023

Conversation

pataquets
Copy link
Contributor

@pataquets pataquets commented Jul 10, 2022

Allow custom status plugins by way of invoking arbitrary scripts (only within plugin scripts' directory).
Script output will be passed as status text (which can be also tmux's status bar placeholders, such as #{host}). The plugin name is custom:followed by the script, which must reside in the plugins dir and be executable (symlinks are OK). Otherwise an error will be shown in the plugin slot. Declaring multiple plugins works OK.
Added corresponding @dracula-custom-plugin-colors variable, as done in all plugins, all custom plugins have the same colour, thou, which I think it's fine (just interleave them). However, I can devise a fix, if required.

Example
Adding to plugins custom:cpu_info.sh would mimic adding the cpu-usage plugin. Drop your custom script or symlink in the plugins dir and adjust name as needed.

Remaining tasks
Documentation: Just added a notice in the readme. I guess it should go here, when it's reviewed & merged.

I can also send a PR with a command: (or should it be shell:?) plugin to run custom commands (eg. cat ~/file.txt). However, it would require the read -r -a for plugins to be a read -a to allow spaces. I didn't send in case it's not acceptable, but it "Works on My Machine:tm:" :grin:.

@ethancedwards8
Copy link
Member

Great work. This is something we really need.

Some comments though:
Documentation that is reflected on the website is listed in the INSTALL.md file. When you add that, can you also add an example of it's usage? It's not super obvious to me.

Also, I would be okay with allowed the script to be sourced elsewhere. I do not think it's necessary to have to put it in the scripts directory and that could make things a bit messy potentially.

@pataquets
Copy link
Contributor Author

Great work. This is something we really need.

Happy to hear that, @ethancedwards8 . I'll try to get to resolving conflicts soon, as master has changed.

Some comments though: Documentation that is reflected on the website is listed in the INSTALL.md file. When you add that, can you also add an example of it's usage? It's not super obvious to me.

Will do.

Also, I would be okay with allowed the script to be sourced elsewhere. I do not think it's necessary to have to put it in the scripts directory and that could make things a bit messy potentially.

I can see the benefits of doing so and agree about decluttering the scripts dir. I did that as everything else was done under current dir. The only concern I had when coding this is that invoking scripts outside the plugin's dir might be a security risk, if you don't check some untrusted config copied elsewhere, but I admit it's a marginal reason, thou. Just to make sure, I understand you're OK with that, right?

@ethancedwards8
Copy link
Member

Yes, I think the responsibility ultimately falls on the user to verify that the external scripts (that are unsupported by the Dracula team) are not malicious.

@ethancedwards8 ethancedwards8 merged commit e859815 into dracula:master Apr 27, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

2 participants