Hey Gophers,
I observed some sudden conduct when feeding a buffer to an exec.Command
.
There’s a software to create picture thumbnails, referred to as “vipsthumbnail”, that I’m utilizing in a pipeline structure like this:
vipsthumbnail stdin -o thumbnail.webp < authentic.jpeg
It creates the thumbnail as anticipated.
The go equal additionally works the identical method:
authentic, err := os.Open("authentic.jpeg")
if err != nil {
log.Deadly(err)
}
cmd := exec.Command("vipsthumbnail", "stdin", "-o", "thumbnail.webp")
cmd.Stdin = authentic
if err := cmd.Run(); err != nil {
log.Deadly(err)
}
Nonetheless, utilizing a buffer doesn’t work:
authentic, err := os.ReadFile("authentic.jpeg")
if err != nil {
log.Deadly(err)
}
cmd := exec.Command("vipsthumbnail", "stdin", "-o", "thumbnail.webp")
cmd.Stdin = bytes.NewReader(authentic)
if err := cmd.Run(); err != nil {
log.Deadly(err)
}
Utilizing a buffer, the vipsthumbnail software fails with some generic “unable to learn from stdin” message.
From the Go docs we get:
If Stdin is an *os.File, the method’s normal enter is linked on to that file.
In any other case, throughout the execution of the command a separate goroutine reads from Stdin and delivers that knowledge to the command over a pipe.
Is that this an implementation error within the vipsthumbnail software program not beeing in a position to deal with pipes correctly? How does it make a distinction for that software program in any respect? Is there something I can do in my Go code?
Thanks for all the assistance!
Did you strive with the golang bundle?
I attempted to make use of vipsthumbnail for instance for higher understanding the issue.
This subject is in regards to the variations of passing a buffer vs utilizing a file deal with for the exec.Command
. In my understanding, utilizing a buffer shouldn’t have an effect on the conduct of the command name.