elves / elvish

Powerful scripting language & versatile interactive shell
https://elv.sh/
BSD 2-Clause "Simplified" License
5.62k stars 300 forks source link

Expose more Go `os` package functions (e.g., `os.Remove`) #1659

Open krader1961 opened 1 year ago

krader1961 commented 1 year ago

While rewriting my Bash scripts into Elvish to automate tasks, such as building and testing Elvish on all my systems, I noticed I was running this shell command on my primary development system: rm -f elvish. It shouldn't be necessary to run an external command to do that. Yet I couldn't find an existing Elvish builtin to do the same thing. So I am opening this issue to propose that the Go os package be exposed (not necessarily in its entirety) as an Elvish module. Alternatively, we might want to implement portions of the os package in other Elvish modules; e.g., the file or path module. I am ambivalent about which approach is preferable since a precedent has already been established by file:open wrapping the Go os.Open function. We'll probably want to continue building on that precedent by adding a path:remove builtin that wraps the Go os.Remove function. However, I feel this needs some discussion before anyone creates a pull-request.

krader1961 commented 1 year ago

Note that resolving this issue also enables resolving issue #1661 since it would allow replacing a lot of external commands used by the epm module with Elvish builtins.

krader1961 commented 1 year ago

This comment by @xiaq on my change to implement a path:remove has caused me to think more about this issue. There are reasonable arguments for and against deviating from the Go packaging of this functionality in Elvish. After sleeping on the question I am inclined to agree that OS specific functionality, such as removing files or creating directories, should live in an Elvish os module. There is a good argument that such functionality applies to file paths and therefore should reside in the Elvish path module. But on balance I agree with @xiaq that such functionality is fundamentally tied to interacting with the OS rather than manipulating filesystem path names (such as by concatenating path name components).

TBD is what to do about the existing path:is-dir and path:is-regular commands. Arguably they should be deprecated and moved to an os module. And if they aren't deprecated and moved what does that mean for new commands such as os:stat (aka path:stat) I want to see implemented?