@ander Look what seems to work:
if [ -f "$__object/parameter/foo" ]
then
while read -r line
I think we cannot distinguish such stdin from e.g. heredoc stdin. Or am I missing something?
@nico @steven We should add this as 'Caveats' to cdist type chapter.
We should document this. It's known since forever. The workaround e.g.:
# Generate and configure enabled host keys
comm -23 "$__object/files/enable-host-key" "$__object/files/disable-host-key"…
This is actually not cdist specific, but happens the same way with ssh - i.e. anything that likes to read stdion in a loop that you input stuff in
@nico Yee, it's not cdist specific, but it's specific for cdist that types always consume stdin.
also, there is probably only 2 more __acl users in the world besides me 😈
How about trying something like the following. Since type parameters are handled by python core then in that code we could see how easy/hard it is to support parameter deprecation. E.g. if parameter…
imho that's too much.
i could just leave old parameters intact, create type explorer which terminates if old explorers are used and call it a day.
so, basically it's a question about how much legacy support we want to do.
@nico what's your take on this? also see first comment @ !785
There is a general rule for this in cdist:
- In general, we try not to break the user ** More often than obvious at first sight, we can avoid breaking the user (see below)
- If we decide to break…