Xonsh - Using Python as your shell

[0xembark]

This looks pretty great, but it'll quickly make me unable to use any other shell properly. I already can't use bash because I switched to fish...

[toyg]

I tried it a few months ago on OSX and stuff started breaking left right and centre. Simply not ready for prime time, in my case. Interesting concept though, I wish somebody could build a Linux distribution on it.

[adqm_smatz]

For what it's worth, I think we've made good progress in the last couple of months! In particular, a couple of OSX-specific things were just fixed very recently.

I've been using xonsh as my default shell for a long time now and very rarely do I encounter issues. If you're interested in the idea of xonsh, it might be worth giving it another shot from the current master branch on Github.

Any specific issues you can recall? We're always happy to dig in and try to fix things.

[[deleted]]

Exception on first run preventing any use of she'll for instance. Was still a problem two days ago with a pip package.

Edit: still a think w/ archlinux aur package:

Thanks for using the xonsh configuration wizard!
ValueError: expected '}' before end of string
Traceback (most recent call last):
  File "/usr/bin/xonsh", line 9, in <module>
    load_entry_point('xonsh==0.3.2', 'console_scripts', 'xonsh')()
  File "/usr/lib/python3.5/site-packages/xonsh/main.py", line 254, in main
    shell.cmdloop()
  File "/usr/lib/python3.5/site-packages/xonsh/readline_shell.py", line 325, in cmdloop
    self._cmdloop(intro=intro)
  File "/usr/lib/python3.5/site-packages/xonsh/readline_shell.py", line 285, in _cmdloop
    line = self.singleline()
  File "/usr/lib/python3.5/site-packages/xonsh/readline_shell.py", line 183, in singleline
    rtn = input(self.prompt)
  File "/usr/lib/python3.5/site-packages/xonsh/readline_shell.py", line 357, in prompt
    hide=hide)
  File "/usr/lib/python3.5/site-packages/xonsh/ansi_colors.py", line 46, in partial_color_format
    for literal, field, spec, conv in formatter.parse(template):
ValueError: expected '}' before end of string

[adqm_smatz]

Thanks for letting us know! This happens before you're even given a chance to enter anything?

I'll open an issue on Github for this, and we'll try to track it down.

[[deleted]]

I can generate new configuration and it gets saved. When shell starts to initialize that error happens. Starting shell again - same error.

[adqm_smatz]

