firecfg: Only use fix_desktop_files automatically when run through sudo

[backspac]

It also fixes this error when running firecfg as root:

Error: this option is not supported for root user; please run as a regular user.

[rusty-snake]

Why? A loot user will end with unfixed .desktop files.

IMHO it would be better to make it conditional either add --nofix or better:

if ROOT AND SUDO {
  fix_desktop_files()
}

[backspac]

Right. I see what you mean.
My main issue was that I was trying to setup a Pacman hook and it ran with errors.
In these conditions, I still have to manually run firecfg --fix as my regular user whenever I install a new desktop application.
Why doesn't firecfg handle /usr/local/share/applications? I don't see why it overwrites executables system-wide but desktop files user-wide.

[glitsj16]

My main issue was that I was trying to setup a Pacman hook and it ran with errors.

What went wrong exactly?

Why doesn't firecfg handle /usr/local/share/applications? I don't see why it overwrites executables system-wide but desktop files user-wide.

I think the choice for ${HOME}/.local/share/applications is to ensure desktop integration works (more) reliable due to it having precedence over /usr/local/share/applications. E.g. a non-firecfg'ed firefox.desktop under ${HOME} would be executed rather than what firecfg would drop under /usr/local. That would onlt create confusion and/or a false sense of security IMO.

[backspac]

What went wrong exactly?

When I run pacman -Syu, I get this "error":

(#/#) Configure symlinks in /usr/local/bin based on firecfg.config...
error: command failed to execute correctly

I say "error" because everything went fine in the end. It's just reported as such. It's mainly due to firecfg returning 1.

@rusty-snake's fix is a good solution to this issue IMHO.

That would only create confusion and/or a false sense of security IMO.

That makes sense, but don't you think it would be even better to make the package manager take care of everything, like putting desktop files in /usr/local/share/applications, and then giving the user the possibility to run firecfg --fix locally to go beyond security-wise.
In this way, it wouldn't require a manual action from the user every time they install a new application.

[rusty-snake]

@backspac do you want do add this conditional fix?

[backspac]

There you go.
Should I make a new issue for the handling of /usr/local/share/applications?

[rusty-snake]

Should I make a new issue for the handling of /usr/local/share/applications?

You can, but ATM there is one who fix firecfg bugs. That's why I started firecfg.py, I plan to suport also /etc/xdg/autostart.

[rusty-snake]

Merged, Thanks.