mirror of
https://github.com/xonsh/xonsh.git
synced 2025-03-04 08:24:40 +01:00
parent
ae6b34ba2f
commit
e1a93cef19
10 changed files with 112 additions and 89 deletions
|
@ -43,7 +43,7 @@ to avoid excessive merge conflicts, please follow the following procedure:
|
|||
2. Copy the ``TEMPLATE.rst`` file to another file in the ``news/`` directory.
|
||||
We suggest using the branchname::
|
||||
|
||||
$ cp TEMPLATE.rst branch.rst
|
||||
@ cp TEMPLATE.rst branch.rst
|
||||
|
||||
3. Add your entries as a bullet pointed lists in your ``branch.rst`` file in
|
||||
the appropriate category. It is OK to leave the ``None`` entries for later
|
||||
|
@ -108,20 +108,20 @@ as misspelled variable names, using `flake8 <https://flake8.pycqa.org/>`_. If yo
|
|||
need to run "conda install flake8" once. You can easily run flake8 on
|
||||
the edited files in your uncommitted git change::
|
||||
|
||||
$ git status -s | awk '/\.py$$/ { print $2 }' | xargs flake8
|
||||
@ git status -s | awk '/\.py$$/ { print $2 }' | xargs flake8
|
||||
|
||||
If you want to lint the entire code base run::
|
||||
|
||||
$ flake8
|
||||
@ flake8
|
||||
|
||||
We also use `black <https://github.com/psf/black>`_ for formatting the code base (which includes running in
|
||||
our tests)::
|
||||
|
||||
$ black --check xonsh/ xontrib/
|
||||
@ black --check xonsh/ xontrib/
|
||||
|
||||
To add this as a git pre-commit hook::
|
||||
|
||||
$ pre-commit install
|
||||
@ pre-commit install
|
||||
|
||||
*******
|
||||
Imports
|
||||
|
@ -142,7 +142,7 @@ If you want to run your "work in progress version" without installing
|
|||
and in a fresh environment you can use Docker. If Docker is installed
|
||||
you just have to run this::
|
||||
|
||||
$ python xonsh-in-docker.py
|
||||
@ python xonsh-in-docker.py
|
||||
|
||||
This will build and run the current state of the repository in an isolated
|
||||
container (it may take a while the first time you run it). There are two
|
||||
|
@ -153,7 +153,7 @@ additional arguments you can pass this script.
|
|||
|
||||
Example::
|
||||
|
||||
$ python docker.py 3.4 0.57
|
||||
@ python docker.py 3.4 0.57
|
||||
|
||||
Ensure your cwd is the root directory of the project (i.e., the one containing the
|
||||
.git directory).
|
||||
|
@ -164,7 +164,7 @@ Dependencies
|
|||
|
||||
Prep your environment for running the tests::
|
||||
|
||||
$ pip install -e '.[dev]'
|
||||
@ pip install -e '.[dev]'
|
||||
|
||||
|
||||
-------------------------
|
||||
|
@ -173,7 +173,7 @@ Running the Tests - Basic
|
|||
|
||||
Run all the tests using pytest::
|
||||
|
||||
$ pytest -q
|
||||
@ pytest -q
|
||||
|
||||
Use "-q" to keep pytest from outputting a bunch of info for every test.
|
||||
|
||||
|
@ -183,16 +183,16 @@ Running the Tests - Advanced
|
|||
|
||||
To perform all unit tests::
|
||||
|
||||
$ pytest
|
||||
@ pytest
|
||||
|
||||
If you want to run specific tests you can specify the test names to
|
||||
execute. For example to run test_aliases::
|
||||
|
||||
$ pytest test_aliases.py
|
||||
@ pytest test_aliases.py
|
||||
|
||||
Note that you can pass multiple test names in the above examples::
|
||||
|
||||
$ pytest test_aliases.py test_environ.py
|
||||
@ pytest test_aliases.py test_environ.py
|
||||
|
||||
----------------------------
|
||||
Writing the Tests - Advanced
|
||||
|
@ -210,7 +210,7 @@ has to be prefixed with `test_`::
|
|||
The conftest.py in tests directory defines fixtures for mocking various
|
||||
parts of xonsh for more test isolation. For a list of the various fixtures::
|
||||
|
||||
$ pytest --fixtures
|
||||
@ pytest --fixtures
|
||||
|
||||
when writing tests it's best to use pytest features i.e. parametrization::
|
||||
|
||||
|
@ -260,7 +260,7 @@ and then you may run the following command from the ``docs`` dir:
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
~/xonsh/docs $ make html
|
||||
~/xonsh/docs @ make html
|
||||
|
||||
For each new
|
||||
module, you will have to supply the appropriate hooks. This should be done the
|
||||
|
@ -293,7 +293,7 @@ Note that xonsh itself needs to be installed too.
|
|||
If you have cloned the git repository, you can install all of the doc-related
|
||||
dependencies by running::
|
||||
|
||||
$ pip install -e ".[doc]"
|
||||
@ pip install -e ".[doc]"
|
||||
|
||||
|
||||
-----------------------------------
|
||||
|
@ -303,18 +303,18 @@ The xonsh website source files are located in the ``docs`` directory.
|
|||
A developer first makes necessary changes, then rebuilds the website locally
|
||||
by executing the command::
|
||||
|
||||
$ make html
|
||||
@ make html
|
||||
|
||||
This will generate html files for the website in the ``_build/html/`` folder.
|
||||
|
||||
There is also a helper utility in the ``docs/`` folder that will watch for changes and automatically rebuild the documentation. You can use this instead of running ``make html`` manually::
|
||||
|
||||
$ python docs/serve_docs.py
|
||||
@ python docs/serve_docs.py
|
||||
|
||||
The developer may view the local changes by opening these files with their
|
||||
favorite browser, e.g.::
|
||||
|
||||
$ firefox _build/html/index.html
|
||||
@ firefox _build/html/index.html
|
||||
|
||||
Once the developer is satisfied with the changes, the changes should be
|
||||
committed and pull-requested per usual. The docs are built and deployed using
|
||||
|
@ -337,9 +337,9 @@ Maintenance Tasks
|
|||
You can cleanup your local repository of transient files such as \*.pyc files
|
||||
created by unit testing by running::
|
||||
|
||||
$ rm -f xonsh/parser_table.py xonsh/completion_parser_table.py
|
||||
$ rm -f xonsh/*.pyc tests/*.pyc
|
||||
$ rm -fr build
|
||||
@ rm -f xonsh/parser_table.py xonsh/completion_parser_table.py
|
||||
@ rm -f xonsh/*.pyc tests/*.pyc
|
||||
@ rm -fr build
|
||||
|
||||
----------------------
|
||||
Performing the Release
|
||||
|
@ -347,12 +347,12 @@ Performing the Release
|
|||
This is done through the `rever <https://github.com/regro/rever>`_. To get a list of the
|
||||
valid options use::
|
||||
|
||||
$ pip install re-ver
|
||||
@ pip install re-ver
|
||||
|
||||
You can perform a full release::
|
||||
|
||||
$ rever check
|
||||
$ rever <version-number>
|
||||
@ rever check
|
||||
@ rever <version-number>
|
||||
|
||||
|
||||
----------------------
|
||||
|
|
20
docs/_templates/index.html
vendored
20
docs/_templates/index.html
vendored
|
@ -151,11 +151,11 @@
|
|||
<div class="text-center">
|
||||
|
||||
<pre class="code">
|
||||
<span unselectable-text="$ "></span><b>cd</b> /home
|
||||
<span unselectable-text="@ "></span><b>cd</b> /home
|
||||
|
||||
<span unselectable-text="$ "></span><b>cat</b> /etc/passwd | <b>grep</b> root
|
||||
<span unselectable-text="@ "></span><b>cat</b> /etc/passwd | <b>grep</b> root
|
||||
|
||||
<span unselectable-text="$ "></span><b>ls</b> -la</pre>
|
||||
<span unselectable-text="@ "></span><b>ls</b> -la</pre>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
@ -177,9 +177,9 @@
|
|||
<div class="text-center">
|
||||
|
||||
<pre class="code">
|
||||
<span unselectable-text="$ "></span>2 + 2
|
||||
<span unselectable-text="@ "></span>2 + 2
|
||||
|
||||
<span unselectable-text="$ "></span><b>import</b> json
|
||||
<span unselectable-text="@ "></span><b>import</b> json
|
||||
<span unselectable-text=" "></span>j = json.loads(<span style="color: lightblue;">'{"Hello": "world!", "Answer": 42}'</span>)
|
||||
<span unselectable-text=" "></span><b>print</b>(j[<span style="color: lightblue;">'Answer'</span>])</pre>
|
||||
|
||||
|
@ -204,9 +204,9 @@
|
|||
<div class="text-center">
|
||||
|
||||
<pre class="code">
|
||||
<span unselectable-text="$ "></span><b>len</b>(<span style="color: lightgreen">$(curl -L https://xon.sh)</span>)
|
||||
<span unselectable-text="@ "></span><b>len</b>(<span style="color: lightgreen">$(curl -L https://xon.sh)</span>)
|
||||
|
||||
<span unselectable-text="$ "></span><b>for</b> filename <b>in</b> <span style="color: yellow">`.*`</span>:
|
||||
<span unselectable-text="@ "></span><b>for</b> filename <b>in</b> <span style="color: yellow">`.*`</span>:
|
||||
<span unselectable-text=" "></span> <b>print</b>(filename)
|
||||
<span unselectable-text=" "></span> <b>du</b> -sh <span style="color: lightsalmon">@(filename)</span></pre>
|
||||
|
||||
|
@ -232,11 +232,11 @@
|
|||
<div class="text-center">
|
||||
|
||||
<pre class="code">
|
||||
<span unselectable-text="$ "></span>var = <span style="color: lightblue;">'he'</span> + <span style="color: lightblue;">'llo'</span>
|
||||
<span unselectable-text="@ "></span>var = <span style="color: lightblue;">'he'</span> + <span style="color: lightblue;">'llo'</span>
|
||||
|
||||
<span unselectable-text="$ "></span><b>echo</b> <span style="color: lightsalmon">@(var)</span> > /tmp/<span style="color: lightsalmon">@(var)</span>
|
||||
<span unselectable-text="@ "></span><b>echo</b> <span style="color: lightsalmon">@(var)</span> > /tmp/<span style="color: lightsalmon">@(var)</span>
|
||||
|
||||
<span unselectable-text="$ "></span><b>echo</b> <span style="color: lightsalmon">@(i for i in range(42))</span></pre>
|
||||
<span unselectable-text="@ "></span><b>echo</b> <span style="color: lightsalmon">@(i for i in range(42))</span></pre>
|
||||
|
||||
</div>
|
||||
</div>
|
||||
|
|
|
@ -15,7 +15,7 @@ command:
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ xpip install --upgrade xonsh
|
||||
@ xpip install --upgrade xonsh
|
||||
|
||||
``xpip`` (note the "x" at the beginning of ``xpip``) is a predefined alias pointing to the ``pip`` command associated with the Python executable running this xonsh.
|
||||
|
||||
|
@ -39,19 +39,19 @@ You can view the available styles by typing
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ xonfig styles
|
||||
@ xonfig styles
|
||||
|
||||
For a quick peek at the theme's colors you can do
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ xonfig colors <theme name>
|
||||
@ xonfig colors <theme name>
|
||||
|
||||
To set a new theme, do
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
$ $XONSH_COLOR_STYLE='<theme name>'
|
||||
@ $XONSH_COLOR_STYLE='<theme name>'
|
||||
|
||||
Registering custom styles
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
@ -85,8 +85,8 @@ first element of your ``sys.path``
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ import sys
|
||||
$ sys.path.insert(0, '')
|
||||
@ import sys
|
||||
@ sys.path.insert(0, '')
|
||||
|
||||
.. _default_shell:
|
||||
|
||||
|
@ -192,7 +192,7 @@ If you are unable to use utf-8 (ie. non-ascii) characters in xonsh. For example
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ echo "ßðđ"
|
||||
@ echo "ßðđ"
|
||||
xonsh: For full traceback set: $XONSH_SHOW_TRACEBACK = True
|
||||
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)
|
||||
|
||||
|
|
|
@ -45,7 +45,7 @@ On macOS, it is *strongly* recommended to install the ``gnureadline`` library if
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ pip3 install gnureadline
|
||||
@ pip3 install gnureadline
|
||||
|
||||
Path Helper
|
||||
^^^^^^^^^^^
|
||||
|
@ -84,7 +84,7 @@ Common packaging systems for macOS include
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ brew install bash-completion2
|
||||
@ brew install bash-completion2
|
||||
|
||||
This will install the bash_completion file in `/usr/local/share/bash-completion/bash_completion` which is in the current xonsh code and so should just work.
|
||||
|
||||
|
@ -92,7 +92,7 @@ Common packaging systems for macOS include
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ sudo port install bash-completion
|
||||
@ sudo port install bash-completion
|
||||
|
||||
|
||||
|
||||
|
@ -100,7 +100,7 @@ Common packaging systems for macOS include
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ $BASH_COMPLETIONS.insert(0, '/opt/local/share/bash-completion/bash_completion')
|
||||
@ $BASH_COMPLETIONS.insert(0, '/opt/local/share/bash-completion/bash_completion')
|
||||
|
||||
Note that the `bash completion project page <https://github.com/scop/bash-completion>`_ gives the script to be called as in .../profile.d/bash_completion.sh which will the call the script mentioned above and one in $XDG_CONFIG_HOME . Currently xonsh seems only to be able to read the first script directly.
|
||||
|
||||
|
|
|
@ -17,11 +17,11 @@ Vox
|
|||
|
||||
First, load the vox xontrib::
|
||||
|
||||
$ xontrib load vox
|
||||
@ xontrib load vox
|
||||
|
||||
To create a new environment with vox, run ``vox new <envname>``::
|
||||
|
||||
$ vox new myenv
|
||||
@ vox new myenv
|
||||
Creating environment...
|
||||
Environment "myenv" created. Activate it with "vox activate myenv".
|
||||
|
||||
|
@ -29,7 +29,7 @@ The interpreter ``vox`` uses to create a virtualenv is configured via the ``$VOX
|
|||
|
||||
You may also set the interpreter used to create the virtual environment by passing it explicitly to ``vox new`` i.e.::
|
||||
|
||||
$ vox new python2-env -p /usr/local/bin/python2
|
||||
@ vox new python2-env -p /usr/local/bin/python2
|
||||
|
||||
Under the hood, vox uses Python 3's ``venv`` module to create Python 3 virtualenvs. [this is the default]
|
||||
|
||||
|
@ -39,7 +39,7 @@ By default, environments are stored in ``~/.virtualenvs``, but you can override
|
|||
|
||||
To see all existing environments, run ``vox list``::
|
||||
|
||||
$ vox list
|
||||
@ vox list
|
||||
Available environments:
|
||||
eggs
|
||||
myenv
|
||||
|
@ -47,24 +47,24 @@ To see all existing environments, run ``vox list``::
|
|||
|
||||
To activate an environment, run ``vox activate <envname>``::
|
||||
|
||||
$ vox activate myenv
|
||||
@ vox activate myenv
|
||||
Activated "myenv".
|
||||
|
||||
Instead of ``activate``, you can call ``workon`` or ``enter``.
|
||||
|
||||
If you want to activate an environment which is stored somewhere else (maybe because it was created by another tool) you can pass to ``vox activate`` a path to a virtual environment::
|
||||
|
||||
$ vox activate /home/user/myenv
|
||||
@ vox activate /home/user/myenv
|
||||
Activated "/home/user/myenv".
|
||||
|
||||
To exit the currently active environment, run ``vox deactivate`` or ``vox exit``::
|
||||
|
||||
$ vox deactivate
|
||||
@ vox deactivate
|
||||
Deactivated "myenv".
|
||||
|
||||
To remove an environment, run ``vox remove <envname>``::
|
||||
|
||||
$ vox remove myenv
|
||||
@ vox remove myenv
|
||||
Environment "myenv" removed.
|
||||
|
||||
Instead of ``remove``, you can call ``rm``, ``delete``, or ``del``.
|
||||
|
|
|
@ -31,7 +31,7 @@ you are in a lesser terminal:
|
|||
.. code-block:: console
|
||||
|
||||
$ xonsh
|
||||
snail@home ~ $
|
||||
snail@home ~ @
|
||||
|
||||
Now we are in a xonsh shell. Our username happens to be ``snail``, our
|
||||
hostname happens to be ``home``, and we are in our home directory (``~``).
|
||||
|
@ -1571,7 +1571,7 @@ By default, the following variables are available for use:
|
|||
determined.
|
||||
* ``branch_bg_color``: Like, ``{branch_color}``, but sets a background color
|
||||
instead.
|
||||
* ``prompt_end``: ``#`` if the user has root/admin permissions ``$`` otherwise
|
||||
* ``prompt_end``: ``#`` if the user has root/admin permissions ``@`` otherwise
|
||||
* ``current_job``: The name of the command currently running in the
|
||||
foreground, if any.
|
||||
* ``vte_new_tab_cwd``: Issues VTE escape sequence for opening new tabs in the
|
||||
|
@ -1687,22 +1687,22 @@ of those calls will be inserted into the prompt). For example:
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
snail@home ~ $ $PROMPT_FIELDS['test'] = "hey"
|
||||
snail@home ~ $ $PROMPT = "{test} {cwd} $ "
|
||||
hey ~ $
|
||||
hey ~ $ import random
|
||||
hey ~ $ $PROMPT_FIELDS['test'] = lambda: random.randint(1,9)
|
||||
3 ~ $
|
||||
5 ~ $
|
||||
2 ~ $
|
||||
8 ~ $
|
||||
snail@home ~ @ $PROMPT_FIELDS['test'] = "hey"
|
||||
snail@home ~ @ $PROMPT = "{test} {cwd} @ "
|
||||
hey ~ @
|
||||
hey ~ @ import random
|
||||
hey ~ @ $PROMPT_FIELDS['test'] = lambda: random.randint(1,9)
|
||||
3 ~ @
|
||||
5 ~ @
|
||||
2 ~ @
|
||||
8 ~ @
|
||||
|
||||
Environment variables and functions are also available with the ``$``
|
||||
prefix. For example:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
snail@home ~ $ $PROMPT = "{$LANG} >"
|
||||
snail@home ~ @ $PROMPT = "{$LANG} >"
|
||||
en_US.utf8 >
|
||||
|
||||
Note that some entries of the ``$PROMPT_FIELDS`` are not always applicable, for
|
||||
|
@ -1713,9 +1713,9 @@ But let's consider a problem:
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
snail@home ~/xonsh $ $PROMPT = "{cwd_base} [{curr_branch}] $ "
|
||||
xonsh [main] $ cd ..
|
||||
~ [] $
|
||||
snail@home ~/xonsh @ $PROMPT = "{cwd_base} [{curr_branch}] @ "
|
||||
xonsh [main] @ cd ..
|
||||
~ [] @
|
||||
|
||||
We want the branch to be displayed in square brackets, but we also don't want
|
||||
the brackets (and the extra space) to be displayed when there is no branch. The
|
||||
|
@ -1724,9 +1724,9 @@ invoked only if the value is not ``None``:
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
snail@home ~/xonsh $ $PROMPT = "{cwd_base}{curr_branch: [{}]} $ "
|
||||
xonsh [main] $ cd ..
|
||||
~ $
|
||||
snail@home ~/xonsh @ $PROMPT = "{cwd_base}{curr_branch: [{}]} @ "
|
||||
xonsh [main] @ cd ..
|
||||
~ @
|
||||
|
||||
The curly brackets act as a placeholder, because the additional part is an
|
||||
ordinary format string. What we're doing here is equivalent to this expression:
|
||||
|
@ -1746,7 +1746,7 @@ and exit, instead of entering the command loop.
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ xonsh -c "echo @(7+3)"
|
||||
@ xonsh -c "echo @(7+3)"
|
||||
10
|
||||
|
||||
Longer scripts can be run either by specifying a filename containing the script,
|
||||
|
@ -1776,7 +1776,7 @@ This script could be run by piping its contents to xonsh:
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ cat test.xsh | xonsh
|
||||
@ cat test.xsh | xonsh
|
||||
file0.txt file1.txt file2.txt file3.txt file4.txt test_script.sh
|
||||
removing files
|
||||
test_script.sh
|
||||
|
@ -1787,7 +1787,7 @@ or by invoking xonsh with its filename as an argument:
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ xonsh test.xsh
|
||||
@ xonsh test.xsh
|
||||
file0.txt file1.txt file2.txt file3.txt file4.txt test_script.sh
|
||||
removing files
|
||||
test_script.sh
|
||||
|
@ -1829,7 +1829,7 @@ operates on a given argument, rather than on the string ``'xonsh'`` (notice how
|
|||
|
||||
.. code-block:: console
|
||||
|
||||
$ xonsh test2.xsh snails
|
||||
@ xonsh test2.xsh snails
|
||||
['test_script.sh', 'snails']
|
||||
file0.txt file1.txt file2.txt file3.txt file4.txt file5.txt test_script.sh
|
||||
removing files
|
||||
|
@ -1837,7 +1837,7 @@ operates on a given argument, rather than on the string ``'xonsh'`` (notice how
|
|||
adding files
|
||||
file0.txt file1.txt file2.txt file3.txt file4.txt file5.txt test_script.sh
|
||||
|
||||
$ echo @(' '.join($(cat @('file%d.txt' % i)).strip() for i in range(6)))
|
||||
@ echo @(' '.join($(cat @('file%d.txt' % i)).strip() for i in range(6)))
|
||||
s n a i l s
|
||||
|
||||
Additionally, if the script should exit if a command fails, set the
|
||||
|
|
|
@ -56,11 +56,11 @@ After starting a new xonsh session, try the following commands:
|
|||
|
||||
.. code-block:: none
|
||||
|
||||
$ history info
|
||||
@ history info
|
||||
backend: couchdb
|
||||
sessionid: 4198d678-1f0a-4ce3-aeb3-6d5517d7fc61
|
||||
|
||||
$ history -n
|
||||
@ history -n
|
||||
0: couchdb in action
|
||||
|
||||
Woohoo! We just wrote a working history backend!
|
||||
|
@ -77,7 +77,7 @@ After installing, check that it's configured correctly with ``curl``:
|
|||
|
||||
.. code-block:: none
|
||||
|
||||
$ curl -i 'http://127.0.0.1:5984/'
|
||||
@ curl -i 'http://127.0.0.1:5984/'
|
||||
HTTP/1.1 200 OK
|
||||
Cache-Control: must-revalidate
|
||||
Content-Length: 91
|
||||
|
@ -235,35 +235,35 @@ Let's start a new xonsh session:
|
|||
|
||||
.. code-block:: none
|
||||
|
||||
$ history info
|
||||
@ history info
|
||||
backend: couchdb
|
||||
sessionid: 1486035364166-3bb78606-dd59-4679
|
||||
|
||||
$ ls
|
||||
@ ls
|
||||
Applications Desktop Documents Downloads
|
||||
|
||||
$ echo hi
|
||||
@ echo hi
|
||||
hi
|
||||
|
||||
Start a second xonsh session:
|
||||
|
||||
.. code-block:: none
|
||||
|
||||
$ history info
|
||||
@ history info
|
||||
backend: couchdb
|
||||
sessionid: 1486035430658-6f81cd5d-b6d4-4f6a
|
||||
|
||||
$ echo new
|
||||
@ echo new
|
||||
new
|
||||
|
||||
$ history show all -nt
|
||||
@ history show all -nt
|
||||
0:(2017-02-02 19:36) history info
|
||||
1:(2017-02-02 19:36) ls
|
||||
2:(2017-02-02 19:37) echo hi
|
||||
3:(2017-02-02 19:37) history info
|
||||
4:(2017-02-02 19:37) echo new
|
||||
|
||||
$ history -nt
|
||||
@ history -nt
|
||||
0:(2017-02-02 19:37) history info
|
||||
1:(2017-02-02 19:37) echo new
|
||||
2:(2017-02-02 19:37) history show all -nt
|
||||
|
|
|
@ -63,7 +63,7 @@ in a question-and-answer format:
|
|||
|
||||
.. code-block:: xonshcon
|
||||
|
||||
$ xonfig wizard
|
||||
@ xonfig wizard
|
||||
|
||||
Welcome to the xonsh configuration wizard!
|
||||
------------------------------------------
|
||||
|
@ -72,7 +72,7 @@ in a question-and-answer format:
|
|||
wizard if the configuration file does not exist. However, you can
|
||||
always rerun this wizard with the xonfig command:
|
||||
|
||||
$ xonfig wizard
|
||||
@ xonfig wizard
|
||||
|
||||
This wizard will load an existing configuration, if it is available.
|
||||
Also never fear when this wizard saves its results! It will create
|
||||
|
|
23
news/new_prompt_end_char.rst
Normal file
23
news/new_prompt_end_char.rst
Normal file
|
@ -0,0 +1,23 @@
|
|||
**Added:**
|
||||
|
||||
* <news item>
|
||||
|
||||
**Changed:**
|
||||
|
||||
* The prompt end character switched to ``@``.
|
||||
|
||||
**Deprecated:**
|
||||
|
||||
* <news item>
|
||||
|
||||
**Removed:**
|
||||
|
||||
* <news item>
|
||||
|
||||
**Fixed:**
|
||||
|
||||
* <news item>
|
||||
|
||||
**Security:**
|
||||
|
||||
* <news item>
|
|
@ -340,7 +340,7 @@ class PromptFields(tp.MutableMapping[str, "FieldType"]):
|
|||
user=xp.os_environ.get(
|
||||
"USERNAME" if xp.ON_WINDOWS else "USER", "<user>"
|
||||
),
|
||||
prompt_end="#" if xt.is_superuser() else "$",
|
||||
prompt_end="#" if xt.is_superuser() else "@",
|
||||
hostname=socket.gethostname().split(".", 1)[0],
|
||||
cwd=_dynamically_collapsed_pwd,
|
||||
cwd_dir=lambda: os.path.join(os.path.dirname(_replace_home_cwd()), ""),
|
||||
|
|
Loading…
Add table
Reference in a new issue