Confd_cli stops before EOF


I have a /bin/sh script that runs “confd_cli << EOF” style processing. Inside heredocument I call modified load command (defined via .cli file) that invokes another script. After that command I call “commit” but it never gets executed (even if the nested script does absolutely nothing).
It is not a confd bug, is it possible that some kind of confd configuration is doing this?

confd_cli -u admin -N <<EOF
$(echo “load merge” $AUTO_CONFIG_FILE_NAME)
exit no-confirm

Have you tested with something like this?:

$ cat
confd_cli -u admin -N <<EOF
exit no-confirm


I have. Before we had modified the load command it was working fine. I moved original load command to xload. Now the load command does some scripting and calls:

maapi --clicmd “xload merge some.config”

After the maapi command completes:

  • return code is 0

  • confd log reports “audit user: admin/130 CLI done”

I do some additional scripting and complete the script without “exit”.
Then I expect the “commit” to be called but the confd_cli just stops (with return code 0).
If I remove the load call from confd_cli, the commit is called.
Even if I remove everything from the load command script (except shebang), the commit is not called.

I guess that you need this in your clispec (from the man page):

   /clispec/$MODE/cmd/callback/exec/options/noInput (xs:token)
       The "noInput" element specifies that the command should not grab the
       input stream and consume freely from that. This option should be used
       if the command should not consume input characters. If not used then
       the command will eath all data from the input stream and cut-and-paste
       may not work as intended.

Per, you were right it solved the problem!
Would you be so kind and explain what exactly was going on because I do not understand it?

I’ll try… When you define a command in a clispec, the CLI engine by default doesn’t know what that command “wants to do” - e.g. even if you define arguments in the clispec, the command may also want to interact with the user, e.g. prompt for additional info and receive the resulting user input. Thus the CLI sends any user input to the command. This is typically no problem when you run the command in an interactive CLI session, since there won’t be any “user input”.

But when you run the command from within a script, that “user input” would have to be - or at least could be - present in the script file. Thus the CLI will by default send any data in the script file, that follows the command invocation, to the command. I.e. the “commit” in the file is actually sent to your command’s standard input (as are the “exit” commands in @cohult’s example). Your command doesn’t read it, but it is nevertheless “gone” when your command finishes.

The noInput tells the CLI that your command doesn’t want any “user input”, and the CLI will then not read any more input from the script file until your command has finished, at which point it will treat the remaining text in the script file as CLI commands.

1 Like