As discussed in a YouTube comment (https://www.youtube.com/watch?v=KEWhOzDCfLg&lc=UgzqmZf7hgBRjGLe-Pp4AaABAg), the `cd` commands to "return" back to the original directory are unnecessary, because it is *impossible* for a script to change the working directory of a shell.
When you run a `cd` command in a script, the working directory does change, but only for the script. When the script exits, nothing has happened to the working directory of the shell where you ran the script.
In fact, it is *impossible* for a script to change the working directory of the shell, even if you wanted to do that. Some ways you can change the working directory:
- an alias that runs a `cd` command (an alias is equivalent to running the commands in your shell)
- `alias gohome="cd ~"
- a shell function that runs a `cd` command (this is the primary reason why things like z.lua are implemented as a shell function, not a script)
- `function gohome() { cd ~ }`
- sourcing a script (so there is a way to do it with a script, but you have to run the script in a specific way, and this will also make exit quit the shell, not just the script)
- `source ./script-name`
These are the ways I know of doing it, there may be some others.
Even if a script could change the shell's working directory, `fla.sh` is doing `cd "$PWD"`, which is basically a no-op, because `$PWD` is automatically updated:
```bash
echo "$PWD"
# go to the flashcard decks directory
cd "$DIR"
echo "$PWD"
```
The above outputs:
```
/home/sami
/home/sami/.local/share/flash
```
So, doing `cd $PWD` actually would not return back to the original directory, it would stay in whatever directory you've cd'd into.
-----
Another minor change in this PR is to output errors to stderr instead of stdout (before this change, errors were output to stdout).
With `fla.sh`, this doesn't really make much of a difference, but generally you want to output errors to stderr. This is useful, if you want to run a script quietly, but still want to see errors. If errors are output to stderr, this can be done with by running e.g.:
```bash
./script-name > /dev/null
```
The above will hide all regular output (redirecting stdout to `/dev/null`), but will still show anything output to stderr (i.e. error messages). To also hide error messages (make a script run completely silently), you can run:
```bash
./script-name > /dev/null 2>&1
```
The above `2>&1` syntax redirects stderr (`2>`) to the same place where stdout is redirected, and `> /dev/null` is redirecting stdout to `/dev/null`.
To only hide error messages, but show regular output, you could run `./script-name 2> /dev/null`, but that might not be a smart thing to do (if there are errors, you probably want to know about them).
The proposed change uses `>&2`, which redirects stdout to stderr, so that regular print commands (e.g. `echo`) are displayed on stderr. Both stdout and stderr are shown similarly in a terminal, but they're still separate, so they can be redirected, etc. Some terminals may also show stderr messages differently.
Both `echo "..." >&2` and `>&2 echo "..."` work identically, but I've used `>&2 echo "..."` because I think it's more intentional ("the following output is an error"), and if there's a long error message, the `>&2` could get "lost" at the end of a line. I picked it up on Stack Overflow, and I've used it ever since:
https://stackoverflow.com/a/23550347
* Applied shfmt formatting
* Minor optimizations
Some if-else flows only contained 1 statement, in shell, a shorter
version of those can be achieved by using the conditional operators,
among other tiny edits.
* Extra safety for multiple conditions
This is probably unnecessary, but just for extra safety, braces can be
added.
Add the documentation for changing the FZF previewer binary. The help
page kind of looks weird now that the alignment is off. That is
something that might need to be refactored in the future.
This commit adds a way of changing the FZF previewer by using the `-p`
flag. An example of this might look like:
$ flash -p cat
This will use cat has the FZF previewer instead of bat. However, it keeps bat as
the default program in all cases unless specifically changed by the `-p`
parameter. There are also checks to see if the provided binary actually
exists on the system. If it exists on the system, it checks if it
supported by flash. If it isn't supported by flash, it falls back onto
bat as the default previewer. For now, only bat and cat are supported but it.
can easily be expanded.