combined use of ID and ID_LIKE

[kewlfft]

Signed-off-by: Xrjy SSG xrjy@nygb.rh.bet (rot13)

[Arfrever]

You can extract multiple variables from a sourced file in this way:

eval "$(source /etc/os-release &>/dev/null; declare -A OS_RELEASE_DATA=([ID]="${ID}" [ID_LIKE]="${ID_LIKE}"); declare -p OS_RELEASE_DATA)"

And then use "${OS_RELEASE_DATA[ID]}" and "${OS_RELEASE_DATA[ID_LIKE]}".

So either directly case ":${OS_RELEASE_DATA[ID]}:${OS_RELEASE_DATA[ID_LIKE]}:" in or assign OS_RELEASE_ID="${OS_RELEASE_DATA[ID]}" and OS_RELEASE_ID_LIKE="${OS_RELEASE_DATA[ID_LIKE]}" and use case ":${OS_RELEASE_ID}:${OS_RELEASE_ID_LIKE}:" in.

[mgorny]

Don't abuse eval. Ever.

[Arfrever]

My solution avoids spawning 2 subprocesses and opening /etc/os-release twice for reading.

It is also possible to send contents of variables to temporary files, but that only avoids subprocess problem.

So there is no consensus that this would be any abuse of eval.

[mgorny]

There are many solutions to every problem, and the one using eval is almost always wrong.

[zmedico]

Here's a way to read the file once, without using eval:

for var in OS_RELEASE_ID OS_RELEASE_ID_LIKE; do
	read -r -d '' || break
	declare ${var}="${REPLY}"
done < <(source /etc/os-release >/dev/null 2>&1; printf -- '%s\0%s\0' "${ID}" "${ID_LIKE}")

[eli-schwartz]

You're all sort of missing the forest for the trees. Not only is eval (a dangerous thing which should only be used with care, and this doesn't qualify) completely unnecessary, you don't need two variables to begin with.

OS_RELEASE_POSSIBLE_IDS=$(source /etc/os-release >/dev/null 2>&1; echo "${ID}:${ID_LIKE}")

case ":${OS_RELEASE_POSSIBLE_IDS}:" in

The variables are used once, right here and now. They don't need to be uniquely available. No read loop hacks, no frivolous use of eval, no opening the file twice for reading, no forking bash into a second subshell on top of the first.

[zmedico]

Oh yes, now I see that the consumer joins them with a colon anyway, so it makes sense to join them in the subshell.

[kewlfft]

Implementation based on @eli-schwartz proposal, is there anything else needed?

[zmedico]

Please omit quotes for case statements, since they are unnecessary, just like in [[.

[zmedico]

This looks good, please remove the case statement quotes and squash all commits into one.

[kewlfft]

We should be good, how do I squash all commits now?

[eli-schwartz]

https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History#_squashing

[kewlfft]

Thanks @eli-schwartz , only one commit now

[kewlfft]

@zmedico is it good for merging or do you need anything from me? thanks

[zmedico]

Looks good, I planning to merge things this weekend and make a release.

[zmedico]

Merged in d5ed2a3, thanks!

[eli-schwartz]

I originally overlooked mentioning, that ID_LIKE can contain multiple, space-separated IDs. So this would really need to be ${ID_LIKE/ /:} or it would not detect any ID_LIKE that has multiple associations.

[kewlfft]

Good point, then ${ID_LIKE/ /:} will only separate the first 2 IDs with :, what about if there are 3 of them?
I think we want ${ID_LIKE// /:} here, do you agree?

[mgorny]

…or you could just, like, use space as the separator and then you wouldn't have to replace anything.

[eli-schwartz]

And then also quote the part in the case statement, then be personally responsible for making sure no one ever accidentally tries to optimize the leading and trailing spaces out of OS_RELEASE_POSSIBLE_IDS. But sure.

I'd personally avoid using spaces as a glob pattern match delimiter.

[kewlfft]

With spaces, the case patterns become quite heavy and more prone to errors.