Hacker News Reader

Comment by laputan_machine | Hacker News Reader

Yes, it really is odd, I couldn't figure it out so switched back to zsh.

The specific issue was to do with a script we had to run to gain ssh access to an internal network. I can't post the script, but it was related to openssh.

Even logging into bash and running the script didn't work, I had to remove all fish binaries, symlinks, etc and set my shell to bash/zsh. Maybe it was an issue with how I installed fish, but yeah like I said, very strange, but I can vouch that I've encountered a similar issue before

It's a real shame because I think the fish syntax alone is worth the switch, for my personal machine(s) I use it.

Edit: this was years ago now, about 4 years, maybe the issue doesn't exist anymore but it caused me a bit of grief at the time (beacuse I didn't know it was related to using fish!), I've not since tried it again. I might try again and get back to this thread

View on HN

> I had to [...] and set my shell to bash/zsh

Most likely a command in your script (or one source-d into it) makes an assumption about your $SHELL or login shell that is true for bash/zsh but not for fish.

Merely adding a shebang won't fix such a script.

See my other comment and let me know if that script contains

  ssh-agent $SHELL ...

  exec $SHELL ...

  eval "$SHELL ..."

or similar. :)

If it ends up passing a script file or arguments to $SHELL and you wanna fix it without rewriting it, just add some conditionals where $SHELL is used and use the equivalent flags or syntax when $SHELL indicates fish.

Alternatively, if you just wanna work around it, just launch that script like

  env SHELL=(which zsh) whatever-script.sh

fish doesn't have builtins but all fish commands are external binaries or fish functions. i think at one point early in the history of fish those binaries may have been installed on the global path so they were accessible outside of fish and possibly there was a name conflict with one of them that this script triggered.

although such a name conflict should not have happened (and i can't think of which command such a script might have used that would also be a fish command), and the global path thing was also fixed soonish. but this is all a faint memory, so i am not sure i remember any of that right.

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.

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

the discussion also points out that this has changed over time

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.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.)

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.

Reply on news.ycombinator.com