Closed #2657.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2657#event-10574182185
You are receiving this because you are subscribed to this thread.
Message ID:
___
Rpm-maint mailing list
Merged via #2708 since there's been no activity on this PR. Thanks for the
patch + report!
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2657#issuecomment-1750508612
You are receiving this because you are subscribed to this thread.
@dmnks requested changes on this pull request.
Mentioned above.
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2657#pullrequestreview-1623916057
You are receiving this because you are subscribed to this thread.
Message ID:
Indeed. It makes one wonder why the file is formatted in a shell-like fashion
:smile: Also, I just noticed this is also what `man os-release` illustrates in
the `Example 3. Reading os-release in sh(1)` section.
--
Reply to this email directly or view it on GitHub:
Heh, yeah sometimes the most obvious answer is just too obvious :smile:
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2657#issuecomment-1717115125
You are receiving this because you are subscribed to this thread.
Message ID:
> Hmm, wouldn't `COMMAND sh -c ". /etc/os-release; echo ${var}"` achieve the
> same thing, by letting the shell do the work instead?
Yep, that's the "canonical" way to use `/etc/os-release`. For some reason, I
didn't realize this when adding this cmake helper.
@dmikushin, feel free to update
Hmm, wouldn't `COMMAND sh -c ". /etc/os-release; echo ${var}"` achieve the same
thing, by letting the shell do the work instead?
--
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2657#issuecomment-1717082230
You are receiving this because
