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

runcommand: replace hard coded /dev/shm with log_dir, add a runcommand configuration menu item #3557

Closed

Conversation

twojstaryzdomu
Copy link

@twojstaryzdomu twojstaryzdomu commented Jun 16, 2022

This PR extends #3556 with a retropie menu configuration entry for the log/scratch area log_dir variable and replaces the remaining hard-coded /dev/shm values with the log_dir variable.

…use /tmp as fallback

This is to allow another directory for runcommand.sh outputs for cases when output are worth preserving (i.e. crash). Also, /dev/shm may not be accessible on all environments, for user discretionary reasons. When /dev/shm doesn't exist or isn't writable, Fall back to /tmp.
@joolswills
Copy link
Member

I'm not sure it needs to be in the GUI. But if I will add that I would prefer to do it in my previous PR rather than yours based on mine.

@twojstaryzdomu
Copy link
Author

I would consider the PR on its sole merit, not the fact of not being its author.

What is the case for the other runcommand.sh options in the GUI that have their configuration file equivalent? I considered the case of users who need persistency for their logs across crashes and the ability to update it quickly.
Your PR requires to dabble in manual editing configuration files, so it is hacky and inconsistent with the fact other options can be changed in the GUI.

@joolswills
Copy link
Member

joolswills commented Jul 14, 2022

Well I'd already started on the changes. I don't think it needs to be multiple commits and I'd like to implement it in the way I want. If that's ok.

@joolswills joolswills closed this Jul 14, 2022
@twojstaryzdomu
Copy link
Author

twojstaryzdomu commented Jul 14, 2022

Well I'd already started on the changes. I don't think it needs to be multiple commits and I'd like to implement it in the way I want. If that's ok.

Absolutely, you're entitled to prefer your own commits, even if they could be done better.

Had your PR been up to scratch, I wouldn't have submitted mine. The inconsistencies with the other configuration items being in the GUI is a fact.

It's up to you to decide but with my multiple PRs closed without merging, I just wonder if it's a pet project thing where maintainers settle for worse regardless of the actual merit. Is there a systemic problem with external contributions?

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

Successfully merging this pull request may close these issues.

None yet

2 participants