Sign up ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

This question already has an answer here:

My Script

find $HOME/OldLogFiles/ -type f -mtime -7 -exec ls -latr {} \; -exec echo was deleted on `date` \; -exec rm -f "{}" \;|paste - - >> $log

My goal for the script is to delete files older than x amount of days and then log them to a file and display the filename, date deleted, and how old it was. I keep getting these errors however...

./ line 3: $log: ambiguous redirect
find: ‘ls’ terminated by signal 13
find: ‘ls’ terminated by signal 13

Anybody have any suggestions?

share|improve this question

marked as duplicate by mpy, gronostaj, Breakthrough, soandos, Mokubai Jun 30 '13 at 22:52

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

Can you clarify exactly what you're trying to achieve here? It will help anybody trying to answer your question as well as anybody searching for similar questions. –  Andrew Lott Jun 28 '13 at 14:51
Sure I updated it for you. –  mkrouse Jun 28 '13 at 14:54
Downvote, because this is a follow-up to –  mpy Jun 28 '13 at 14:56
You're welcome. Just so you know, @mpy is only trying to be a good SU user, I am sure he has nothing against you personally and I have nothing but respect for the quality of his answers. We just disagree on this particular point. –  terdon Jun 28 '13 at 17:26
The -a option of ls is meaningless when applied to file argument(s). (ls –l .bashrc works fine; you don’t need to say ls –la.) And the -t and -r options are meaningful only when you have multiple arguments, or one (or more) directory argument. So, since you’re saying -type f, you might as well say just -exec ls -l {}. –  Scott Jun 29 '13 at 18:01

1 Answer 1

First of all, based on your previous question, you want -mtime +7 for 7 days or older. -mtime -7 means 7 days old or newer.

The ambiguous redirect error probably means that $log is not defined. I cannot reproduce your find: ‘ls’ terminated by signal 13 it probably depends on the specific files you have in the folder in question. Could you post the file list somewhere?

Anyway, signal 13 means a broken pipe so something is going wrong. Are you piping this command through head or tail or similar? Try this and see if you get the same errors:

find $HOME/OldLogFiles/  -type f -mtime +7 -exec stat -c "%n %y"  "{}" \; -exec echo was deleted on `date` \; |paste - - >>$log
share|improve this answer
ambiguous redirection can also be caused by white spaces in $log; try this in bash: log=$(date); echo foo > $log, this failes, while log=$(date); echo foo > "$log" is working fine. –  mpy Jun 28 '13 at 22:27
Well, putting the pieces together here: if there’s something about $log (such as unescaped, unquoted embedded spaces) that makes >> $log fail, then that means that the paste process never gets started, and so the find is piping into nothing. But find isn’t writing to its standard output; it’s only spawning child processes (ls and echo) that do. (rm also shares the same stdout; i.e., the broken pipe, but it doesn’t write anything to it.) So, each time find fork/execs ls and ls writes, it gets a broken pipe signal. –  Scott Jun 29 '13 at 17:58
The only question is: Why doesn’t echo exhibit the same behavior? I guess it probably has something to do with the fact that echo is a shell builtin command. –  Scott Jun 29 '13 at 17:59

Not the answer you're looking for? Browse other questions tagged or ask your own question.