Your approach to replacing the built-in save pipe command should work; perhaps paths in your clispec file are not correct?
But custom completions probably cannot work like that; I believe completions like this (i.e. using the <completion/> element) can be used only for completing in the context of auto-rendered commands. You can use completion points attached to types though - i.e. you define a YANG-modeled type, use it in your clispec file and attach a completion point to it. Have a look at the cli/completions example.
I have added the delete of existing save command, forgot to add it in the comment/question.
but the back end script does not receive any input from the previous command.
I have also tried with a different name like xsave but still face the same issue
That part options/pipeFlags should not be there. I don’t think it makes sense to add a pipeFlag to “itself”.
What I did is that I took your clispec snippet, added it to the introductory ConfD example’s commands-c.cli, did few modifications for my environment, removed that pipeFlags option, and it works. If it does not work in your environment, something must be wrong with that.
If I remove the options/pipeFlag, I see the new command ‘xsave’ in pipe options.
Also the tab completion works. But the backend callBack/exec/osCommand (file_utils.sh) hooked to ‘xsave’ does not receive the output of ‘file show’ ( complete command: file show test.log | save log/test1.log)
I am expecting to redirect the out of ‘file show’ to ‘xsave’ so that I could process it using the callBack/exec/osCommand (file_utils.sh), the osCommand is invoked with out any input(I have printed the command line arguments (’$@’) in shell script and they were empty).
How can I pass the output of file show to the new pipeCmd ‘xsave’.
You write that $@ is empty - that’s weird, it should contain exactly two arguments:
the file_save string that you declare as an argument
the file parameter.
If it does not, it means something else is not working as it should. But in either case, the input data is not provided through arguments, you should read it from stdin, so in your shell script using read or something like that.
sorry for the confusion.
When I said $@ was empty, I meant it does not have any data from previous command ‘file show’.
We tried in the following ways
Initially tried to read the input using “read”(read $input), as we do in shell script to read input from redirection. When I tried to print the data read from ‘read’ it was empty.
We also tried like below
if [ -p /dev/stdin ]; then
echo “Data was piped to this script!”
# If we want to read the input line by line
while IFS= read line; do
echo “Line: ${line}”
done
fi
to check if the data piped to script.
In the both the above cases, we only see “file_save log/test1.log” in both command line arguments and in data read from ‘read’ call.
Are you sure /dev/stdin needs to be (a link to) a pipe? In my environment it is a link to a socket; not sure how this can be, but simply -p test may not work.