On Sat, 22 Jul 2000, Alexander Langer wrote:

> Thus spake Matthew Orgass (darkstar@pgh.net):
> > 1) truncate(2) is not general enough.  This should be fixed *before* a
> > utility to use it is created.
> 
> What do you mean w/ "general enough"?

  You cannot truncate sections of a file.  See BUGS in truncate(2). 

> > 2) truncate(1) should not create the file by default.
> 
> We've discussed that one on freebsd-arch for a long time and came to
> the conclusion, that it should create the file because of "POLA"
> (Principle of least astonishment): touch(1) and other tools that are
> expected to do different jobs do create files by default, too.
> (Remember: touch(1)'s job is to modify inodes, not to create files).

  I think it is much more astonishing to conform to an application with a
different purpose then to a system call with the same name.  Touch should
have had the opposite sense too, but we can't do anything about that now
and it at least the name sounds like it could create the file.  It is bad
enough that something called truncate can increase the size of a file;  it
would be even worse if it created the file by default. 

> > 4) "truncate file" should mean truncate to zero.
> 
> No, that's a security risk.

  Security obviously means something completely different to you then it
does to me.  How about a -i option so you can alias it along with rm and
cp?  If you just want "truncate file $SIZE" to fail if SIZE is not set,
then add an '=' modifier that means truncate to size but fail if no size
is given. 

Matthew Orgass
darkstar@pgh.net