find: ‘ls’ terminated by signal 13 error

bash logging

5,639

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

5,639

mkrouse

Noob

Updated on September 18, 2022

Comments

mkrouse over 1 year
My Script
```
log=$HOME/Deleted/$(date)
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...
```
./test.sh: line 3: $log: ambiguous redirect
find: ‘ls’ terminated by signal 13
find: ‘ls’ terminated by signal 13
```
Anybody have any suggestions?
- Andrew Lott almost 11 years
  
  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.
- mkrouse almost 11 years
  
  Sure I updated it for you.
- mpy almost 11 years
  
  Downvote, because this is a follow-up to superuser.com/q/612930/195224
- terdon almost 11 years
  
  @mpy so? What if it is a follow up? Nothing wrong with that, the OP very correctly posted a new question rather than cluttering the comments of their previous question. That is exactly what they should do. There is no reason to downvote, it is a perfectly clear question.
- mkrouse almost 11 years
  
  @terdon Thanks for sticking up for the little guy! :)
- terdon almost 11 years
  
  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.
- Scott - Слава Україні almost 11 years
  
  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 {}.
mpy almost 11 years

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.
Scott - Слава Україні almost 11 years

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 - Слава Україні almost 11 years

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.