3 ms·

Fish definitely has builtins, for example - cd - source, . - eval - string - and - or - builtin - command and many others. Not sure what the

by pxc 3y ago

Fish definitely has builtins, for example - cd - source, . - eval - string - and - or - builtin - command and many others. Not sure what the point of distinguishing between fish builtins and fish functions is; whether a builtin is shipped as a function distributed with fish or a reserved word in the fish evaluator seems like an implementation detail.

em-bee 3y ago
fish has grown and evolved. i was referring to this: Builtin commands should only be created when it cannot be avoided. echo, kill, printf and time are among the commands that fish does not implement internally since they can be provided as external commands. Several other commands that are commonly implemented as builtins and can not be implemented as external commands, including type, vared, pushd and popd are implemented as shellscript functions in fish. if i remember correctly, this led to some useful commands that are builtin elsewhere to be external binaries shipped with fish. but since those where not actually tied to the fish shell they could run without it, and if they ended up on the global path be accessible from other shells. the relevant text on the website has been changed, but it is referenced here: https://github.com/fish-shell/fish-shell/issues/612 https://github.com/fish-shell/fish-shell/issues/612 the discussion also points out that this has changed over time
- pxc 3y ago
  Idk if fish has ever shipped builtins that way, but doing so is pretty conventional and doesn't normally put those executables on the PATH. It's what libexec is for: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.htm... If you wanna add a builtin like that to your own distribution of fish, you could do it cleanly by keeping those binaries in /usr/lib or /usr/libexec and then wrapping them in a fish function that ships in fish's install prefix. (This is basically how fish's Python scripts for generating completions from manpages are shipped today.)
  - em-bee 3y ago
    doesn't normally put those executables on the PATH right, i don't remember the details, but when it happened it was probably fixed quickly. could even have been a packaging error in a distribution.

by pxc 3y ago

em-bee 3y ago

fish has grown and evolved. i was referring to this: Builtin commands should only be created when it cannot be avoided. echo, kill, printf and time are among the commands that fish does not implement internally since they can be provided as external commands. Several other commands that are commonly implemented as builtins and can not be implemented as external commands, including type, vared, pushd and popd are implemented as shellscript functions in fish. if i remember correctly, this led to some useful commands that are builtin elsewhere to be external binaries shipped with fish. but since those where not actually tied to the fish shell they could run without it, and if they ended up on the global path be accessible from other shells. the relevant text on the website has been changed, but it is referenced here: https://github.com/fish-shell/fish-shell/issues/612 https://github.com/fish-shell/fish-shell/issues/612 the discussion also points out that this has changed over time

pxc 3y ago
Idk if fish has ever shipped builtins that way, but doing so is pretty conventional and doesn't normally put those executables on the PATH. It's what libexec is for: https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.html https://refspecs.linuxfoundation.org/FHS_3.0/fhs/ch04s07.htm... If you wanna add a builtin like that to your own distribution of fish, you could do it cleanly by keeping those binaries in /usr/lib or /usr/libexec and then wrapping them in a fish function that ships in fish's install prefix. (This is basically how fish's Python scripts for generating completions from manpages are shipped today.)
- em-bee 3y ago
  doesn't normally put those executables on the PATH right, i don't remember the details, but when it happened it was probably fixed quickly. could even have been a packaging error in a distribution.