From ArchWiki
Jump to: navigation, search

Troubleshooting Section - Shebangs and a toor alternative

In general I would concur that the shebangs are usually sufficient to ensure that most scripts run in the proper shell. And I run fish as my normal user and have run it as the root shell in the past. That being said not all scripts are properly written. In particular scripts with a #!/bin/sh have been known to contain bash specific syntax as most linux systems use bash in bourne compatability mode for /bin/sh (I think debian uses dash, and the BSDs still have bourne shell)

If someone is truely paranoid about a critical script being run they should of course run the default shell. But these methods seem hackish ways to keep the default shell and use fish. Why not go the old root/toor route and have two users with the same uid/gid different names and different shells. I actually run all of my root accounts like this with bash as root and fish as toor just in case something is broken and expecting bash.

To get a toor account that uses fish run:

# useradd -ou 0 -g 0 toor
# passwd toor
# chsh -s /usr/bin/fish toor

And then instead of su call su toor and everything else is the same as root (even the prompts say root) you just have a different shell. I imagine that the same could be done with a regular user say 'johndoe' and a user 'johndoefish' that has a different default shell.

Not publishing this on the page without comment since toor has been superceeded for it's intended use purposes (it was used for recovering root but now we have single user mode and bin isn't seperate anymore). However, the concept seems transferable to the question at hand as the desire is to have one user with two shells and that is one thing toor was used for.

Michorn (talk) 05:57, 6 November 2014 (UTC)

1. A #!/bin/sh script will still be run under /bin/sh, whatever that may be, not fish.
2. All scripts must have a shebang line, or be invoked via an argument to a predefined shell (e.g. bash script). ./script with no shebang line would cause something like:
Failed to execute process './script'. Reason:
exec: Exec format error
The file './script' is marked as an executable but could not be run by the operating system.
3. "Bash in bourne compatibility mode" isn't really bourne compatible then, is it? All I can say is that developers really should know what language they're writing in.
4. The mentioned "pseudo-default shell" methods, if you will, do seem kind of hacky, but kind of not. I'm not sure how I feel about them. Personally, I just changed my default shell for my own user account, and left root as bash (though I often switch into fish under root). It's trivial to bring up a bash shell under fish, if one feels the need.
5. Thanks for the toor trivia. That is indeed a clever hack that I wasn't aware of. Still, it seems like more work than invoking your desired shell from your current one. Most of the time, applications only start the default shell interactively; they don't normally run commands under it.
6. As for publishing the toor solution, I feel like on one hand it would just add bloat to the section which is, in my opinion, already a non-issue in the first place. On the other hand, it probably deserves a spot just as much as the other solutions, however much or little that may be.
Bottom line: toor isn't a bad solution, but I have yet to see a demonstration of any problem caused by fish being set as the default shell.
-- EscapedNull (talk) 03:22, 7 November 2014 (UTC)
If the script has a proper shebang line, then there won't be a problem, you are right. However, /etc/profile and the scripts in /etc/profile.d don't have such lines and fish doesn't execute them by default, resulting in a system with a broken environment. (At least for me. Most notably, $PATH was basically empty)
-- Xandaros (talk) 22:45, 11 March 2015 (UTC)
An example of an issue which is present with fish as your default shell occurs when using ssh-copy-id. I got the following error when using ssh-copy-id. I attempted to run ssh-copy-id, and both my local user and remote user account had fish as the default shell. Here's the output:
Unsupported use of '&&'. In fish, please use 'COMMAND; and COMMAND'.
fish: 		mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1 ;     		             ^
Changing the remote shell to use bash resolves it. You can have similar issues with certain rsync options.
-- Process91 (talk) 19:37, 23 January 2016 (UTC)
I update the wording in the troubleshooting section. Please improve if you have better idea. Then we can close this topic.
--Fengchao (talk) 09:34, 12 February 2016 (UTC)
Closing. -- Rdeckard (talk) 17:10, 23 September 2016 (UTC)

Dash section

What's the value of the Fish#.2Fetc.2Fprofile_and_.7E.2F.profile_compatibility ? The principle is the same (relying on a different shell to set up the environment), yet the execution is poor at best with an adhoc sed filter and hardcoded variables. The approach further has no practical benefits, and the introduction duplicates Fish#Not_setting_fish_as_default_shell. -- Alad (talk) 12:14, 18 September 2016 (UTC)

I'm in agreement that dash content should be removed. -- Rdeckard (talk) 18:44, 18 September 2016 (UTC)
All right, removed with [1] -- Alad (talk) 21:31, 18 September 2016 (UTC)
So... we remove the information that makes setting fish as your default shell dead simple, then tell people that setting fish as your default shell is too hard and not to do it? Why? - Joshua Bennett (talk) 01:54, 19 September 2016 (UTC)
Adding exec fish to .bashrc seems even more dead simple than adding the removed text to the fish configuration while setting the default shell to fish, and it ends up with less problems? Also see Alad's comment above which explains the decision. -- Rdeckard (talk) 02:13, 19 September 2016 (UTC)