github-mirror/fish-shell
2
0
Fork 0
mirror of https://github.com/fish-shell/fish-shell.git synced 2024-11-23 01:36:39 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity
9e01981bb9
fish-shell/doc_src/tutorial.rst

759 lines
27 KiB
ReStructuredText
Raw Normal View History

Switch to fish_indent based syntax highlighting in sphinx docs
2019-03-15 04:52:25 +08:00
.. highlight:: fish-docs-samples
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Link tutorial immediately
2019-12-11 01:47:14 +08:00
.. _tutorial:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Tutorial
========
Why fish?
---------
docs: Use "fish" without markup in tutorial Work towards #6785. [ci skip]
2020-09-21 02:12:50 +08:00
Fish is a fully-equipped command line shell (like bash or zsh) that is smart and user-friendly. Fish supports powerful features like syntax highlighting, autosuggestions, and tab completions that just work, with nothing to learn or configure.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Use "fish" without markup in tutorial Work towards #6785. [ci skip]
2020-09-21 02:12:50 +08:00
If you want to make your command line more productive, more useful, and more fun, without learning a bunch of arcane syntax and configuration options, then fish might be just what you're looking for!
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Getting started
---------------
Once installed, just type in ``fish`` into your current shell to try it out!
You will be greeted by the standard fish prompt,
which means you are all set up and can start using fish::
> fish
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
Welcome to fish, the friendly interactive shell
docs: Remove some more html See #5696. [ci skip]
2019-04-30 18:53:15 +08:00
Type help for instructions on how to use fish
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
you@hostname ~>
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some on the tutorial Try to clarify and simplify some wording and move the wildcards/redirection section behind variables because they are more important
2023-04-28 23:09:39 +08:00
This prompt that you see above is the fish default prompt: it shows your username, hostname, and working directory. You can customize it, see :ref:`how to change your prompt <prompt>`.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: don't quote code snippets The added single quotes don't look great in HTML, and it's already clear that the monospaced text is to be interpreted literally.
2020-04-14 04:54:33 +08:00
From now on, we'll pretend your prompt is just a ``>`` to save space.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Learning fish
-------------
docs: Use "fish" without markup in tutorial Work towards #6785. [ci skip]
2020-09-21 02:12:50 +08:00
This tutorial assumes a basic understanding of command line shells and Unix commands, and that you have a working copy of fish.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Use "fish" without markup in tutorial Work towards #6785. [ci skip]
2020-09-21 02:12:50 +08:00
If you have a strong understanding of other shells, and want to know what fish does differently, search for the magic phrase *unlike other shells*, which is used to call out important differences.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some rewording to the tutorial Add a link to fish-for-bash-users, mention string collect, some reformatting
2021-05-28 23:35:29 +08:00
Or, if you want a quick overview over the differences to other shells like Bash, see :ref:`Fish For Bash Users <fish_for_bash_users>`.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Add some links (and remove a stray sentence)
2021-07-17 00:08:55 +08:00
For the full, detailed description of how to use fish interactively, see :ref:`Interactive Use <interactive>`.
For a comprehensive description of fish's scripting language, see :ref:`The Fish Language<language>`.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Running Commands
----------------
docs: Use "fish" without markup in tutorial Work towards #6785. [ci skip]
2020-09-21 02:12:50 +08:00
Fish runs commands like other shells: you type a command, followed by its arguments. Spaces are separators::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo hello world
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
hello world
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
This runs the command ``echo`` with the arguments ``hello`` and ``world``. In this case that's the same as one argument ``hello world``, but in many cases it's not. If you need to pass an argument that includes a space, you can :ref:`escape <escapes>` with a backslash, or :ref:`quote <quotes>` it using single or double quotes::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> mkdir My\ Files
docs: Some rewording to the tutorial Add a link to fish-for-bash-users, mention string collect, some reformatting
2021-05-28 23:35:29 +08:00
# Makes a directory called "My Files", with a space in the name
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> cp ~/Some\ File 'My Files'
docs: Some rewording to the tutorial Add a link to fish-for-bash-users, mention string collect, some reformatting
2021-05-28 23:35:29 +08:00
# Copies a file called "Some File" in the home directory to "My Files"
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> ls "My Files"
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
Some File
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Getting Help
------------
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
Run ``help`` to open fish's help in a web browser, and ``man`` with the page (like ``fish-language``) to open it in a man page. You can also ask for help with a specific command, for example, ``help set`` to open in a web browser, or ``man set`` to see it in the terminal.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> man set
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
set - handle shell variables
Synopsis...
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some more on tutorial and combiners
2022-12-27 21:17:27 +08:00
To open this section, use ``help getting-help``.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some on the tutorial Try to clarify and simplify some wording and move the wildcards/redirection section behind variables because they are more important
2023-04-28 23:09:39 +08:00
This only works for fish's own documentation for itself and its built-in commands (the "builtins"). For any other commands on your system, they should provide their own documentation, often in the man system. For example ``man ls`` should tell you about your computer's ``ls`` command.
docs: Some more in the intro sections
2022-12-27 22:22:17 +08:00
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Syntax Highlighting
-------------------
docs/tutorial: Replace coloring markup This used to use doxygen's html blocks, which don't have a *direct* equivalent in sphinx in code blocks. Instead of adding this to the pygments highlighter, let's just use some roles. It's a teensy bit awkward as we then use block styling, but we want to add more of our own styling anyway, so we can presumably get this somehow, and these html tags look awkward and confuse people. Fix #6640 [ci skip]
2020-02-23 01:01:05 +08:00
.. role:: red
.. role:: gray
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
.. role:: prompt
.. role:: command
.. role:: param
.. role:: param-valid-path
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
You'll quickly notice that fish performs syntax highlighting as you type. Invalid commands are colored red by default:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
.. parsed-literal::
docs: Fix background color for interactive examples For the few weird code blocks where default highlighting does not work, we must add the 'highlight' class manually to get matching backgrounds. This reuses the background color defined in pygments.css.
2020-09-02 11:48:59 +08:00
:class: highlight
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
:prompt:`>` :red:`/bin/mkd`
docs/tutorial: Replace coloring markup This used to use doxygen's html blocks, which don't have a *direct* equivalent in sphinx in code blocks. Instead of adding this to the pygments highlighter, let's just use some roles. It's a teensy bit awkward as we then use block styling, but we want to add more of our own styling anyway, so we can presumably get this somehow, and these html tags look awkward and confuse people. Fix #6640 [ci skip]
2020-02-23 01:01:05 +08:00
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
A command may be invalid because it does not exist, or refers to a file that you cannot execute. When the command becomes valid, it is shown in a different color::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> /bin/mkdir
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
Valid file paths are underlined as you type them:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
.. parsed-literal::
docs: Fix background color for interactive examples For the few weird code blocks where default highlighting does not work, we must add the 'highlight' class manually to get matching backgrounds. This reuses the background color defined in pygments.css.
2020-09-02 11:48:59 +08:00
:class: highlight
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
:prompt:`>` :command:`cat` :param-valid-path:`~/somefi`
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: don't quote code snippets The added single quotes don't look great in HTML, and it's already clear that the monospaced text is to be interpreted literally.
2020-04-14 04:54:33 +08:00
This tells you that there exists a file that starts with ``somefi``, which is useful feedback as you type.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
These colors, and many more, can be changed by running ``fish_config``, or by modifying :ref:`color variables <variables-color>` directly.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Document turning off suggestions/history Also add more mentions of `fish_config` in general.
2021-10-22 23:08:41 +08:00
For example, if you want to disable (almost) all coloring::
fish_config theme choose none
This picks the "none" theme. To see all themes::
fish_config theme show
Just running ``fish_config`` will open up a browser interface that allows you to pick from the available themes.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Autosuggestions
---------------
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
As you type fish will suggest commands to the right of the cursor, in gray. For example:
.. parsed-literal::
docs: Fix background color for interactive examples For the few weird code blocks where default highlighting does not work, we must add the 'highlight' class manually to get matching backgrounds. This reuses the background color defined in pygments.css.
2020-09-02 11:48:59 +08:00
:class: highlight
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
:prompt:`>` :red:`/bin/h`:gray:`ostname`
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
It knows about paths and options:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
.. parsed-literal::
docs: Fix background color for interactive examples For the few weird code blocks where default highlighting does not work, we must add the 'highlight' class manually to get matching backgrounds. This reuses the background color defined in pygments.css.
2020-09-02 11:48:59 +08:00
:class: highlight
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
:prompt:`>` :command:`grep` :param:`--i`:gray:`gnore-case`
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
And history too. Type a command once, and you can re-summon it by just typing a few letters:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
.. parsed-literal::
docs: Fix background color for interactive examples For the few weird code blocks where default highlighting does not work, we must add the 'highlight' class manually to get matching backgrounds. This reuses the background color defined in pygments.css.
2020-09-02 11:48:59 +08:00
:class: highlight
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
:prompt:`>` :red:`r`:gray:`sync -avze ssh . myname@somelonghost.com:/some/long/path/doo/dee/doo/dee/doo`
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use canonical key names in :kbd: tags This seems a bit better because it's what bind uses. To makes sure that something like :kbd:`ctrl-x` looks good in HTML, remove the border from the kbd style. Else both "ctrl" and "x" get small boxes which looks weird.
2024-04-14 02:30:07 +08:00
To accept the autosuggestion, hit :kbd:`right` (``→``) or :kbd:`ctrl-f`. To accept a single word of the autosuggestion, :kbd:`alt-right` (``→``). If the autosuggestion is not what you want, just ignore it.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Document turning off suggestions/history Also add more mentions of `fish_config` in general.
2021-10-22 23:08:41 +08:00
If you don't like autosuggestions, you can disable them by setting ``$fish_autosuggestion_enabled`` to 0::
set -g fish_autosuggestion_enabled 0
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Tab Completions
---------------
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
A rich set of tab completions work "out of the box".
docs: use canonical key names in :kbd: tags This seems a bit better because it's what bind uses. To makes sure that something like :kbd:`ctrl-x` looks good in HTML, remove the border from the kbd style. Else both "ctrl" and "x" get small boxes which looks weird.
2024-04-14 02:30:07 +08:00
Press :kbd:`tab` and fish will attempt to complete the command, argument, or path:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
.. parsed-literal::
docs: Fix background color for interactive examples For the few weird code blocks where default highlighting does not work, we must add the 'highlight' class manually to get matching backgrounds. This reuses the background color defined in pygments.css.
2020-09-02 11:48:59 +08:00
:class: highlight
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use canonical key names in :kbd: tags This seems a bit better because it's what bind uses. To makes sure that something like :kbd:`ctrl-x` looks good in HTML, remove the border from the kbd style. Else both "ctrl" and "x" get small boxes which looks weird.
2024-04-14 02:30:07 +08:00
:prompt:`>` :red:`/pri`:kbd:`tab` => :command:`/private/`
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
If there's more than one possibility, it will list them:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
.. parsed-literal::
docs: Fix background color for interactive examples For the few weird code blocks where default highlighting does not work, we must add the 'highlight' class manually to get matching backgrounds. This reuses the background color defined in pygments.css.
2020-09-02 11:48:59 +08:00
:class: highlight
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
docs: use canonical key names in :kbd: tags This seems a bit better because it's what bind uses. To makes sure that something like :kbd:`ctrl-x` looks good in HTML, remove the border from the kbd style. Else both "ctrl" and "x" get small boxes which looks weird.
2024-04-14 02:30:07 +08:00
:prompt:`>` :red:`~/stuff/s`:kbd:`tab`
docs: Some more on tutorial and combiners
2022-12-27 21:17:27 +08:00
~/stuff/script.sh :gray:`(command)` ~/stuff/sources/ :gray:`(directory)`
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some more on tutorial and combiners
2022-12-27 21:17:27 +08:00
Hit tab again to cycle through the possibilities. The part in parentheses there (that "command" and "directory") is the completion description. It's just a short hint to explain what kind of argument it is.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
fish can also complete many commands, like git branches:
.. parsed-literal::
docs: Fix background color for interactive examples For the few weird code blocks where default highlighting does not work, we must add the 'highlight' class manually to get matching backgrounds. This reuses the background color defined in pygments.css.
2020-09-02 11:48:59 +08:00
:class: highlight
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use canonical key names in :kbd: tags This seems a bit better because it's what bind uses. To makes sure that something like :kbd:`ctrl-x` looks good in HTML, remove the border from the kbd style. Else both "ctrl" and "x" get small boxes which looks weird.
2024-04-14 02:30:07 +08:00
:prompt:`>` :command:`git` :param:`merge pr`:kbd:`tab` => :command:`git` :param:`merge prompt_designer`
:prompt:`>` :command:`git` :param:`checkout b`:kbd:`tab`
docs: Some more on tutorial and combiners
2022-12-27 21:17:27 +08:00
builtin_list_io_merge :gray:`(Branch)` builtin_set_color :gray:`(Branch)` busted_events :gray:`(Tag)`
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
Try hitting tab and see what fish can do!
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Variables
---------
docs: Some rewording to the tutorial Add a link to fish-for-bash-users, mention string collect, some reformatting
2021-05-28 23:35:29 +08:00
Like other shells, a dollar sign followed by a variable name is replaced with the value of that variable::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo My home directory is $HOME
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
My home directory is /home/tutorial
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some rewording to the tutorial Add a link to fish-for-bash-users, mention string collect, some reformatting
2021-05-28 23:35:29 +08:00
This is known as variable substitution, and it also happens in double quotes, but not single quotes::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo "My current directory is $PWD"
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
My current directory is /home/tutorial
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo 'My current directory is $PWD'
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
My current directory is $PWD
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some more on tutorial and combiners
2022-12-27 21:17:27 +08:00
Unlike other shells, fish has an ordinary command to set variables: ``set``, which takes a variable name, and then its value.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> set name 'Mister Noodle'
> echo $name
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
Mister Noodle
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
(Notice the quotes: without them, ``Mister`` and ``Noodle`` would have been separate arguments, and ``$name`` would have been made into a list of two elements.)
Unlike other shells, variables are not further split after substitution::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> mkdir $name
> ls
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
Mister Noodle
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Add some links (and remove a stray sentence)
2021-07-17 00:08:55 +08:00
In bash, this would have created two directories "Mister" and "Noodle". In fish, it created only one: the variable had the value "Mister Noodle", so that is the argument that was passed to ``mkdir``, spaces and all.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Rewrite exports section See #5920. [ci skip]
2019-06-07 01:26:54 +08:00
You can erase (or "delete") a variable with ``-e`` or ``--erase``
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> set -e MyVariable
> env | grep MyVariable
docs/tutorial: Rewrite exports section See #5920. [ci skip]
2019-06-07 01:26:54 +08:00
(no output)
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
For more, see :ref:`Variable expansion <expand-variable>`.
docs: Add more about $PATH being imported to the tutorial Fixes #7539.
2021-01-10 05:44:30 +08:00
.. _tut-exports:
docs/tutorial: Rewrite exports section See #5920. [ci skip]
2019-06-07 01:26:54 +08:00
Exports (Shell Variables)
-------------------------
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use monospace for inline code snippets more consistently
2020-10-27 02:19:05 +08:00
Sometimes you need to have a variable available to an external command, often as a setting. For example many programs like ``git`` or ``man`` read the ``$PAGER`` variable to figure out your preferred pager (the program that lets you scroll text). Other variables used like this include ``$BROWSER``, ``$LANG`` (to configure your language) and ``$PATH``. You'll note these are written in ALLCAPS, but that's just a convention.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some more on tutorial and combiners
2022-12-27 21:17:27 +08:00
To give a variable to an external command, it needs to be "exported". This is done with a flag to ``set``, either ``--export`` or just ``-x``.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> set -x MyVariable SomeValue
> env | grep MyVariable
docs/tutorial: Rewrite exports section See #5920. [ci skip]
2019-06-07 01:26:54 +08:00
MyVariable=SomeValue
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Rewrite exports section See #5920. [ci skip]
2019-06-07 01:26:54 +08:00
It can also be unexported with ``--unexport`` or ``-u``.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Add more about $PATH being imported to the tutorial Fixes #7539.
2021-01-10 05:44:30 +08:00
This works the other way around as well! If fish is started by something else, it inherits that parents exported variables. So if your terminal emulator starts fish, and it exports ``$LANG`` set to ``en_US.UTF-8``, fish will receive that setting. And whatever started your terminal emulator also gave *it* some variables that it will then pass on unless it specifically decides not to. This is how fish usually receives the values for things like ``$LANG``, ``$PATH`` and ``$TERM``, without you having to specify them again.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Remove "note that" It's one of my verbal tics, and I don't want it.
2021-05-04 00:39:54 +08:00
Exported variables can be local or global or universal - "exported" is not a :ref:`scope <variables-scope>`! Usually you'd make them global via ``set -gx MyVariable SomeValue``.
docs: Point away from `set -x` This is a common anti-pattern, we should try to get people to do `set -gx`.
2021-02-02 01:12:24 +08:00
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
For more, see :ref:`Exporting variables <variables-export>`.
Use dashes instead of underscores pervasively in tutorial anchors This fixes some broken help completions.
2020-08-01 03:06:40 +08:00
.. _tut-lists:
docs/tutorial: Fix list link [ci skip]
2019-06-07 04:52:14 +08:00
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Lists
-----
docs: Use "fish" without markup in tutorial Work towards #6785. [ci skip]
2020-09-21 02:12:50 +08:00
The ``set`` command above used quotes to ensure that ``Mister Noodle`` was one argument. If it had been two arguments, then ``name`` would have been a list of length 2. In fact, all variables in fish are really lists, that can contain any number of values, or none at all.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Some variables, like ``$PWD``, only have one value. By convention, we talk about that variable's value, but we really mean its first (and only) value.
Other variables, like ``$PATH``, really do have multiple values. During variable expansion, the variable expands to become multiple arguments::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo $PATH
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
/usr/bin /bin /usr/sbin /sbin /usr/local/bin
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
fixup! docs: use monospace for inline code snippets more consistently
2020-11-13 05:10:05 +08:00
Variables whose name ends in "PATH" are automatically split on colons to become lists. They are joined using colons when exported to subcommands. This is for compatibility with other tools, which expect $PATH to use colons. You can also explicitly add this quirk to a variable with ``set --path``, or remove it with ``set --unpath``.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Lists cannot contain other lists: there is no recursion. A variable is a list of strings, full stop.
Get the length of a list with ``count``::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> count $PATH
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
5
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
You can append (or prepend) to a list by setting the list to itself, with some additional arguments. Here we append /usr/local/bin to $PATH::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> set PATH $PATH /usr/local/bin
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
You can access individual elements with square brackets. Indexing starts at 1 from the beginning, and -1 from the end::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo $PATH
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
/usr/bin /bin /usr/sbin /sbin /usr/local/bin
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo $PATH[1]
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
/usr/bin
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo $PATH[-1]
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
/usr/local/bin
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Fix markup for code blocks
2020-10-11 03:22:34 +08:00
You can also access ranges of elements, known as "slices":
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo $PATH[1..2]
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
/usr/bin /bin
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo $PATH[-1..2]
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
/usr/local/bin /sbin /usr/sbin /bin
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
You can iterate over a list (or a slice) with a for loop::
docs: Remove prompt from multiline commands If a code block includes a line starting with ">", we assume it shows an interactive session, all lines starting with ">" are commands and the rest is output. Unfortunately, in something like: ``` > for val in $PATh echo "entry: $val" end entry: /usr/bin ``` this won't highlight the dangling lines. We could also prefix them with `>`, but that require us to parse them in blocks or the `end` would be an error. So, for now, simply don't give these as a prompt but as a script with cheesy comments describing the output.
2022-03-12 02:05:26 +08:00
for val in $PATH
echo "entry: $val"
end
# Will print:
# entry: /usr/bin/
# entry: /bin
# entry: /usr/sbin
# entry: /sbin
# entry: /usr/local/bin
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some on the tutorial Try to clarify and simplify some wording and move the wildcards/redirection section behind variables because they are more important
2023-04-28 23:09:39 +08:00
One particular bit is that you can use lists like :ref:`Brace expansion <expand-brace>`. If you attach another string to a list, it'll combine every element of the list with the string::
> set mydirs /usr/bin /bin
> echo $mydirs/fish # this is just like {/usr/bin,/bin}/fish
/usr/bin/fish /bin/fish
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some on the tutorial Try to clarify and simplify some wording and move the wildcards/redirection section behind variables because they are more important
2023-04-28 23:09:39 +08:00
This also means that, if the list is empty, there will be no argument::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some on the tutorial Try to clarify and simplify some wording and move the wildcards/redirection section behind variables because they are more important
2023-04-28 23:09:39 +08:00
> set empty # no argument
> echo $empty/this_is_gone # prints an empty line
If you quote the list, it will be used as one string and so you'll get one argument even if it is empty.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
For more, see :ref:`Lists <variables-lists>`.
docs: Some on the tutorial Try to clarify and simplify some wording and move the wildcards/redirection section behind variables because they are more important
2023-04-28 23:09:39 +08:00
For more on combining lists with strings (or even other lists), see :ref:`cartesian products <cartesian-product>` and :ref:`Variable expansion <expand-variable>`.
Wildcards
---------
Fish supports the familiar wildcard ``*``. To list all JPEG files::
> ls *.jpg
lena.jpg
meena.jpg
santa maria.jpg
You can include multiple wildcards::
> ls l*.p*
lena.png
lesson.pdf
The recursive wildcard ``**`` searches directories recursively::
> ls /var/**.log
/var/log/system.log
/var/run/sntp.log
docs: use canonical key names in :kbd: tags This seems a bit better because it's what bind uses. To makes sure that something like :kbd:`ctrl-x` looks good in HTML, remove the border from the kbd style. Else both "ctrl" and "x" get small boxes which looks weird.
2024-04-14 02:30:07 +08:00
If that directory traversal is taking a long time, you can :kbd:`ctrl-c` out of it.
docs: Some on the tutorial Try to clarify and simplify some wording and move the wildcards/redirection section behind variables because they are more important
2023-04-28 23:09:39 +08:00
For more, see :ref:`Wildcards <expand-wildcard>`.
Pipes and Redirections
----------------------
You can pipe between commands with the usual vertical bar::
> echo hello world | wc
1 2 12
stdin and stdout can be redirected via the familiar ``<`` and ``>``. stderr is redirected with a ``2>``.
::
> grep fish < /etc/shells > ~/output.txt 2> ~/errors.txt
To redirect stdout and stderr into one file, you can use ``&>``::
> make &> make_output.txt
For more, see :ref:`Input and output redirections <redirects>` and :ref:`Pipes <pipes>`.
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Command Substitutions
---------------------
docs: Some more $() changes
2021-07-17 00:08:36 +08:00
Command substitutions use the output of one command as an argument to another. Unlike other shells, fish does not use backticks `` for command substitutions. Instead, it uses parentheses with or without a dollar::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some more $() changes
2021-07-17 00:08:36 +08:00
> echo In (pwd), running $(uname)
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
In /home/tutorial, running FreeBSD
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
A common idiom is to capture the output of a command in a variable::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> set os (uname)
> echo $os
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
Linux
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some more $() changes
2021-07-17 00:08:36 +08:00
Command substitutions without a dollar are not expanded within quotes, so the version with a dollar is simpler::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some more $() changes
2021-07-17 00:08:36 +08:00
> touch "testing_$(date +%s).txt"
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> ls *.txt
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
testing_1360099791.txt
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Some more on tutorial and combiners
2022-12-27 21:17:27 +08:00
Unlike other shells, fish does not split command substitutions on any whitespace (like spaces or tabs), only newlines. Usually this is a big help because unix commands operate on a line-by-line basis. Sometimes it can be an issue with commands like ``pkg-config`` that print what is meant to be multiple arguments on a single line. To split it on spaces too, use ``string split``.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> printf '%s\n' (pkg-config --libs gio-2.0)
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
-lgio-2.0 -lgobject-2.0 -lglib-2.0
Suggest string split -n for separating on spaces. At least on some versions/systems, pkg-config outputs a trailing space. Since the usually-desired behavior isn't to have a blank argument, recommend using `string split -n` instead of `string split`. Fixes #6836. [ci skip]
2020-03-31 01:17:51 +08:00
> printf '%s\n' (pkg-config --libs gio-2.0 | string split -n " ")
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
-lgio-2.0
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
-lgobject-2.0
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
-lglib-2.0
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Docs for "$(cmd)" and $(cmd)
2021-07-03 05:11:03 +08:00
If you need a command substitutions output as one argument, without any splits, use quoted command substitution::
docs: Some rewording to the tutorial Add a link to fish-for-bash-users, mention string collect, some reformatting
2021-05-28 23:35:29 +08:00
> echo "first line
second line" > myfile
Docs for "$(cmd)" and $(cmd)
2021-07-03 05:11:03 +08:00
> set myfile "$(cat myfile)"
docs: Some rewording to the tutorial Add a link to fish-for-bash-users, mention string collect, some reformatting
2021-05-28 23:35:29 +08:00
> printf '|%s|' $myfile
|first line
second line|
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
For more, see :ref:`Command substitution <expand-command-substitution>`.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Use dashes instead of underscores pervasively in tutorial anchors This fixes some broken help completions.
2020-08-01 03:06:40 +08:00
.. _tut-semicolon:
docs: fix a few links - add missing links for some commands (control flow section) - fix broken links that use the old syntax (#tut_ links) - miscellaneous fixing of backticks/emphasis
2020-07-18 02:22:57 +08:00
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Separating Commands (Semicolon)
-------------------------------
Like other shells, fish allows multiple commands either on separate lines or the same line.
To write them on the same line, use the semicolon (";"). That means the following two examples are equivalent::
echo fish; echo chips
# or
echo fish
echo chips
docs: Some more on tutorial and combiners
2022-12-27 21:17:27 +08:00
This is useful interactively to enter multiple commands. In a script it's easier to read if the commands are on separate lines.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Put exit status with combiners and conditionals It was awkwardly sandwhiched inbetween variables and exports. [ci skip]
2019-06-07 01:17:09 +08:00
Exit Status
-----------
docs: Some more on tutorial and combiners
2022-12-27 21:17:27 +08:00
When a command exits, it returns a status code as a non-negative integer (that's a whole number >= 0).
docs/tutorial: Rewrite exit status section We've kinda forgotten the "tutorial" part of this. [ci skip]
2019-06-07 01:38:19 +08:00
docs: Use "fish" without markup in tutorial Work towards #6785. [ci skip]
2020-09-21 02:12:50 +08:00
Unlike other shells, fish stores the exit status of the last command in ``$status`` instead of ``$?``.
docs/tutorial: Put exit status with combiners and conditionals It was awkwardly sandwhiched inbetween variables and exports. [ci skip]
2019-06-07 01:17:09 +08:00
::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> false
> echo $status
docs/tutorial: Put exit status with combiners and conditionals It was awkwardly sandwhiched inbetween variables and exports. [ci skip]
2019-06-07 01:17:09 +08:00
1
Revert "docs/tutorial: Fix duplicate sentence" This reverts commit 9d1129f14cada98bb213605f4c7e4600eff315b6. Probably a bad rebase, at the time this appeared on master the sentence was already removed.
2020-06-12 00:40:05 +08:00
This indicates how the command fared - 0 usually means success, while the others signify kinds of failure. For instance fish's ``set --query`` returns the number of variables it queried that weren't set - ``set --query PATH`` usually returns 0, ``set --query arglbargl boogagoogoo`` usually returns 2.
docs/tutorial: Rewrite exit status section We've kinda forgotten the "tutorial" part of this. [ci skip]
2019-06-07 01:38:19 +08:00
There is also a ``$pipestatus`` list variable for the exit statuses [#]_ of processes in a pipe.
docs/tutorial: Put exit status with combiners and conditionals It was awkwardly sandwhiched inbetween variables and exports. [ci skip]
2019-06-07 01:17:09 +08:00
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
For more, see :ref:`The status variable <variables-status>`.
docs/tutorial: Rewrite exit status section We've kinda forgotten the "tutorial" part of this. [ci skip]
2019-06-07 01:38:19 +08:00
.. [#] or "stati" if you prefer, or "statūs" if you've time-travelled from ancient Rome or work as a latin teacher
docs/tutorial: Put exit status with combiners and conditionals It was awkwardly sandwhiched inbetween variables and exports. [ci skip]
2019-06-07 01:17:09 +08:00
Correct tut_combiners anchor to tut-combiners dash is preferred in the tutorial. This fixes a broken link from the main help page.
2020-08-01 02:53:26 +08:00
.. _tut-combiners:
docs: fix a few links - add missing links for some commands (control flow section) - fix broken links that use the old syntax (#tut_ links) - miscellaneous fixing of backticks/emphasis
2020-07-18 02:22:57 +08:00
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Combiners (And, Or, Not)
------------------------
docs: Remove &foo; escapes I always hated these. [ci skip]
2019-04-07 05:33:07 +08:00
fish supports the familiar ``&&`` and ``||`` to combine commands, and ``!`` to negate them::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> ./configure && make && sudo make install
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: fix a few links - add missing links for some commands (control flow section) - fix broken links that use the old syntax (#tut_ links) - miscellaneous fixing of backticks/emphasis
2020-07-18 02:22:57 +08:00
Here, ``make`` is only executed if ``./configure`` succeeds (returns 0), and ``sudo make install`` is only executed if both ``./configure`` and ``make`` succeed.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
fish also supports :doc:`and <cmds/and>`, :doc:`or <cmds/or>`, and :doc:`not <cmds/not>`. The first two are job modifiers and have lower precedence. Example usage::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Make the lines in the code examples shorter We should typically avoid scrolling even at max-width. An exception here is the output of `functions` - this prints one very long line, but it's really not important what's in there specifically, it's just to illustrate the kind of output you'd get.
2021-01-26 16:26:17 +08:00
> cp file1 file1_bak && cp file2 file2_bak; and echo "Backup successful"; or echo "Backup failed"
docs: Remove <outp> tags fish_indent_lexer formats lines not starting with a prompt indicator as output, as long as there is a prompt indicator elsewhere. So these tags are useless and wrong. See #5696. [ci skip]
2019-04-30 18:19:04 +08:00
Backup failed
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Use dashes instead of underscores pervasively in tutorial anchors This fixes some broken help completions.
2020-08-01 03:06:40 +08:00
As mentioned in :ref:`the section on the semicolon <tut-semicolon>`, this can also be written in multiple lines, like so::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Make the lines in the code examples shorter We should typically avoid scrolling even at max-width. An exception here is the output of `functions` - this prints one very long line, but it's really not important what's in there specifically, it's just to illustrate the kind of output you'd get.
2021-01-26 16:26:17 +08:00
cp file1 file1_bak && cp file2 file2_bak
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
and echo "Backup successful"
or echo "Backup failed"
docs: More on conditionals directly It's weird to force people to go to the separate pages, at least give some simple examples here and link to the tutorial. [ci skip]
2020-07-24 23:17:39 +08:00
.. _tut-conditionals:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Conditionals (If, Else, Switch)
-------------------------------
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
Use :doc:`if <cmds/if>` and :doc:`else <cmds/else>` to conditionally execute code, based on the exit status of a command.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
::
if grep fish /etc/shells
echo Found fish
else if grep bash /etc/shells
echo Found bash
else
echo Got nothing
end
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
To compare strings or numbers or check file properties (whether a file exists or is writeable and such), use :doc:`test <cmds/test>`, like
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
::
if test "$fish" = "flounder"
echo FLOUNDER
end
# or
if test "$number" -gt 5
echo $number is greater than five
else
echo $number is five or less
end
docs/tutorial: Expand [ci skip]
2019-06-07 02:00:11 +08:00
# or
docs: Make the lines in the code examples shorter We should typically avoid scrolling even at max-width. An exception here is the output of `functions` - this prints one very long line, but it's really not important what's in there specifically, it's just to illustrate the kind of output you'd get.
2021-01-26 16:26:17 +08:00
# This test is true if the path /etc/hosts exists
# - it could be a file or directory or symlink (or possibly something else).
if test -e /etc/hosts
docs/tutorial: Expand [ci skip]
2019-06-07 02:00:11 +08:00
echo We most likely have a hosts file
else
echo We do not have a hosts file
end
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Correct tut_combiners anchor to tut-combiners dash is preferred in the tutorial. This fixes a broken link from the main help page.
2020-08-01 02:53:26 +08:00
:ref:`Combiners <tut-combiners>` can also be used to make more complex conditions, like
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
::
docs: Some more on tutorial and combiners
2022-12-27 21:17:27 +08:00
if command -sq fish; and grep fish /etc/shells
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
echo fish is installed and configured
end
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
For even more complex conditions, use :doc:`begin <cmds/begin>` and :doc:`end <cmds/end>` to group parts of them.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
There is also a :doc:`switch <cmds/switch>` command::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
switch (uname)
case Linux
echo Hi Tux!
case Darwin
echo Hi Hexley!
case FreeBSD NetBSD DragonFly
echo Hi Beastie!
case '*'
echo Hi, stranger!
end
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
As you see, :doc:`case <cmds/case>` does not fall through, and can accept multiple arguments or (quoted) wildcards.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
For more, see :ref:`Conditions <syntax-conditional>`.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Functions
---------
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
A fish function is a list of commands, which may optionally take arguments. Unlike other shells, arguments are not passed in "numbered variables" like ``$1``, but instead in a single list ``$argv``. To create a function, use the :doc:`function <cmds/function>` builtin::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Remove prompt from multiline commands If a code block includes a line starting with ">", we assume it shows an interactive session, all lines starting with ">" are commands and the rest is output. Unfortunately, in something like: ``` > for val in $PATh echo "entry: $val" end entry: /usr/bin ``` this won't highlight the dangling lines. We could also prefix them with `>`, but that require us to parse them in blocks or the `end` would be an error. So, for now, simply don't give these as a prompt but as a script with cheesy comments describing the output.
2022-03-12 02:05:26 +08:00
function say_hello
echo Hello $argv
end
say_hello
# prints: Hello
say_hello everybody!
# prints: Hello everybody!
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Tutorial: Merge the footnotes on aliases and abbreviations together @mqudsi's feedback from #9226
2022-09-25 06:15:33 +08:00
Unlike other shells, fish does not have aliases or special prompt syntax. Functions take their place. [#]_
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
You can list the names of all functions with the :doc:`functions <cmds/functions>` builtin (note the plural!). fish starts out with a number of functions::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> functions
Remove delete-or-exit function, which has a C++ implementation
2021-12-09 00:28:40 +08:00
N_, abbr, alias, bg, cd, cdh, contains_seq, dirh, dirs, disown, down-or-search, edit_command_buffer, export, fg, fish_add_path, fish_breakpoint_prompt, fish_clipboard_copy, fish_clipboard_paste, fish_config, fish_default_key_bindings, fish_default_mode_prompt, fish_git_prompt, fish_hg_prompt, fish_hybrid_key_bindings, fish_indent, fish_is_root_user, fish_job_summary, fish_key_reader, fish_md5, fish_mode_prompt, fish_npm_helper, fish_opt, fish_print_git_action, fish_print_hg_root, fish_prompt, fish_sigtrap_handler, fish_svn_prompt, fish_title, fish_update_completions, fish_vcs_prompt, fish_vi_cursor, fish_vi_key_bindings, funced, funcsave, grep, help, history, hostname, isatty, kill, la, ll, ls, man, nextd, open, popd, prevd, prompt_hostname, prompt_pwd, psub, pushd, realpath, seq, setenv, suspend, trap, type, umask, up-or-search, vared, wait
Implement nextd-or-forward-word and prevd-or-backward-word in C++
2021-12-09 00:16:26 +08:00
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
You can see the source for any function by passing its name to ``functions``::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> functions ls
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
function ls --description 'List contents of directory'
command ls -G $argv
end
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
For more, see :ref:`Functions <syntax-function>`.
Tutorial: Merge the footnotes on aliases and abbreviations together @mqudsi's feedback from #9226
2022-09-25 06:15:33 +08:00
.. [#] There is a function called :doc:`alias <cmds/alias>`, but it's just a shortcut to make functions. fish also provides :ref:`abbreviations <abbreviations>`, through the :ref:`abbr <cmd-abbr>` command.
Add reference to abbreviations
2022-09-21 05:47:57 +08:00
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Loops
-----
While loops::
docs: Remove prompt from multiline commands If a code block includes a line starting with ">", we assume it shows an interactive session, all lines starting with ">" are commands and the rest is output. Unfortunately, in something like: ``` > for val in $PATh echo "entry: $val" end entry: /usr/bin ``` this won't highlight the dangling lines. We could also prefix them with `>`, but that require us to parse them in blocks or the `end` would be an error. So, for now, simply don't give these as a prompt but as a script with cheesy comments describing the output.
2022-03-12 02:05:26 +08:00
while true
docs: Remove some more html See #5696. [ci skip]
2019-04-30 18:53:15 +08:00
echo "Loop forever"
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
end
docs: Remove prompt from multiline commands If a code block includes a line starting with ">", we assume it shows an interactive session, all lines starting with ">" are commands and the rest is output. Unfortunately, in something like: ``` > for val in $PATh echo "entry: $val" end entry: /usr/bin ``` this won't highlight the dangling lines. We could also prefix them with `>`, but that require us to parse them in blocks or the `end` would be an error. So, for now, simply don't give these as a prompt but as a script with cheesy comments describing the output.
2022-03-12 02:05:26 +08:00
# Prints:
# Loop forever
# Loop forever
# Loop forever
# yes, this really will loop forever. Unless you abort it with ctrl-c.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
For loops can be used to iterate over a list. For example, a list of files::
docs: Remove prompt from multiline commands If a code block includes a line starting with ">", we assume it shows an interactive session, all lines starting with ">" are commands and the rest is output. Unfortunately, in something like: ``` > for val in $PATh echo "entry: $val" end entry: /usr/bin ``` this won't highlight the dangling lines. We could also prefix them with `>`, but that require us to parse them in blocks or the `end` would be an error. So, for now, simply don't give these as a prompt but as a script with cheesy comments describing the output.
2022-03-12 02:05:26 +08:00
for file in *.txt
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
cp $file $file.bak
end
Iterating over a list of numbers can be done with ``seq``::
docs: Remove prompt from multiline commands If a code block includes a line starting with ">", we assume it shows an interactive session, all lines starting with ">" are commands and the rest is output. Unfortunately, in something like: ``` > for val in $PATh echo "entry: $val" end entry: /usr/bin ``` this won't highlight the dangling lines. We could also prefix them with `>`, but that require us to parse them in blocks or the `end` would be an error. So, for now, simply don't give these as a prompt but as a script with cheesy comments describing the output.
2022-03-12 02:05:26 +08:00
for x in (seq 5)
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
touch file_$x.txt
end
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
For more, see :ref:`Loops and blocks <syntax-loops-and-blocks>`.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Prompt
------
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
.. role:: purple
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
Unlike other shells, there is no prompt variable like ``PS1``. To display your prompt, fish executes the :doc:`fish_prompt <cmds/fish_prompt>` function and uses its output as the prompt. And if it exists, fish also executes the :doc:`fish_right_prompt <cmds/fish_right_prompt>` function and uses its output as the right prompt.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
You can define your own prompt from the command line:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
.. parsed-literal::
docs: Fix background color for interactive examples For the few weird code blocks where default highlighting does not work, we must add the 'highlight' class manually to get matching backgrounds. This reuses the background color defined in pygments.css.
2020-09-02 11:48:59 +08:00
:class: highlight
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
> function fish_prompt; echo "New Prompt % "; end
New Prompt % _
docs/tutorial: Fix prompt display This displays a colored prompt, which we emulate by adding explicit roles that are translated to css classes. For other things, like "eror" this might not be enough because those often need the rest of the line to still be styled, and I've not found a way to add some explicit styling to a code block. See #5696. [ci skip]
2019-05-25 17:47:44 +08:00
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
Then, if you are happy with it, you can save it to disk by typing ``funcsave fish_prompt``. This saves the prompt in ``~/.config/fish/functions/fish_prompt.fish``. (Or, if you want, you can create that file manually from the start.)
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
Multiple lines are OK. Colors can be set via :doc:`set_color <cmds/set_color>`, passing it named ANSI colors, or hex RGB values::
docs: use parsed-literal to highlight interactive examples There are a few code blocks where the default highlighting does not work and the documentation looks bad as a result. Usually this happens when we are demonstrating an important interactive feature, such as autosuggestions, syntax highlighting, or tab completion. The pygments highlighter was not designed for code samples like these. But it is important to show the behavior clearly in the docs. I am attempting to make these weird examples look as much like the "normal" code blocks as possible. https://docutils.sourceforge.io/docs/ref/rst/directives.html#parsed-literal
2020-08-03 00:01:34 +08:00
function fish_prompt
set_color purple
date "+%m/%d/%y"
set_color F00
echo (pwd) '>' (set_color normal)
end
This prompt would look like:
.. parsed-literal::
docs: Fix background color for interactive examples For the few weird code blocks where default highlighting does not work, we must add the 'highlight' class manually to get matching backgrounds. This reuses the background color defined in pygments.css.
2020-09-02 11:48:59 +08:00
:class: highlight
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Fix background color for interactive examples For the few weird code blocks where default highlighting does not work, we must add the 'highlight' class manually to get matching backgrounds. This reuses the background color defined in pygments.css.
2020-09-02 11:48:59 +08:00
:purple:`02/06/13`
:red:`/home/tutorial >` _
docs/tutorial: Fix prompt display This displays a colored prompt, which we emulate by adding explicit roles that are translated to css classes. For other things, like "eror" this might not be enough because those often need the rest of the line to still be styled, and I've not found a way to add some explicit styling to a code block. See #5696. [ci skip]
2019-05-25 17:47:44 +08:00
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Link relevant language sections from the tutorial This allows us to keep the tutorial more focussed and leave the more in-depth information in the "language" part of the documentation.
2021-05-04 00:15:24 +08:00
You can choose among some sample prompts by running ``fish_config`` for a web UI or ``fish_config prompt`` for a simpler version inside your terminal.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
$PATH
-----
docs: Use "fish" without markup in tutorial Work towards #6785. [ci skip]
2020-09-21 02:12:50 +08:00
``$PATH`` is an environment variable containing the directories that fish searches for commands. Unlike other shells, $PATH is a :ref:`list <tut-lists>`, not a colon-delimited string.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Add more about $PATH being imported to the tutorial Fixes #7539.
2021-01-10 05:44:30 +08:00
Fish takes care to set ``$PATH`` to a default, but typically it is just inherited from fish's parent process and is set to a value that makes sense for the system - see :ref:`Exports <tut-exports>`.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
To prepend /usr/local/bin and /usr/sbin to ``$PATH``, you can write::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> set PATH /usr/local/bin /usr/sbin $PATH
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
To remove /usr/local/bin from ``$PATH``, you can write::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> set PATH (string match -v /usr/local/bin $PATH)
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Fix markup for code blocks
2020-10-11 03:22:34 +08:00
For compatibility with other shells and external commands, $PATH is a :ref:`path variable<variables-path>`, and so will be joined with colons (not spaces) when you quote it::
docs/tutorial: Expand [ci skip]
2019-06-07 02:00:11 +08:00
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo "$PATH"
docs/tutorial: Expand [ci skip]
2019-06-07 02:00:11 +08:00
/usr/local/sbin:/usr/local/bin:/usr/bin
and it will be exported like that, and when fish starts it splits the $PATH it receives into a list on colon.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Fix example link
2019-03-31 17:50:28 +08:00
You can do so directly in ``config.fish``, like you might do in other shells with ``.profile``. See :ref:`this example <path_example>`.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
A faster way is to use the :doc:`fish_add_path <cmds/fish_add_path>` function, which adds given directories to the path if they aren't already included. It does this by modifying the ``$fish_user_paths`` :ref:`universal variable <tut-universal>`, which is automatically prepended to ``$PATH``. For example, to permanently add ``/usr/local/bin`` to your ``$PATH``, you could write::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Recommend fish_add_path over $fish_user_paths
2020-05-21 23:38:46 +08:00
> fish_add_path /usr/local/bin
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Recommend fish_add_path over $fish_user_paths
2020-05-21 23:38:46 +08:00
The advantage is that you don't have to go mucking around in files: just run this once at the command line, and it will affect the current session and all future instances too. You can also add this line to :ref:`config.fish <tut-config>`, as it only adds the component if necessary.
Or you can modify $fish_user_paths yourself, but you should be careful *not* to append to it unconditionally in config.fish, or it will grow longer and longer.
.. _tut-config:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Startup (Where's .bashrc?)
--------------------------
docs: Use "fish" without markup in tutorial Work towards #6785. [ci skip]
2020-09-21 02:12:50 +08:00
Fish starts by executing commands in ``~/.config/fish/config.fish``. You can create it if it does not exist.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
It is possible to directly create functions and variables in ``config.fish`` file, using the commands shown above. For example:
docs: Fix example link
2019-03-31 17:50:28 +08:00
.. _path_example:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> cat ~/.config/fish/config.fish
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
set -x PATH $PATH /sbin/
function ll
ls -lh $argv
end
However, it is more common and efficient to use autoloading functions and universal variables.
docs: Don't speak of "initialization files" The file is called "config.fish", not "init.fish". We'll call it "configuration" now. "Initialization" might be slightly more precise, but in an irritating way. Also some wording improvements to the section. In particular we now mention config.fish *early*, before the whole shebang.
2021-05-28 23:21:49 +08:00
If you want to organize your configuration, fish also reads commands in .fish files in ``~/.config/fish/conf.d/``. See :ref:`Configuration Files <configuration>` for the details.
docs/tutorial: Expand [ci skip]
2019-06-07 02:00:11 +08:00
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Autoloading Functions
---------------------
docs: Use "fish" without markup in tutorial Work towards #6785. [ci skip]
2020-09-21 02:12:50 +08:00
When fish encounters a command, it attempts to autoload a function for that command, by looking for a file with the name of that command in ``~/.config/fish/functions/``.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
For example, if you wanted to have a function ``ll``, you would add a text file ``ll.fish`` to ``~/.config/fish/functions``::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> cat ~/.config/fish/functions/ll.fish
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
function ll
ls -lh $argv
end
This is the preferred way to define your prompt as well::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> cat ~/.config/fish/functions/fish_prompt.fish
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
function fish_prompt
echo (pwd) "> "
end
docs: Use :doc: role when linking to commands This makes it so we link to the very top of the document instead of a special anchor we manually include. So clicking e.g. :doc:`string <cmds/string>` will link you to cmds/string.html instead of cmds/string.html#cmd-string. I would love to have a way to say "this document from the root of the document path", but that doesn't appear to work, I tried `/cmds/string`. So we'll just have to use cmds/string in normal documents and plain `string` from other commands.
2022-09-24 01:57:49 +08:00
See the documentation for :doc:`funced <cmds/funced>` and :doc:`funcsave <cmds/funcsave>` for ways to create these files automatically, and :ref:`$fish_function_path <syntax-function-autoloading>` to control their location.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs: Fix universal variables link [ci skip]
2019-09-30 22:02:06 +08:00
.. _tut-universal:
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Universal Variables
-------------------
docs: Use "fish" without markup in tutorial Work towards #6785. [ci skip]
2020-09-21 02:12:50 +08:00
A universal variable is a variable whose value is shared across all instances of fish, now and in the future – even after a reboot. You can make a variable universal with ``set -U``::
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> set -U EDITOR vim
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Now in another shell::
docs/tutorial: Fix formatting This removes the explicit html coloring that was used in the tutorial. Where necessary we just add pseudo-html like `<red>...</red>` to explain it to the users. I don't know how to reintroduce coloring here, but it's not super important as the user can always just check for themselves. See #5696 [ci skip]
2019-11-05 03:08:45 +08:00
> echo $EDITOR
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
vim
docs: Fix two links
2024-06-22 20:58:07 +08:00
You only need to set universal variables once interactively. There is no need to add them to your :ref:`config files <configuration>`. For more details, see :ref:`Universal Variables <variables-universal>`.
Add tutorial to sphinx docs build
2019-02-25 09:13:01 +08:00
Ready for more?
---------------
Disavow IRC channel I don't know of any fish dev on there, so it's not a good channel to reach us and I have no idea how good it is, so it's best to just ditch it.
2019-11-16 23:03:14 +08:00
If you want to learn more about fish, there is :ref:`lots of detailed documentation <intro>`, the `official gitter channel <https://gitter.im/fish-shell/fish-shell>`__, an `official mailing list <https://lists.sourceforge.net/lists/listinfo/fish-users>`__, and the `github page <https://github.com/fish-shell/fish-shell/>`__.
Reference in New Issue Copy Permalink