> its not compatible with BASH's shell scripting, which means you often cant just run shell scripts written by others, you may have to reformat it a little first.
What exactly do you mean by “Shell scripts”? If the script contains a proper Shebang you can easily run it via `./script.sh`. If not you use: `bash ./script.sh`.
The biggest problem I have is scripts that are meant to be exec-ed from the interactive shell. For example, scripts that set environment variables and change the current directory.
I have several bash functions that need to be sourced to be included. For instance, I use `cdc` to change to my code directory, where I keep my source for projects I am working on. If I type `cdc name` it changes it to my projects source directory, save me a lot of keystrokes in a day as I have many that I flip between. This sourcing of a function is required due to the way cd is handled, and in it's current form, not directly usable under fish. Maybe it's easier under fish, but fish isn't backwards compatible to make this work out of the box.
CDPATH is not a very good bookmarking system, as you can't bookmark several directories that have the same name, and you are forced to bookmark all the siblings of the item you wish to bookmark, which can be a problem with flat hierarchies. So if bookmarking directories is the goal, CDPATH might not be the best way. And one off bookmarking functions are easy to write.
Admittedly for the description given, it does sound like CDPATH would work. But I'm going to assume there's a reason, and functions that change the current working directory are the perfect example of functions that can not be run in a subshell, so will have to be rewritten to fish, which is what the author was providing.
I simplified the example, cdc does more than just a change the directory. `cdc -t name` changes to the directory and attaches to the tmux session of the same name if it exists, and if it doesn't, sets up my tmux layout for development.
whilst reading your above comment i wondered why you chose not to use environment variables instead. e.g.:
$ export cdc_stuff='/Users/me/src/project_stuff'
$ cd $cdc_stuff
however, now it's clear.
in the event you're looking for alternatives, perhaps porting your code to (e.g.) ruby could work.
just in case, here's the isbn number of a book called, 'Build Awesome Command-Line Applications in Ruby 2,' from the pragmatic bookshelf: 978-1-93778-575-8
It seems a lot of people don't realize `bash`, `sh`, `zsh` etc... are executable binaries just like any other on the system, and that you don't need to be logged in to a bash shell to run bash scripts.
This isn't the case for sourced scripts. Running a script in bash from fish that changes your current directory will do one of two things: It'll move you to that directory but inside of a bash shell, or it will move you to that directory in a bash shell, bash's cd will return, and you'll be in the same directory as before, still in the fish shell.
I'm no CLI wizard, so when I sit down to make my own function or alias I'm going to be googling how to do it whether it's for Bash or Fish.
What I meant in my comment above is a lot of 'download an install' instructions in tutorials, and sometimes installation wizards for programs are written for bash, and can't be run without modification in Fish. Not a major setback, but for a Bash user it would just work.
What exactly do you mean by “Shell scripts”? If the script contains a proper Shebang you can easily run it via `./script.sh`. If not you use: `bash ./script.sh`.