From: UnixOS2 Archive
To: "UnixOS2 Archive" <UnixOS2_Archive at unixos2.com>
Date: Wed, 26 Mar 2003 05:00:39 EST-10EDT,10,-1,0,7200,3,-1,0,7200,3600
Subject: [UnixOS2_Archive] No. 82

**************************************************
Tuesday 25 March 2003
 Number  82
**************************************************

Subjects for today
 
1  Re:  FYI - Truncating logs. : Dave Saville" <dave.saville at ntlworld.com>

**= Email   1 ==========================**

Date:  Wed, 26 Mar 2003 08:39:48 +0000 (GMT)
From:  "Dave Saville" <dave.saville at ntlworld.com>
Subject:  Re:  FYI - Truncating logs.

On Mon, 24 Mar 2003 08:53:08 -0800, Steven Levine wrote:

>In <20030324082916.GKSX310.mta05-svc.ntlworld.com at pooh>, on 03/24/03 
>   at 08:26 AM, "Dave Saville" <dave.saville at ntlworld.com> said:
>
>>I have found out that it would appear to be OK on OS/2 to do the cat
>></dev/null >some log Unix trick to truncate an open log. 
>
>>Unfortunately the cmd shell allows >nul but not <nul. I have tested from
>>the command line with cat - >log and given it a ^D and it seems OK on the
>
>What shell are you using?  Some OS/2 shells are more brain dead than
>others.  With 4OS2:
>
>[d:\tmp\00instal]cat - </dev/nul >tmp.txt
>
>[d:\tmp\00instal]cat tmp.txt
>
>[d:\tmp\00instal]

That is totally non standard behavior.

If you want cat to take stdin you either give it - or no file name
according to the help.

cat - >outputfile

Or if you want cat to take stdin from some file

cat somefile >outputfile 

cat - or cat <somefile actually hangs waiting for keyboard i/p. On
*nix, cat file and cat <file behave the same way ie it makes no
difference if there is a redirect present.

but cat - </dev/null > somefile works without reading the keyboard.
Note that /dev/null does not exist.

In fact I just found that cat /dev/null >outputfile works - There
must be internal magic in the os/2 version that looks for a file name
of /dev/null and mimics *nix.

And in answer to Sebastian's question - it basically resets the file
system write pointer to the start of the file - the fact that the
file is open is the whole point. If you have a server process that
*has* to be up but also produces large log files they very quickly
become unmanageable. So what you do is run a script with cron that
copies the log file and resets the pointer so the server process
keeps on happily logging. Its common practise on *nix systems. Even
if you don't copy the file you can get the disk space back this way
without having to stop the server. On *nix you can delete an open
file and it disappears from a directory listing - but as far as the
process(es) that have it open are concerned its still there until the
count of processes that have it open is zero - then it *really* gets
deleted. Until then of course it is still taking up space. 

-- 
Regards

Dave Saville