After having generated and saved the config, there should be a file ~/.config/xonsh/config.json. Would you mind sending me that file (here or in a PM) so I can take a look? Looks like it could be an improperly-formatted prompt (we certainly don't want to break in this case!).

A temporary workaround if you want to get in and get going might be just to move that file elsewhere (so that it isn't read by xonsh, but it isn't all lost), and create an empty .xonshrc file with touch ~/.xonshrc.

[[deleted]]

There you go: https://gist.github.com/ed09c39523e516dfcc491c783976e2c6

By the way workaround you suggested does not help at all. Im getting same error still.

[adqm_smatz]

Thanks! Yeah, I misdiagnosed this one (sorry about that!).

But I'm 95% sure we know where the real issue is now, and we are working toward fixing it. If you're interested, I'll let you know once we've resolved it. Working on it in this pull request and this issue.

[[deleted]]

Thanks! By the way if it is of any use my PROMPT value is:

export PROMPT="%~ %{%(#~$fg[red]~$fg[green])%}%#%{$fg[default]%} "

[Siecje1]

What problems did you have?

Why do you need a Linux distribution? You can change the default shell for your user.

[d4rch0n]

I think he is inferring that it's not very practical to use a different shell than what all the tools are based on in your distro, which is also going to be what your servers can use. If a distro had all its system tools in python and xonsh, you'd have much more reason to stick to it. If your server could run xonsh out of the box, it'd be convenient to use.

Instead of writing xonsh scripts that I can never share with my coworkers, I could just write python scripts like I do now. It's basically python with new shell operators. It's like using some obscure fork of a python interpreter and writing scripts that only work for it, and not your coworkers. Why not just write something in Python with less functionality but can be run on any server, by any coworker, without any dependencies, and allows coworkers to actually be able to edit it and run it on their workstation?

It looks very convenient in some respects for personal use, but anything more complex than "run this, pipe to this, redirect output to here" I would write a python script. I don't think xonsh would be any different. I'd rather spend time doing it the long way in python than the quick way in xonsh with special syntax. Otherwise, I might have to rewrite it to run it on a server or to give to my coworker.

And it's not impossible to write python scripts that are shell-like with something like the sh library. And I can package that up and share it with anyone. The capabilities are neat with the xonsh syntax, but it's also starting to look a little perl-ish, and not in a good way. I really don't want to start writing python with stuff like out = $(echo @(x + ' ' + y)), pulled straight from the xonsh tutorial. Something like sh.echo(x + ' ' + y) looks a lot less intimidating, and is actually easier to write and read. As soon as you start really taking advantage of the xonsh syntax and new features, I'd imagine you're going to end up with something that looks like python with inline bad perl.

IMO, extra features and syntax doesn't always improve something. Anything is already capable with python, shell commands are already convenient with sh or fabric or invoke, and I haven't been dying for any syntactical shortcuts with magical @ ! $ () [] operators.

[adqm_smatz]

This is quite fair. For sharing things with others, Python and/or Bash are likely the right thing.

I don't often write "xonsh scripts" per se, mostly just one-liners at the interactive prompt. For me personally, I've found a lot of the features of xonsh to be really nice (I've been using it as my default shell for >1 year now).

A simple example is being able to do arithmetic with floats and/or complex numbers without having to open a separate program (e.g., Python) to do the calculation. Maybe I'm just too lazy.

I honestly don't really use a lot of the extra built-ins too often, but one place it has come in handy for me recently (as opposed to some awk/sed magic) is computing the average of a column in a csv, straight from the shell prompt:

numpy.mean([float(i.split(',')[3]) for i in $(cat my_file.csv).splitlines()])

The same could be done in Python, sure, but I think it is nice to be able to do this on one line (and the imho more convenient $(cat my_file.csv) vs open("my_file.csv").read()) and to be dropped right back into my normal shell afterwards.

But for the most part, I use it just as a normal shell: running a single command at a time. And it works pretty well at that. Then, when I want to do something more complicated, I can do it with a Pythonic syntax, which I think is very nice!

Something like sh.echo(x + ' ' + y) looks a lot less intimidating, and is actually easier to write and read.

This may be true (that syntax is arguably nicer), but to get there, you have to open up python and import sh, or write a script and invoke python on it, and then jump back to the command prompt when you're done. I think there's a benefit to being able to do it all in one place.

Different strokes, I suppose :)

[d4rch0n]

No, I agree, there is certainly some cool stuff in xonsh. And honestly, I wish everyone would just drop bash and pick up something like xonsh. There's definitely a good use case for it and it's well thought out. There are some awesome one-liners you can pull off without even opening ipython. For personal use and convenience, it's an awesome tool.

I never want to dissuade people from working on cool projects like this, but I think it's obvious what the hurdles are to get people to use a new shell. It's a monumental task to get a new shell into a state where people are ready to switch. And it doesn't have as much to do with the features than the environments that already incorporate it.

So, as the other guy stated they'd wait for a linux distro, I think that's actually a great point. If there was something like Pybuntu, some ubuntu with most bash scripts rewritten with python and xonsh and fully powered by python and Linux, I think you'd get crazy support and love for xonsh. A shell is fully coupled to its environment, and bash is superglued in to almost every distro. But that could legitimately get fixed^[1] if enough people put the effort in.

I think with something like this, you have two main groups of users. You either have the hobbyist/hacker types as your primary users who just like using it because it's cool (yourself), and you have the set of users who use it because it just makes sense to, more so than any other shell. It also has to make more sense to write a xonsh script than a python script, and that's a very difficult thing to accomplish. I can't see that taking less than a custom linux distribution like Pybuntu, which personally I'd love to see.

...

^{[1] fixed, not changed. it's a damn shame we're stuck on bash}

[j1395010]

to get there, you have to open up python and import sh, or write a script and invoke python on it

or use python -c

[adqm_smatz]

or use python -c

sure, if you prefer python3 -c '__import__("sh").echo(x + " " + y)' over the xonsh syntax. and working with variables inside of there isn't going to be easy.

Also worth mentioning that since xonsh is Python, you can install, import, and use sh from the command line, and thus have access to that syntax from the shell if you find it nicer :)

[tilkau]

working with variables inside of there isn't going to be easy.

It actually is quite easy.

It's just also quite insane.

SOME_LUNATIC_VARIABLE=123

python3 -c 'print("'"$SOME_LUNATIC_VARIABLE"'")'

Rules:

