fish-shell/doc_src/cmds/set.rst

159 lines
8.3 KiB
ReStructuredText
Raw Normal View History

.. _cmd-set:
2020-03-31 23:37:38 +08:00
set - display and change shell variables
========================================
Synopsis
--------
::
set [SCOPE_OPTIONS]
set [OPTIONS] VARIABLE_NAME VALUES...
set [OPTIONS] VARIABLE_NAME[INDICES]... VALUES...
set ( -q | --query ) [SCOPE_OPTIONS] VARIABLE_NAMES...
set ( -e | --erase ) [SCOPE_OPTIONS] VARIABLE_NAME...
set ( -e | --erase ) [SCOPE_OPTIONS] VARIABLE_NAME[INDICES]...
set ( -S | --show ) [VARIABLE_NAME]...
Description
-----------
``set`` manipulates :ref:`shell variables <variables>`.
If both a variable name and values are provided, ``set`` assigns the values to the variable of that name. Because all variables in fish are :ref:`lists <variables-lists>`, multiple values are allowed.
If only a variable name has been given, ``set`` sets the variable to the empty list.
If ``set`` is called with no arguments, it prints the names and values of all shell variables in sorted order. Passing :ref:`scope <variables-scope>` or :ref:`export <variables-export>` flags allows filtering this to only matching variables, so ``set --local`` would only show local variables.
With ``--erase`` and optionally a scope flag ``set`` will erase the matching variable (or the variable of that name in the smallest possible scope).
With ``--show``, ``set`` will describe the given variable names, explaining how they have been defined - in which scope with which values and options.
The following options control variable scope:
Add `set --function` (#8145) * Add `set --function` This makes the function's scope available, even inside of blocks. Outside of blocks it's the toplevel local scope. This removes the need to declare variables locally before use, and will probably end up being the main way variables get set. E.g.: ```fish set -l thing if condition set thing one else set thing two end ``` could be written as ```fish if condition set -f thing one else set -f thing two end ``` Note: Many scripts shipped with fish use workarounds like `and`/`or` instead of `if`, so it isn't easy to find good examples. Also, if there isn't an else-branch in that above, just with ```fish if condition set -f thing one end ``` that means something different from setting it before! Now, if `condition` isn't true, it would use a global (or universal) variable of te same name! Some more interesting parts: Because it *is* a local scope, setting a variable `-f` and `-l` in the toplevel of a function ends up the same: ```fish function foo2 set -l foo bar set -f foo baz # modifies the *same* variable! end ``` but setting it locally inside a block creates a new local variable that shadows the function-scoped variable: ```fish function foo3 set -f foo bar begin set -l foo banana # $foo is banana end # $foo is bar again end ``` This is how local variables already work. "Local" is actually "block-scoped". Also `set --show` will only show the closest local scope, so it won't show a shadowed function-level variable. Again, this is how local variables already work, and could be done as a separate change. As a fun tidbit, functions with --no-scope-shadowing can now use this to set variables in the calling function. That's probably okay given that it's already an escape hatch (but to be clear: if it turns out to problematic I reserve the right to remove it). Fixes #565
2021-08-02 02:08:12 +08:00
- ``-f`` or ``--function`` scopes the variable to the currently executing function. It is erased when the function ends.
Add `set --function` (#8145) * Add `set --function` This makes the function's scope available, even inside of blocks. Outside of blocks it's the toplevel local scope. This removes the need to declare variables locally before use, and will probably end up being the main way variables get set. E.g.: ```fish set -l thing if condition set thing one else set thing two end ``` could be written as ```fish if condition set -f thing one else set -f thing two end ``` Note: Many scripts shipped with fish use workarounds like `and`/`or` instead of `if`, so it isn't easy to find good examples. Also, if there isn't an else-branch in that above, just with ```fish if condition set -f thing one end ``` that means something different from setting it before! Now, if `condition` isn't true, it would use a global (or universal) variable of te same name! Some more interesting parts: Because it *is* a local scope, setting a variable `-f` and `-l` in the toplevel of a function ends up the same: ```fish function foo2 set -l foo bar set -f foo baz # modifies the *same* variable! end ``` but setting it locally inside a block creates a new local variable that shadows the function-scoped variable: ```fish function foo3 set -f foo bar begin set -l foo banana # $foo is banana end # $foo is bar again end ``` This is how local variables already work. "Local" is actually "block-scoped". Also `set --show` will only show the closest local scope, so it won't show a shadowed function-level variable. Again, this is how local variables already work, and could be done as a separate change. As a fun tidbit, functions with --no-scope-shadowing can now use this to set variables in the calling function. That's probably okay given that it's already an escape hatch (but to be clear: if it turns out to problematic I reserve the right to remove it). Fixes #565
2021-08-02 02:08:12 +08:00
- ``-l`` or ``--local`` scopes the variable to the currently executing block. It is erased when the block ends. Outside of a block, this is the same as ``--function``.
- ``-g`` or ``--global`` causes the specified shell variable to be given a global scope. Global variables don't disappear and are available to all functions running in the same shell. They can even be modified.
- ``-U`` or ``--universal`` causes the specified shell variable to be given a universal scope. If this option is supplied, the variable will be shared between all the current user's fish instances on the current computer, and will be preserved across restarts of the shell.
These options control additional variable options:
- ``-x`` or ``--export`` causes the specified shell variable to be exported to child processes (making it an "environment variable")
- ``-u`` or ``--unexport`` causes the specified shell variable to NOT be exported to child processes
- ``--path`` causes the specified variable to be treated as a path variable, meaning it will automatically be split on colons, and joined using colons when quoted (``echo "$PATH"``) or exported.
- ``--unpath`` causes the specified variable to not be treated as a path variable. Variables with a name ending in "PATH" are automatically path variables, so this can be used to treat such a variable normally.
The following other options are available:
- ``-a`` or ``--append`` causes the values to be appended to the current set of values for the variable. This can be used with ``--prepend`` to both append and prepend at the same time. This cannot be used when assigning to a variable slice.
- ``-p`` or ``--prepend`` causes the values to be prepended to the current set of values for the variable. This can be used with ``--append`` to both append and prepend at the same time. This cannot be used when assigning to a variable slice.
- ``-e`` or ``--erase`` causes the specified shell variables to be erased
- ``-q`` or ``--query`` test if the specified variable names are defined. Does not output anything, but the builtins exit status is the number of variables specified that were not defined, up to a maximum of 255. If no variable was given, it also returns 255.
- ``-n`` or ``--names``: List only the names of all defined variables, not their value. The names are guaranteed to be sorted.
- ``-S`` or ``--show`` shows information about the given variables. If no variable names are given then all variables are shown in sorted order. It shows the scopes the given variables are set in, along with the values in each and whether or not it is exported. No other flags can be used with this option.
- ``-L`` or ``--long`` do not abbreviate long values when printing set variables
If a variable is set to more than one value, the variable will be a list with the specified elements. If a variable is set to zero elements, it will become a list with zero elements.
If the variable name is one or more list elements, such as ``PATH[1 3 7]``, only those list elements specified will be changed. If you specify a negative index when expanding or assigning to a list variable, the index will be calculated from the end of the list. For example, the index -1 means the last index of a list.
The scoping rules when creating or updating a variable are:
- Variables may be explicitly set to universal, global or local. Variables with the same name in different scopes will not be changed.
- If a variable is not explicitly set to be either universal, global or local, but has been previously defined, the previous variable scope is used.
- If a variable is not explicitly set to be either universal, global or local and has never before been defined, the variable will be local to the currently executing function. Note that this is different from using the ``-l`` or ``--local`` flag. If one of those flags is used, the variable will be local to the most inner currently executing block, while without these the variable will be local to the function. If no function is executing, the variable will be global.
The exporting rules when creating or updating a variable are identical to the scoping rules for variables:
- Variables may be explicitly set to either exported or not exported. When an exported variable goes out of scope, it is unexported.
- If a variable is not explicitly set to be exported or not exported, but has been previously defined, the previous exporting rule for the variable is kept.
- If a variable is not explicitly set to be either exported or unexported and has never before been defined, the variable will not be exported.
In query mode, the scope to be examined can be specified.
In erase mode, if variable indices are specified, only the specified slices of the list variable will be erased.
``set`` requires all options to come before any other arguments. For example, ``set flags -l`` will have the effect of setting the value of the variable ``flags`` to '-l', not making the variable local.
Exit status
-----------
In assignment mode, ``set`` does not modify the exit status, but passes along whatever $status was set, including by command substitutions. This allows capturing the output and exit status of a subcommand, like in ``if set output (command)``.
In query mode, the exit status is the number of variables that were not found.
In erase mode, ``set`` exits with a zero exit status in case of success, with a non-zero exit status if the commandline was invalid, if any of the variables did not exist or was a :ref:`special read-only variable <variables-special>`.
Examples
--------
2018-12-19 11:14:04 +08:00
::
# Prints all global, exported variables.
set -xg
2018-12-19 11:14:04 +08:00
# Sets the value of the variable $foo to be 'hi'.
set foo hi
2018-12-19 11:14:04 +08:00
# Appends the value "there" to the variable $foo.
set -a foo there
2018-12-19 11:14:04 +08:00
# Does the same thing as the previous two commands the way it would be done pre-fish 3.0.
set foo hi
set foo $foo there
2018-12-19 11:14:04 +08:00
# Removes the variable $smurf
set -e smurf
# Changes the fourth element of the $PATH list to ~/bin
2018-12-19 11:14:04 +08:00
set PATH[4] ~/bin
# Outputs the path to Python if ``type -p`` returns true.
2018-12-19 11:14:04 +08:00
if set python_path (type -p python)
echo "Python is at $python_path"
end
# Setting a variable doesn't modify $status!
false
set foo bar
echo $status # prints 1, because of the "false" above.
true
set foo banana (false)
echo $status # prints 1, because of the "(false)" above.
2021-02-02 15:35:38 +08:00
# Like other shells, pass a variable to just one command:
# Run fish with a temporary home directory.
HOME=(mktemp -d) fish
# Which is essentially the same as:
begin; set -lx HOME (mktemp -d); fish; end
Notes
-----
Fish versions prior to 3.0 supported the syntax ``set PATH[1] PATH[4] /bin /sbin``, which worked like
``set PATH[1 4] /bin /sbin``. This syntax was not widely used, and was ambiguous and inconsistent.