Evolution of shells in Linux (2011) | Hacker News Reader

Evolution of shells in Linux (2011)

ibm.com

67 pointskercker46 comments

Does anybody know a shell that keeps its input line on top of the window?

Think of a browser window with the url-bar being the shell line editor. But of course I want a real, quick shell, not a clunky electron-based monster or some html based shell simulation in a browser.

I imagine that it will have a positive effect on our neck muscles if we would not have to stare at the bottom of the screen all the time, but instead at the top.

I looked into the existing pythonic shell libraries like the python-prompt-toolkit but could not figure out in a few minutes how this could be realized, so I hope some experts in this field would like to spend a few minutes on this?

Thanks for your attention!

In eg bash you can set the title of your X window to arbitrary things. See http://stackoverflow.com/questions/1687642/set-screen-title-...

You could reset the title on each keystroke, or even just after inputting the full command.

He means having the input prompt be on top, not the last command he wrote...

I think that it has to do with the flow of the text in the console. the historic text flows upwards, so it is natural to expect input on the next newline. You can of course use a termbox/termkit type library and move the input to the top row, but it would overwrite older historic text, unless you reverse the flow of the history as well.

You just need two text areas: one at the top where you enter text, and one at the bottom where the scrolling happens. This is not rocket science, but I'm sure it's actually literally impossible in Unix, which in general has never moved on from the idea that a computer's primary output device is a printer printing on an endless roll of paper.

Hum... Say you have an interactive command that takes a "y" keystroke.

Does your history becomes like this:

  Second result - line 1
  Second result - line 2
  Command prompt
  y
  First result - line 1
  First result - line 2

Or this:

  First result - line 1
  First result - line 2
  Command prompt
  y
  Second result - line 1
  Second result - line 2

And if it is the second option, how does it at the instants it shows the prompt, and after it gets a result?

Looks complex to me.

Sure you can, just use (n)curses.

Does that work with the scrollback? If it's supposed to, I've yet to see it ever happen!

Have a look at bpython.

I'll try it when I get a moment, but I'll take your word for it for now. From the screenshots it looks to me very much like it'll be a single scrolling viewport, though, with a line of input at the end. So, at heart, differing in some of the details, but no more than a few, a printer printing on a long roll of paper...

>So, at heart, differing in some of the details, but no more than a few, a printer printing on a long roll of paper...

The responses of commands are "long rolls of digital paper". They could be from 1 to millions of lines long.

So what exactly would your solution do differently?

And it's not "unix" that does it this way, it's VMS, Windows, and pretty much everybody.

In fact your concept is still not concrete enough to make sense. The browser can have a single address bar on top, because urls are a single string -- and they also don't interact with subsequent contents, commands, etc.

Well, yes, it doesn't attempt to modify the semantics of the terminal - the opposite, in fact. I brought it up as an example of something that uses curses for all kinds of fancy stuff, but integrates with the terminal's normal scrollback. Sorry for any misunderstanding.

This sounded like fun, so I had a go at implementing it for bash using ANSI control codes[0][1] (though other people have posted much better solutions). You still have to look at the bottom to see the command's output though, so I'm not sure you gain much. If you're having neck troubles, is adjusting your monitor an option?

[0] http://pastebin.com/xaLFyXtT - implementation

[1] http://www.termsys.demon.co.uk/vtansi.htm - reference for some ANSI control codes

https://github.com/swirepe/alwaysontop is this what you need?

ascii.io seems down, but there is another screencast hosted here: https://asciinema.org/a/3779

It seems to clear the screen at each new command, resetting scroll history every time. Renders it pretty much useless for most of us.

What part of

  unautoclear       Turn OFF clear-screen after each command.

seems difficult?

This looks great, I will try! Thanks to all of you for your efforts!

Maybe possible with two terminal windows? One to enter commands only, another for displaying any output -- chained together via named pipes.

No zsh? I've attempted to try zsh a couple of times, but both times I was daunted by the sheer number of config questions asked by the set-up tool (may have been Oh-My-Zsh, can't remember), questions to which my only answer could be "I don't know, the first one I guess?"