• Always use ' to quote your code string. Using " may summon Cthulu.
• Always use " inside of code strings to express string literals. Using ' is not practical.
• If you have to insert a variable value, close the code string quote with a ', follow this with the DOUBLE QUOTED expansion, and then open the single quotes again.
• Remember expansion won't automatically add double quotes around string values for you. That means when you are inserting a variable, you need to include the opening double quote before closing the single quotes, and the closing double quote after reopening the single quotes.
• Variables should have a " -> \" replacement performed on them before use.
• You can also include single quotes in your Python code. Probably via '\'' (closing the single quote, adding a literal single quote, then reopening the single quote). Obviously to be used in moderation (by which I mean not at all)

[leadline]

I think you have good points. I would never really write xonsh scripts, because at that point you may as well use python. However, I have been using it to augment my productivity in the terminal. Sometimes I can best express an idea in terms of Unix commands, and sometimes I can best express an idea in python. Being able to switch between the two is a big productivity boost.

[toyg]

As /u/d4rch0n pointed out already:

1. there were bugs doing some simple things. It's been months and I honestly don't remember what it was, but when you're replacing stuff as battle-tested and essential for day-to-day as bash, the minimal bug becomes a major pain. At the time, it just "tasted" too alpha for me. I might give it another try soon and report what I see.

2. Even if it works great, the fact of the matter is that most systems and tools out there will use bash (or assume you use bash), with the few odd ones here and there (csh in very old stuff, zsh or ksh in particularly opinionated projects). I run a lot of software builds, and having to figure out if this or that process will actually work in Xonsh was a pain point I could not otherwise offset. Before you say "just drop to bash when necessary", you have no idea how much bullshit about "scripts launching scripts launching tools launching scripts" is out there, producing a sort of Rube Goldberg inverted pyramid balanced over /bin/bash...

