Hi @sumeetpatil , could you attach or paste a steady.sh file generated with this new config? That would simplify my review considerably. Thanks!

Ok, here you go -> steady_script.txt

An important consequence of this change is that the resulting file cannot be run anywere:

1. it must be in the very same machine where kaybee merge was run
2. the export must have been done immediately after the merge, or the data expected in the script might not be there (or might contain something different than they did when the export was executed)
3. the file must be run from a very specific directory, or it won't find .kaybee/merged./....

The latter is easy to solve, not so much the other two...

2. If there is no data in .merge. We get this error -

> kaybee export -t steady                                                                                               
2020/11/06 14:45:04 open .kaybee/merged: no such file or directory
Exported 1 statements to steady.sh

But still, the steady.sh is generated. My latest commit will handle the case of generating any junk data.

3. We can run it with specifying -f param like this -
   kaybee export -t steady -c project-kb/kaybeeconf.yaml -f project-kb/kaybee_backup/merged/CVE-2005-3745/statement.yaml

This would generate the script properly with the correct path. The script would contain something like this -
[ -f project-kb/kaybee_backup/merged/CVE-2005-3745/changed-source-code.tar.gz ] && tar -xf project-kb/kaybee_backup/merged/CVE-2005-3745/changed-source-code.tar.gz -C ./CVE-2005-3745

I am not saying that kaybee export would not work, but that the resulting script steady.sh would not work in a machine where you do not have the necessary .kaybee/merged/.... directories. This may seem obvious, but this limitation did not exist before:
one could generate a steady.sh script which would be totally self-contained and self-sufficient to import data into any steady backend. You see what I mean?

Ok, I understood