I cannot get a correct $? (ret code) of:

cat file.lst | xargs rm -

It always return 0 for me even though the files to be deleted do not exist.

Any thoughts?

What OS are you using?


Try

# cat file.list | xargs rm

Hello John

Works for me (although rm doesn't recognise the - option so takes it as a file name):Best

Charles

I am using RHEL5. Any suggestion?

There are two components involved here -- the shell and the rm command.

If you run the rm command on its own with identical arguments, does it set $? as expected?

If you run
echo XXX > /dev/null | false
then check $?, does the shell report 1 as expected from false?

Which rm are you using? Which shell are you using?

catkin is on the right track here. Whenever you use a pipe on the command line, the return code that is returned is not what you expect. You are getting the return code for part of the command, but not the whole line. I think that you answer will be in restructuring your command so that you don't have that pipe in it. Try ...

According to http://www.gnu.org/software/bash/man...html#Pipelines "The exit status of a pipeline is the exit status of the last command in the pipeline, unless the pipefail option is enabled (see The Set Builtin). If pipefail is enabled, the pipeline's return status is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands exit successfully."

But that's for bash; we don't yet know what shell John Lee is using.

In bash, the return status of a pipeline is this of the last command, even if some previous part of the pipeline failed. You can easily test with any meaningless command. For example, this should return non-zero:

While this will return 0, because the last command will suceed even if the previous one fails:

In a pipe, all commands run regardless if a previous one failed. Never forget that.

However, since bash 3.0 we can do this:

If you do this, the pipe will return the last non-zero exist status. Hence, the result of the last command in the pipe that failed. Again, regardless of the result, all the commands in the pipeline will run, which might not be the intended result.

Yes, you could do this, but this is not a proper solution. If the list of files is too long it will fail. If you absolutely need something like this, better use xargs, find -exec or a loop like this:

Or something similar.

I was unaware of this. Thank you catkin and j92guboj. I just remember a few years ago having run afoul return status when using a pipe, and have always just tried to stay clear of it. This is good to know.

Frankly, I understood the answers but not the question!