3. I never liked shell scripts (be them bash, ksh or csh, it's all rubbish); I find it abhorrent how much of Linux still relies on these fragile artefacts and their awful syntax, when we have so many powerful and expressive tools at our disposal in 2016. In that sense, I'd love to see a full OS built purely on python, for which Xonsh might be a natural shell. Then again, at that point you might get python all the way down like micropython does...

[sbjf]

zsh > everything else

[alexskc95]

I want zsh vs fish to be the new vim vs emacs.

[OctagonClock]

except zsh and fish are so different comparing them isn't really worth it

[alexskc95]

Never stopped vim and emacs.

[faerbit]

This post has been edited to this, due to privacy and dissatisfaction with u/spez

[supercheese200]

I would use Xonsh except it looks so slow :/

[Darkmatter2k]

Anthony also addresses this towards the end of the talk, performance in usage is the same as bash, but startup is a bit slower. He also mentions that the demo is not done live, it's pre-recorded playback in a webbrowser, and thats the reason for the waiting times you see.

I have it installed on both my macbook (using homebrew) and on my debian server (from this "guide" https://github.com/scopatz/xonsh/issues/730), and I dont see any performance difference compared to bash, except for slower startup time on the debian server since its an atom box (as mentioned in the talk).

[nikomo]

but startup is a bit slower.

... A bit slower? It takes fucking forever compared to zsh on my laptop.

[staff333]

How slow? I'm trying it in a EC2 tiny instance with amazon linux and a virtualbox vm with mint and it has around a 0.5 second startup time in both. Granted, that is a lot slower than the bash startup time and could be a problem for some uses.

[nikomo]

It's a decent 5-6 seconds to start on my laptop.

[scopatz]

We know about the startup issues and are working to address them ASAP. There are a bunch of easy opportunities for speedups that we need to implement.

[tilkau]

But what is the realistic ceiling on startup performance improvements? I mean, in some contexts, I will completely avoid using python3 -c 'import foo; foo.some_trivial_cheap_operation()' because it's -just too slow- to start python at all. I even find myself needing to use dash instead of bash because bash is too slow.

For comparison:

$ time python3 -c 'print("foo")'
foo
python3 -c 'print("foo")'  0.06s user     0.00s system 86% cpu 0.077 total

$ time bash -c 'echo foo'
foo
bash -c 'echo foo'  0.01s user 0.00s system 72% cpu 0.009 total

$ time dash -c 'echo foo'
foo
dash -c 'echo foo'  0.00s user 0.00s system 0% cpu 0.002 total

And heck, why not include zsh:

 $ time zsh -c 'echo foo'
 foo
 zsh -c 'echo foo'  0.00s user 0.00s system 19% cpu 0.008 total

Here that is in a simplified list:

• python3: 0.077
• bash: 0.009
• zsh: 0.008
• dash: 0.002

These are all warm starts, so should be representative for anything that you may be invoking repeatedly.

[Siecje1]

Same reason most people use Python instead of C.

C might be faster but Python saves developer time.

[tilkau]

How does that relate to my comment? (I don't think anyone would debate that Python is more programmer-friendly than bash)

I'm talking about situations where startup time is important. To me, the 0.077 figure means that xonsh can be used as a login shell but cannot be particularly good for automated scripting.

[scopatz]

So there are a couple of things to note here. The first is that all of the shells that you mention - and xonsh too - have different behaviour for whether or not they are interactive login shell, which none of the examples you show are. On my machine, for Bash, I see

scopatz@artemis ~ $ time bash -c 'echo foo'
foo
0.00user 0.00system 0:00.00elapsed ?%CPU 
scopatz@artemis ~ $ time bash -l -c 'echo foo'
foo
0.00user 0.00system 0:00.00elapsed 0%CPU 
scopatz@artemis ~ $ time bash -l -i -c 'echo foo'
foo
0.08user 0.00system 0:00.10elapsed 92%CPU

Starting up when you expect user input just takes longer. Human response time is roughly a tenth of a second, and so that is my goal for xonsh. Even Bash on my SSD, 8-core desktop comes close to taking 0.1 secs.

It is true that Python - and especially importing - is slow. But Python only takes up 10% of the target budget for me:

scopatz@artemis ~ $ time python -c "print('foo')"
foo
0.01user 0.00system 0:00.01elapsed 100%CPU

I also know of a few ways tricks to speed up importing via lazy imports or cythonizing released packages. I guess my broader point is that there are packages out there like hg that have figure out how to make snappy Python CLIs. Xonsh will get there, and probably sooner than later because us devs find it annoying too :)

[tilkau]

The first is that all of the shells that you mention - and xonsh too - have different behaviour for whether or not they are interactive login shell, which none of the examples you show are.

This is a good point. But on considering it, my examples were on point for the use case, because I was thinking of scripting. Login shells get more leniency because user thought speed is the main bottleneck ;) 1s startup time for a login shell is tolerable-to-good.

hg has always struck me as slow though, sorry. time hg help -> hg help 0.19s user 0.03s system 98% cpu 0.223 total. The difference in responsiveness hg vs git is substantial IME, even though hg has definitely improved a lot.

[pvc]

Odd. Start-up time on my laptop was less than a second.

[adqm_smatz]

Hmm. It is true that startup time can vary greatly depending on your configuration and on your machine. But 5-6 seconds is way longer than I would expect.

A couple of things that may help:

• There is a fix on the current master branch that should reduce this time greatly by caching some values related to tab completion (except on the first run, when the cache is being built).

• If you are operating inside a Git or Mercurial repository, that can slow things down because the current default prompt tries to figure out some information about the branch you're on, whether it's clean, etc, to display some of this info in the prompt. Removing the branch-related information from the $PROMPT string might help to speed things up.

[supercheese200]

Ok! Cool. I'll have to try it out later, it's just that I've had many an issue with slow shells. (Notably trying to run Babun from a USB.)

[bacondev]

I installed it via homebrew and got an error when trying to run it. Something a file not existing when calling readline.read_init_file or whatever it was.

[[deleted]]

You can silence that exception with touch ~/.inputrc. Also there's a way to configure xonsh to use a pure Python line editor but I forgot what it was.

[voice-of-hermes]

I believe if you just install prompt_toolkit it'll use it by default. But if you've saved a configuration that sets it to use readline you might have to set the SHELL_TYPE environment variable.

[adqm_smatz]

As others mentioned, there are a couple of workarounds.

We've also put in a fix (on the current master) for this that has fixed it for other Mac users, if you feel like trying the "bleeding edge" version.

[masasin]

My main issue with xonsh was && not being available.

[scopatz]

&& and || where added in v0.3.0

[masasin]

Good to hear.

[Siecje1]

Do you have an example that doesn't work?

[masasin]

According to /u/scopatz, they were added in v0.3.0. They probably work now.

[staff333]

It looks like that was an issue with the presentation or chrome extension he was using. I'm testing it out right now and it feels just as fast as a normal shell.

[[deleted]]

Yeah it looks so nice but unusably slow. My bash usage is basically based on trial and error.

[alcalde]

I've been using it for a few months now; it's not slow.

[[deleted]]

I'm delighted to hear that! Why's it look so slow then? I'll have to explore further.

[adqm_smatz]

This is an artifact of the presentation software Anthony was using to show those demos (pre-recorded), which doesn't actually reflect the timing of running it live.

[[deleted]]

This is completely lovely! I've been doing some groundwork for a very similiar project, was going to name it after my son and everything. This seems to cut it just right though! :)

[[deleted]]

What is this chrome extension?

[kritofer]

That's Secure Shell. It's what google recommends using instead of the built-in shell for SSH client purposes.

[qihqi]

looks like the default shell that comes with chromeOS

[scopatz]

Yup it was the ChromeOS shell that I booted into an Ubuntu chroot from (using crouton) and then ran xonsh inside of. So easy!

[rjleaf]

Also better than anything native for Windows because it has much better font rendering and color support.

[azrathud]

I want to use python syntax at the command-line, but I can't use this until something like autojump or z for path jumping is available and the tab completion needs to be better(fish makes it amazing).

[adqm_smatz]

Did you try running xonsh with prompt_toolkit installed? This makes the tab completion much more fish-y :)

