Ah okay, thanks seank. I was missing the fact that we can embed multiple
files by specifying multiple patterns and assign it to a single `embed.FS`.
Now it all makes sense. Thanks!
On Monday, 5 July 2021 at 20:56:28 UTC+1 seank...@gmail.com wrote:
> `embed` embeds the files with the path you specified, so if you look into
> your `static` variable, the files will be available as
> `files/static/yourfile`.
> This means there won't be issues with filename collisions etc... if you
> specify multiple patterns
>
> If you want to serve your files in your `files/static` directory under the
> `/static/` url, your handler should be : `http.Handle("/static/",
> http.FileServer(http.FS(static.Sub("files"))))`
> That is, for everything under the `/static` url, serve from the embedded
> filesystem, skipping over the `files/` prefix in the embedded fs.
>
> On Monday, July 5, 2021 at 8:30:37 PM UTC+2 Amnon wrote:
>
>> What does
>>
>> go list -f '{{ .EmbedFiles }}'
>>
>> display?
>>
>> On Monday, 5 July 2021 at 06:28:54 UTC+1 tjgur...@gmail.com wrote:
>>
>>> Hi there,
>>>
>>> I have been testing the (relatively) new go:embed feature for a few days
>>> and I came across this situation which I wasn't quite sure what was causing
>>> it so I thought asking here would help.
>>>
>>> Consider the following code:
>>>
>>> ```golang
>>> package main
>>>
>>> import (
>>> "embed"
>>> "fmt"
>>> "log"
>>> "net/http"
>>> )
>>>
>>> //go:embed files/static
>>> var static embed.FS
>>>
>>> func main() {
>>> http.Handle("/static/", http.StripPrefix("/static/",
>>> http.FileServer(http.FS(static))))
>>> log.Fatal(http.ListenAndServe(":8000", nil))
>>> }
>>>
>>> ```
>>>
>>> Now the files in directory files/static are very much accessible but the
>>> issue I seem to have is that it was accessible under the url
>>> /static/files/static/filename instead of just being accessible through
>>> /static/filename where filename exists inside the directory files/static/
>>>
>>> I tried looking up some examples online and it seems that I have to use
>>> the fs.FS and fs.Sub and only expose (not sure if this is correct
>>> terminology) the new fs.Sub which would mitigate the issue I was having.
>>>
>>> My question is about the reason why the Go team went with this
>>> implementation? Because in the above program I wasn't able to access the
>>> files in files/ directory even though there were files in it and was only
>>> able to access files inside the files/static files directory. So there
>>> doesn't seem to be a point in this implementation unless I'm missing
>>> something, and I'm sure its the latter case haha. If anyone knows about why
>>> they went with this implementation, I would be very grateful.
>>>
>>> Best wishes
>>> Taj
>>>
>>>
>>>
--
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.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/50a029e2-0ead-458a-801f-418d54bd96f8n%40googlegroups.com.
