Will this actually update the 'last modified' date for an already existing file?
Also, there's a standard way of processing command line arguments on Linux/Unix, which is not being followed here.
Will this actually update the 'last modified' date for an already existing file?
Also, there's a standard way of processing command line arguments on Linux/Unix, which is not being followed here.
Major bug in the first command.
Technically, yes, it updates the last modified date, by actually emptying the file. He should have use "w+" or "a" instead of "w".
PS: I like this guy.
What I have never found any use for personally is opening a file in read-write mode, while also truncating it, which is the full extent of w+ behaviour. I cannot think of many reasons to have an output stream to also function as an input.
Yeah, but we have plain "w" for that already.
> What I have never found any use for personally is opening a file in read-write mode, while also truncating it, which is the full extent of w+ behaviour. I cannot think of many reasons to have an output stream to also function as an input.
Exactly my point. If I am about to fully overwrite the file content, why would I want to re-read them without even an intermediate fclose()? I know that content already, I've just wrote it out! The only fringe use cases I can think of are really the edge cases of some general scenarios that would normally use "r+" (e.g. databases) but could occasionally go "okay, let's drop everything and start ab initio" — but those can just call ftrunc() in those circumstances. Or just open the file twice with different modes, the filesystem being what it is (global shared mutable state), you'll see your changes through.
In natural language, this leads to semantic drift. In programming languages, semantic drift leads to bugs.
But, okay, that could make a valid excuse.
But, what you cannot excuse yourself for, is that you don't really add any functionality. In fact, you don't reproduce all the functionality let alone adding more.