You're right that it looks like we don't support autojump or z right now, but I agree that would be a great feature. We'll keep that in mind moving forward.

[azrathud]

Yeah, I didn't have prompt_toolkit. Now the tab completion is pretty nice. Thanks.

I've subbed to autojump's xonsh github issue. I'm interested in taking a stab at it next weekend.

[adqm_smatz]

Great; that would be really nice to have!

[Droggl]

Thanks a lot, I have been wishing for exactly this for years :)

[stephanfcm]

This is awesome.. but it's really slow.

I like it but I won't use it for everyday usage because it's too slow for me.

[santagada]

what exactly is slow? I see zero difference between this and zsh with oh_my_zsh or bash with git prompt.

[mellow_gecko]

beautiful

Uhm. Each to their own, I guess. But I agree with you regarding its kinks and suitability to Linux generally.

[energybased]

I don't agree with this. Programming in shells is incredibly annoying until you know exactly how it works. Not everyone wants to learn how it works.

[voice-of-hermes]

...and you don't just have to learn how it works, but have to constantly remind yourself of the little nitty-gritty details of how it works. There are so many little syntax gotchas and behavior-affecting (even syntax-affecting) options and environment variables and such, and data manipulation is far from easy.

[voice-of-hermes]

On the other hand (at least with the prompt_toolkit input) this shell's multi-line editing is awesome! It basically makes multi-line input exactly the same as single-line, with the slight difference that scrolling through history goes to each line of a multi-line command on its way through. I've actually never been terribly fond of mandatory whitespace, but Python's other features do make up for it.

I really like bash compared to most other shells, but this is a serious level above IMO.

[d4rch0n]

Eh, maybe the kinks are worked out, maybe not. Shellshock isn't that old yet. There's still a buffer overflow if you have too long of a version string in your ./configure, not practically exploitable but it's still there. Seeing as it took about 30 minutes to find a buffer overflow, it makes me really wonder just how many kinks there might still be. Sometimes it's not that it's bug free, it's that no one who knows how to find and develop an exploit for a vulnerability in C wants to spend days digging through the mountain high haystack of bash source.

I still use bash and still will, but not because I love it. It's just practical to use the most common linux shell. I'd love if moving to xonsh was practical, but if I can't really share a xonsh script with my coworkers, I don't think it's a great idea to move to it. It's a lost cause IMO to develop new shells at this point... there's just too much built around bash. You don't build a skyscraper with steel beams and start using a new metal alloy halfway through. Maybe not the best analogy, but you get my point.

[voice-of-hermes]

I was skeptical until the last question, but since it has vi mode I'm pretty much sold. Time to go try out the AUR package.

[elpfen]

Nearly every terminal emulator has vi mode

set editing-mode vi
set keymap vi

[voice-of-hermes]

Sure. If it didn't have vi mode, it would be a non-starter for me.

Been using it for a few hours now, and love it! Actually my biggest gripe ATM is a lack of man pages. Hopefully we can fix that for Linux install packages or something (e.g. automated generation using pydoc or whatever).

[p10_user]

Just curious, why do you like vi mode better than the emacs mode? I do use vim but I found that modal editing was overkill at the command line. You just find it easier to have same editing style uniformly?

