Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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 was marked as an exact duplicate of an existing 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

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 .