Hey there, I saw your message / responded to it in the gophers Slack channel but I thought I'd reply here too. I think one thing we should clarify for the mailing list is that this _seems_ to impact Darwin (OS X) and not Linux, based on testing done by users in Slack. I was also able to replicate it on Darwin but admittedly did not try on Linux.
I've modified your example a bit to try and read the file again after the command exits, by opening it using its path using ioutil.ReadFile(), to make sure that vim is definitely writing the data: - https://goplay.space/#EXPdpNfID1 Interestingly enough, this new read from the file does contain the content. That means that, for some reason, the file handle (*os.File) you get on OS X doesn't seem to observe the new content being written to the file. I've done some spelunking through the standard library, and while assembly isn't my forte I'm not absolutely sure this is a bug in the Go stdlib itself. Yes this could be a case where the Go stdlib isn't doing something right, but the code hits the open syscall pretty quickly on Darwin. This makes me wonder if the file handle given back by the Darwin kernel doesn't observe the changes, therefore trying to seek will only give you the data that the file descriptor saw at the time of opening. I am curious what the root cause is too, as this is interesting. Cheers! -Tim On Sunday, August 20, 2017 at 9:56:32 PM UTC-7, Alexandru Bonini wrote: > > https://play.golang.org/p/_rudr2_Vyc > > I don't understand why any change done via vim is not reflected by > b.String(). > I can see the changes in the tempfile. > Any help is appreciated. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
