Re^4: system and &>/dev/null

Replies are listed 'Best First'.
Re^5: system and &>/dev/null by Fletch (Bishop) on Oct 10, 2008 at 18:34 UTC
That's the idiom I've always seen used (seek then truncate), which is why I recommended it back in my post. Consulting APUE (well, technically the 1st edition of the same tome; pp 91-92), the discussion there indicates that while SVR4's `truncate(2)` could be used to extend a file (creating a hole) the 4.3+BSD version wouldn't extend the size of the file. So while seeking then calling truncate is possibly more effort than strictly necessary, it's probably more likely to work regardless of the underlying OS' `truncate(2)` semantics. The cake is a lie. The cake is a lie. The cake is a lie.	[reply]
Re^6: system and &>/dev/null by repellent (Priest) on Oct 10, 2008 at 21:28 UTC
Very interesting. Thanks for the explanation! Yes, I would also opt for the option of minimal effort for more robustness.	[reply]
Re^5: system and &>/dev/null by mscharrer (Hermit) on Oct 11, 2008 at 09:30 UTC
As Fletch already said: the seek before the truncate is to improve portability. The perldoc page of truncate says: The behavior is undefined if LENGTH is greater than the length of the file. so IMHO seek is used to extend the file length first. It works without seek under Linux but might not be under other OS. BTW, seek alone without truncate results in an empty (0-byte) file. For the usage of `eval` and `close return`: This is basic error handling, when either seek or truncate fails I close the filehandle and return, with returns undef(=false) so that the caller know it didn't work. Otherwise I return an non-zero value to show success.	[reply] [d/l] [select]