kameleon write_in does not like EOF

[npf]

creating a bash script that makes use of

cat <<EOF
...
EOF

Fails.

This is mostly due to kameleon using the syntax itself internally unfortunately.

[npf]

moved to oar-team/kameleon#102

[npf]

alias is:

  - exec_in: |
      mkdir -p $(dirname @1);
      cat >@1 <<EOF
      @2
      EOF

changing EOF to e.g. EOF_KAMELEON_INTERNAL solves the issue.

[mickours]

Great! did you made a patch?

[npf]

I'm on it. Let me sleep a bit ;-)

[npf]

About cat <<EOF vs cat <<'EOF', is there a reason the prefer the former ? For what I see, having $VAR in the text (e.g. bash script) is error prone if not useless anyway ?

[mickours]

Maybe variable expansion is used in some recipe, frankly I don't know... I suggest to keep the default behavior just in case. 2017-04-12 14:20 GMT+02:00 Pierre Neyron <[email protected]>:

…

About cat <<EOF vs cat <<'EOF', is there a reason the prefer the former ? For what I see, having $VAR in the text (e.g. bash script) is error prone if not useless anyway ? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#32 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAzGwL8VUhPvS8newTmC2evPH7s7wImQks5rvMF6gaJpZM4M6r5s> .

[npf]

The current behavior breaks so defined bash scripts and I don't see how expansion could be used within the yaml and aliases definitions...
I will change it unless proven it breaks something.

[npf]

question: is exec_in executed in a sub shell ?

[npf]

This breaks the step bootstrap/ssh_config/prepare_ssh_config:

 - prepare_ssh_config:
  - on_bootstrap_init:
    - write_local:
      - $${ssh_config_file}
      - |
        Host $${kameleon_recipe_name}
        HostName 127.0.0.1
        Port ${SSH_FWD_PORT}
        User root
        UserKnownHostsFile /dev/null
        StrictHostKeyChecking no
        PasswordAuthentication no
        IdentitiesOnly yes
        LogLevel FATAL
        ForwardAgent yes
        Compression yes
        Protocol 2

${SSH_FWD_PORT} is not expanded. Look like the answer to my last question is no: microsteps are executed in a same shell.

[npf]

we could consider providing a different alias for cat <<'EOF'... also providing aliases that set the owner et perms for the file could be nice... For now I will just not use any alias in my recipe.