Currently, to make a location on the host filesystem accessible at some location in the plugin filesystem, we have the --map-path option, host and plugin paths separated by a ">". For example, to map the path /host/example on the host filesystem to a path /example on the plugin filesystem, you could add the flag --map-path /host/example>/example. A few users have expressed some confusion with this option, partially due to the way this behavior is named, and partially because of its use.
Matricks calls this behavior "mapping", but a more universal term for this sort of behavior is "mounting". Other tools, such as dylibso's Hermit, do a similar task by separating the host and WASM locations with a ":" instead of a ">".
So, to keep more in line with what other tools are doing, instead of --map-path [HOST]>[PLUGIN], change it to --mount [HOST]:[PLUGIN]. Doing this will involve:
Currently, to make a location on the host filesystem accessible at some location in the plugin filesystem, we have the
--map-pathoption, host and plugin paths separated by a ">". For example, to map the path/host/exampleon the host filesystem to a path/exampleon the plugin filesystem, you could add the flag--map-path /host/example>/example. A few users have expressed some confusion with this option, partially due to the way this behavior is named, and partially because of its use.Matricks calls this behavior "mapping", but a more universal term for this sort of behavior is "mounting". Other tools, such as dylibso's Hermit, do a similar task by separating the host and WASM locations with a ":" instead of a ">".
So, to keep more in line with what other tools are doing, instead of
--map-path [HOST]>[PLUGIN], change it to--mount [HOST]:[PLUGIN]. Doing this will involve:map_pathoption inclargs.rstomountmap_pathin the code tomountclargs.rsto describe the new usage