Page MenuHomeFreeBSD

Extract the DESKTOP_ENTRIES related targets.

Authored by mat on Jun 22 2017, 4:49 PM.
Referenced Files
Unknown Object (File)
Sun, Sep 17, 4:52 PM
Unknown Object (File)
Sun, Sep 17, 4:14 PM
Unknown Object (File)
Sun, Sep 17, 11:41 AM
Unknown Object (File)
Sat, Sep 9, 2:29 PM
Unknown Object (File)
Aug 15 2023, 8:36 AM
Unknown Object (File)
Aug 14 2023, 7:44 AM
Unknown Object (File)
Jun 27 2023, 4:07 PM
Unknown Object (File)
Jun 20 2023, 12:18 AM

Diff Detail

No Lint Coverage
No Test Coverage
Build Status
Buildable 14457
Build 14604: arc lint + arc unit

Event Timeline

This revision is now accepted and ready to land.Jun 22 2017, 5:01 PM
jilles requested changes to this revision.Jun 22 2017, 10:03 PM
jilles added a subscriber: jilles.
jilles added inline comments.

The previous code using echo|grep matched the suffix case-insensitively.


The expr syntax is invalid because / is interpreted as a division operator. Perhaps

case ${Icon} in
/*) ;;
    ${dp_ECHO_MSG} "${dp_PKGNAME}:  Makefile warning: in desktop entry ${entry}: field 3 (Icon) should be either absolute path or icon name without extension if installed icons follow Icon Theme Specification" ;;
This revision now requires changes to proceed.Jun 22 2017, 10:03 PM
mat edited edge metadata.
  • Fix the absolute path check.

This will work with the current implementation of expr, but it is not POSIX-compliant, since POSIX leaves it unspecified whether an initial ^ is special (the expression being implicitly anchored anyway).

mat marked an inline comment as done.Jun 23 2017, 3:08 PM
mat added inline comments.

True. On the other hand, I did check beforehand, there are no cases where the files are not lower cased.


But we do not run in the os called POSIX, we run on the OS called FreeBSD, where the behavior is currently very well defined.
If the behavior ever changes later, then all the code using it will need to change. We live in the now, with an eye of what is in the work, and not using tools because of a vague possibilty that one day the way they work may change is not how I see doing things. I mean, I could never do anything if it was the case.


Sorry for being less constructive here. The desired behaviour can be implemented using POSIX-compliant expr as ${dp_EXPR} "x${Icon}" : x/.

My point is not that we should restrict ourselves to POSIX features at all cost, but that an implementation using only POSIX features is preferable to an implementation using extensions if they are similar in other respects. In some situations, non-standard features unique to a system are more likely to change than standard features common with other systems.

Given that this feature (^ in : regular expression) is implemented the same way by GNU expr, it seems not unlikely to change, though.

  • Switch this one to grep, expr's posix is harder.

It looks like it will work.

This could be optimized a little but I think it is not worth gating the patch for it.

This revision is now accepted and ready to land.Jan 19 2018, 11:00 PM
This revision was automatically updated to reflect the committed changes.