I was hoping to find some good reasons why I should (or shouldn't) use it over bash.

I switched to zsh a couple of months ago, with oh-my-zsh.

Just ignore the "i dont know" questions. The defaults all work well.

The improvements of zsh over bash are all rather small. And a lot can be achieved by configuring bash heavily. But they all add up to give a nice producivity boost.

What I like (some of those come from oh-my-zsh rather then zsh):

* way better autocompletion

* directory stacks (love em)

* way better behaviour for rm / rm -r (confirm prompts, etc)

* small but nice: if output of a program lacks a \n at the end, it is inserted (with a visual marker)

* ".." or "..." for going up the directory tree, without "cd"

* from oh-my: great aliases for git (git add - ga, git

It has really good completion, including path completion. It has virtually infinite shared history. You can do some powerful customizations.

bash is trying to catch up in many areas but not quite there.

Having said that, I've now switched to fish which I don't like but it doesn't need configuring.

> Having said that, I've now switched to fish which I don't like but it doesn't need configuring.

That's a plus, but I really don't like how unlike the standard shells fish is. That's not entirely a bad thing (c.f. eshell, which is an interesting experiment), but also not a good thing (c.f. eshell, which is AFAICT unusable).

Another issue I have with fish is its popularity. eshell isn't popular, and so eshellisms don't tend to creep into shared environments; fish is popular, and more and more fishisms are creeping into the world at large. This is not, I think, a good thing at all.

If you're putting shell examples out into the world, they should be POSIX-compatible, or at the very least an extension of POSIX; they shouldn't be some wonky other language (else why use shell at all; use a better language altogether, which fish isn't).

I'd really like to see a good reason to use fish over zsh or bash.

>If you're putting shell examples out into the world, they should be POSIX-compatible, or at the very least an extension of POSIX;

If you want to be constrained by POSIX (as we will all be for the next 100 years or so), there are literally myriads of shells you can use.

One of the compatibility breaks that I love about fish is that you can use unquoted variable expansion without needing to worry about it being broken on whitespace

    set foo "Hello World"
    count $foo  # gives 1

In my eyes, the "size of the delta" between, say, fish and bash, is similar to that between, say, Perl and PHP. Or C# and Java.

So I feel it's justified to say that fish is a different language than POSIX shell.

Bah.... Use Fish

Meh, fish seems to be gratuitously incompatible with sh/bash/zsh. In my experience it seems to be preferred by the sort of person who uses macOS and doesn't use vi or emacs.

I use vim & neovim :P on kUbuntu. Also, I don't notice that any script on bash stooped working because my main shell is fish.

...you are saying it as if it was a bad thing or something.

I'm pretty sure it's possible to configure fish, but I don't feel any need to. That's the good part - works out of box.

However I don't like their new shell syntax, especially env vars handling. Doubt it's configurable.

One of the deep concepts of fish is that everything is a function.

So while you can't do "PATH=$PATH", you could easily make a function that parses that for you, and have "env PATH=$PATH". It's a limitation.

However, it does mean that instead of something like Bash's insanity around P1 when you want a contextual prompt, fish_prompt is a function, with all the beauty of ifs, fors, and whiles spread out in an easy to read language.

Fish can be hit or miss, but it feels like Lua for the shell, to me.

I use and love fish, but zsh completion is more powerful.

Zsh is listed in figure one.

Well 2011 fish not was yet there. Someone should update it with fish becoming more popular.

The oldest commit on Github is from 2005, and it mentions documentation updates, so it seems Github doesn't have the whole history.

Personally, I like using NetBSD's Almquist Shell, which formed the basis of Dash. It is small and has the command line editing and tab completion features that I can't live without.

https://en.wikipedia.org/wiki/Almquist_shell

On a similar note, while I normally just stick with bash on Linux (path of least resistance), I really like OpenBSD's ksh. Not quite as small as ash, but still much smaller than either bash or zsh, but with all the essential features (many things people consider bashisms are actually kshisms, and OpenBSD has added many of the ones that truly were bashisms into their version of ksh, since so many scripts have come to rely on them).

Learnt new commands: pushd and popd

zsh can be configured so the cd command automatically becomes a pushd. This is such a huge improvement to me I stuck with it. (Fish has a similar feature, except it supports pushd/popd additionally.) (Maybe bash supports this, too, I have not used it much in the last couple of years.)

Interestingly, even cmd.exe on Windows (at least on Windows 7 and newer) supports pushd/popd.

The same can be done easily in bash with an alias:

alias cd=pushd

pushd/popd have been on it since Windows 2000

I don't see the fish...

xonsh is the only shell you need. It is far and away the best of all.

I so wanted to like xonsh, but the startup time is too slow. I keep spawing new shells every now and then for every little task. When I'm done with the task, I close it. Xonsh has noticeable startup delays.

I don't have a taste for pulldown terminals.

Sorry to hear you ran into problems. Start up time is pretty fast for me (~0.1-0.2 s). If it is slower than a second, I am very concerned. Please open an issue (with the results of the xonfig) so we can work through what is going wrong. Your workflow sounds similar to mine.

As per the pulldown terminals, do you mean the dropdown menus? If so this can be avoided by using the readline shell instead of the prompt-toolkit one.

Thank you for the response! For me, the startup time ranges between 0.3-0.45 seconds. I have an old i5 3rd Gen processor. Presumably, your system is faster. This should give you an idea of the timing of my shells, compared to the latest git checkout of xonsh:

    % for i in dash mksh zsh bash xonsh; do; /usr/bin/time $i -c /usr/bin/ls; done
    0.00user 0.00system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 1884maxresident)k
    0inputs+0outputs (0major+127minor)pagefaults 0swaps
    0.00user 0.00system 0:00.00elapsed 0%CPU (0avgtext+0avgdata 1820maxresident)k
    0inputs+0outputs (0major+136minor)pagefaults 0swaps
    0.00user 0.00system 0:00.00elapsed 50%CPU (0avgtext+0avgdata 3204maxresident)k
    0inputs+0outputs (0major+251minor)pagefaults 0swaps
    0.00user 0.00system 0:00.00elapsed 60%CPU (0avgtext+0avgdata 3092maxresident)k
    0inputs+0outputs (0major+244minor)pagefaults 0swaps
    0.41user 0.06system 0:00.48elapsed 100%CPU (0avgtext+0avgdata 58768maxresident)k
    0inputs+24outputs (0major+22347minor)pagefaults 0swaps

Do you think the difference is large enough to warrant a bug report?

I don't mean dropdown menus; "pulldown" was my misnomer. I meant dropdown terminal emulators like Guake, Terminator, Yakuake, etc. They are meant to be running in the background, and swoop down on pressing a hot key, inspired by "~" opening a console in Quake games.

Reply on news.ycombinator.com