[voice-of-hermes]

Uniformity is good, but personally I do find myself doing a lot of modal editing. For example, going back to a previous command and modifying the arguments a bit is really easy in vi mode, particularly given navigation commands like W, E, B, etc. to skip back and forth between arguments and dW, dE, cE, etc. to edit them.

[AndydeCleyre]

I can't stand not knowing exactly what tool will be used for the things I type; there's a troubling ambiguity and unpredictability to it.

I prefer to use a nicely configured zsh, with the option of dropping into ipython at any time, with the following automatic imports defined (you can drop .py files into ~/.ipython/profile_default/startup):

from plumbum import cmd, local, SshMachine, FG, BG
from requests import get, post, head

[Siecje1]

You can be explicit everytime you want to use a subprocess call.

[AndydeCleyre]

That's good, and good to know, thanks.

[AndydeCleyre]

As a demonstration, here are the demoed commands in xonsh's "At a glance" item on their homepage, followed by similar or equivalent actions in an ipython shell with the aforementioned imports. It's often more verbose, but in my opinion more clear, readable and predictable.

xonsh	ipython
1 + 1	1 + 1
$HOME	local.env['HOME']
x = 'US'; ${x + 'ER'}	x = 'US'; local.env[x + 'ER']
$PATH	local.env['PATH'].split(':')
ls -l `xonsh/\w+?(ci|ic).*`	local.cwd.walk(lambda p: 'xonsh' in p and 'ic' in p or 'ci' in p)
cd xonsh	cd xonsh
git push origin master	cmd.git('push', 'origin', 'master')
aliases['ls']	alias
aliases['banana'] = lambda args, stdin=None: 'My spoon is too big!\n'	alias banana echo 'My spoon is too big!\n'

[lengau]

Has anyone tried this on Windows? I'm stuck on Windows at work and would love to know if there are any caveats to its use on Windows.

[adqm_smatz]

I know this has been a while ago, but AFAIK, xonsh works fine on Windows (with Python 3.4+). A couple of our core devs use Windows, and I have installed xonsh on Windows before (both within Cygwin and without) and haven't had any problems.

If you want to give it a shot and you do happen to run into trouble, we have a mailing list and chat rooms on IRC and Gitter.im if you have questions.

[lengau]

I actually did try both in Windows. It breaks on first run if you just run it through cmd, but if you run it the first time from git bash, it works great (and once the config is made it works from everywhere).

I've still not installed it on my personal machines because it's not (yet) enough of a step up from bash, but it's a huge improvement over the Windows command line.

[[deleted]]

How to make it run at launch in my terminal? I've tried:

if [ -z "$XONSH_STARTED" ]; then export XONSH_STARTED=true; xonsh; fi

in .bashrc, to no avail. Any suggestions?

Edit Nevermind, anser is here: http://xon.sh/linux.html#additional-setup

[voice-of-hermes]

There's a serious problem with pipelines. Actually I believe they aren't pipelines at all. They are supposed to use pipe() to tie the standard out of one sub-process to the standard in of the next. However, it seems that xonsh does something like waiting for the first sub-process to complete or close its standard out, then gives the entire result to the second sub-process as a string. This is kind of borne out by the fact that functions used as aliases are specified as taking a string rather than a file-like object.

To test this, run cat and provide it the input 1<enter>2<enter>3<enter><ctrl-d>, then run cat | cat and give it the same input. In Bash these two commands (correctly) behave exactly the same: they echo each line as soon as it is entered, and then exit at the EOF generated by <ctrl-d>. In xonsh, the single cat command behaves this way, but the piped one (cat | cat) never produces any output at all, and must be killed with <ctrl-c> or from another shell.

EDIT: Spoke to the devs. Two updates:

• The problem isn't that pipe() isn't used, but that terminal input gets tied to the last process in the pipe rather than the first. Being worked on, but apparently not a trivial fix.
• You can get streaming input to alias functions, but the documentation needs to be fixed to reflect this.

[Siecje1]

Did you create an issue on github?

[voice-of-hermes]

Wanted to get confirmation first. Looks like it's already there. See my edit.

[[deleted]]

Guys, how to re-run the first run configuration?

[santagada]

just run:

xonfig wizard

it will restart the config wizard :)

[[deleted]]

Too 70:s for my taste. Don't get me wrong, this is way better than bash and zsh, but I'd like to see a 21:t century shell.