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?
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.
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?
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
> 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.
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
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.
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.
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.
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).
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.
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.
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:
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.
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!