|
Home > Archive > Unix Shell > February 2007 > Ideas on command to zero out files on system?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Ideas on command to zero out files on system?
|
|
| snoopy_@excite.com 2007-02-09, 1:17 pm |
| I have error log files that I'd like to truncate once a week, and
can't figure out how to do this using find.
I tried:
find /logdir -type f -name "*.err" -exec cat /dev/null > {} \;
I aslo tried piping it to xargs, but I'm missing something here.
I am trying to avoid using a script or for loop because I need it in a
remote application to send commands over.
for x in /logdir/*.err
do
cat /dev/null > $x
done
| |
| Stephane CHAZELAS 2007-02-09, 1:17 pm |
| 2007-02-9, 09:48(-08), snoopy_@excite.com:
> I have error log files that I'd like to truncate once a week, and
> can't figure out how to do this using find.
>
> I tried:
> find /logdir -type f -name "*.err" -exec cat /dev/null > {} \;
Here, you're redirecting find's output to a file called {}.
Try
find /logdir < /dev/null -type f -name "*.err" -exec tee {} \;
.... > file
is a shell operator, not a find operator. ">" and "file" are not
passed as arguments to find, it's a way to tell the shell to
open a shell for writing and make that the stdout of the command
the shell will run (here "find"). It can be anywhere on the
command line. Above, I've intentionaly put there in the middle
for demonstration purposes.
--
Stéphane
| |
| Stephane CHAZELAS 2007-02-09, 1:17 pm |
| 2007-02-09, 18:07(+00), Stephane CHAZELAS:
> 2007-02-9, 09:48(-08), snoopy_@excite.com:
>
> Here, you're redirecting find's output to a file called {}.
>
> Try
>
> find /logdir < /dev/null -type f -name "*.err" -exec tee {} \;
>
> ... > file
>
> is a shell operator, not a find operator. ">" and "file" are not
> passed as arguments to find, it's a way to tell the shell to
> open a shell for writing and make that the stdout of the command
a file
sorry.
Also:
find /logdir -type f -name "*.err" -exec cp /dev/null {} \;
Or
find /logdir -type f -name "*.err" -exec sh -c '
for f do
: > "$f"
done' inline {} +
--
Stéphane
| |
|
| Why Truncation ?
Instead delete the file.
In next write these files will be recreated.
siva
On Feb 9, 11:10 pm, Stephane CHAZELAS <this.addr...@is.invalid> wrote:
> 2007-02-09, 18:07(+00), Stephane CHAZELAS:
>
>
>
>
>
>
>
>
>
>
> a file
>
> sorry.
>
> Also:
>
> find /logdir -type f -name "*.err" -exec cp /dev/null {} \;
>
> Or
>
> find /logdir -type f -name "*.err" -exec sh -c '
> for f do
> : > "$f"
> done' inline {} +
>
> --
> St=E9phane- Hide quoted text -
>
> - Show quoted text -
| |
| Stephane CHAZELAS 2007-02-10, 7:22 am |
| 2007-02-10, 00:18(-08), swami:
[PLEASE DO NOT TOP POST][vbcol=seagreen]
> Why Truncation ?
> Instead delete the file.
> In next write these files will be recreated.
[...]
No, it's open(2) with (O_CREAT) or creat(2) that creates a file.
If a process does a write(2) on a file that it opened before it
was unlinked, then it will keep writing to the unlinked file.
So if those *.err files are actually currently open by some
process (with O_APPEND), deleting them will be a lot worse than
truncating them as first it will not free the disk space and
second, it will cause further output by the process to be lost.
--
Stéphane
| |
| snoopy_@excite.com 2007-02-21, 7:16 pm |
| On Feb 10, 3:38 am, Stephane CHAZELAS <this.addr...@is.invalid> wrote:
> 2007-02-10, 00:18(-08), swami:>> find /logdir -type f -name "*.err" -exec=
sh -c '
>
> [PLEASE DO NOT TOP POST]> Why Truncation ?
>
> [...]
>
> No, it's open(2) with (O_CREAT) or creat(2) that creates a file.
> If a process does a write(2) on a file that it opened before it
> was unlinked, then it will keep writing to the unlinked file.
>
> So if those *.err files are actually currently open by some
> process (with O_APPEND), deleting them will be a lot worse than
> truncating them as first it will not free the disk space and
> second, it will cause further output by the process to be lost.
>
> --
> St=E9phane
Thanks, cp /dev/null works like a champ, and I can't see any
difference between the two. Thanks.
| |
| Stephane CHAZELAS 2007-02-21, 7:16 pm |
| 2007-02-21, 11:18(-08), snoopy_@excite.com:
[...]
[...][vbcol=seagreen]
> Thanks, cp /dev/null works like a champ, and I can't see any
> difference between the two. Thanks.
The discussion was between deleting and truncating.
cp -- /dev/null "$f" is just a less efficient way to truncate "$f".
It is functionnaly equivalent to
: > "$f"
--
Stéphane
|
|
|
|
|