Xiki: An amazing shell(techcrunch.com)
techcrunch.com
Xiki: An amazing shell
http://techcrunch.com/2014/07/07/programmer-craig-muth-kickstarts-a-new-version-of-his-arguably-amazing-shell-xiki/?utm_campaign=fb&ncid=fb
33 comments
You have a lot of good points, but this one jumped out at me:
> - Don't work remote. If it doesn't work remotely without installation (and none do), it's pointless to me.
That just sounds like a by-definition dismissal of all shells outside of the few provided by an OS. Having it work remotely is of course essential. But the most talented programmer alive is not going to write a shell that you can use without installing it. :/
> - Don't work remote. If it doesn't work remotely without installation (and none do), it's pointless to me.
That just sounds like a by-definition dismissal of all shells outside of the few provided by an OS. Having it work remotely is of course essential. But the most talented programmer alive is not going to write a shell that you can use without installing it. :/
Wow, an average of 30 terminals at all times? Just out of curiosity... what for exactly? Real-time monitoring?
I always have at least that many too. Not for real-time monitoring, just a large number of projects and threads of thought, many of which last for weeks or months. I do this for everything: I just totalled up all my currently open terminals, browser tabs, documents, etc., and got to over 700, and it's only that low because I've restarted a couple of times recently....
If I had that many I'd never actually finish anything.
I suffer from the same problem of too many terminal windows and browser tabs, and honestly it doesn't seem to help me much. It just dilutes my attention. I always do a logoff or restart at the end of every day now, and that seems to help a fair bit.
To keep track of what I need to do in the short term, I have a simple TODO text file.
To keep track of what I need to do in the short term, I have a simple TODO text file.
Unrelated, but if you're using plain old text files for todo lists, you should look at this: http://todotxt.com/
Or the Org Mode of Emacs
Me too! I've been using a plain TODO.txt for years, it's amazingly efficient.
I also usually have dozens of terminals open, though my workflow is probably different than most people on HN. I do 3d graphics on linux, so I have a separate desktop for each session of Nuke, Maya, houdini etc that I'm working on, each with a few associated terminals.
I very much dislike using things like tmux or even tabs in terminals, since I find it much easier for processes to get buried and to forget where everything is. It's much easier for me to have separate windows open so I can see everything that's going on at once.
I very much dislike using things like tmux or even tabs in terminals, since I find it much easier for processes to get buried and to forget where everything is. It's much easier for me to have separate windows open so I can see everything that's going on at once.
When you're using tmux or screen this isn't uncommon. I have a screen for each project, in a project I usually have around 5 to 10 tabs, and I have about 5 projects I'm currently working on.
I use a lot of terminal applications for mail, irc, music player, chat. Then there are always about 9 permanent terminals for generic local stuff such as setting up tunnels, man pages, socks proxy, a calculator, etc. Then I've got 9 terminals per remote location / project I'm working on. These are shells for file system navigation, grepping, reference, editor, a few database sessions, log file tailing. Then there are the random terminals opened for who knows what. I generally keep the terminals for projects I work on the most open all the time.
30 sounds like a lot, but really it's a very easy workflow process to follow if you've got virtual desktops. For instance, all persistent stuff (irc, music player, chat) lives on desktop 1. Mail, password manager, todo list on desktop 2. Browser on 3. Local terminals on 4. Remote terminals in tabs on 5, etc. I've been using the same workflow for years (going on decades). I can switch to nearly every window in two keystrokes, which never change.
30 sounds like a lot, but really it's a very easy workflow process to follow if you've got virtual desktops. For instance, all persistent stuff (irc, music player, chat) lives on desktop 1. Mail, password manager, todo list on desktop 2. Browser on 3. Local terminals on 4. Remote terminals in tabs on 5, etc. I've been using the same workflow for years (going on decades). I can switch to nearly every window in two keystrokes, which never change.
Yeah I start to have a panic attack when I see 5 or more shells open.
I mean, why do you have 30 tabs open at all times? You move on to something else, forget your tab was open, and go through at the end of the week and clean them all out.
You move on to something else, forget your tab was open, and go through at the end of the week and clean them all out.
No, that's what you do, and have extrapolated it to be what everyone does.
I use tree style tabs and mtputty, I leave open the things I use a lot and/or am focused on today. I find that I return to already open things enough that it's works for me. Re-opening programs and re-navigating to the same things I always use them for isn't a grand inconvenience or anything, but I do it for our software that uses floating licenses and it is annoying in my workflow.
No, that's what you do, and have extrapolated it to be what everyone does.
I use tree style tabs and mtputty, I leave open the things I use a lot and/or am focused on today. I find that I return to already open things enough that it's works for me. Re-opening programs and re-navigating to the same things I always use them for isn't a grand inconvenience or anything, but I do it for our software that uses floating licenses and it is annoying in my workflow.
TMUX is a thing. People should really be using it for this type of workflow considering you can set up environments that don't necessarily have to be running all the time for other projects. This seems far more like a self-inflicted problem than anything.
It is a thing, but I find that having separate desktops ("spaces" in OSX terminology) for different tasks helps me context switch back to the task quicker. I keep different desktops for different tasks, each with their own terminal running. Each terminal may have several tabs opens. When it's time to switch to that task, I switch to that desktop. When that task is completely done, I just close everything and remove the desktop.
Keeping this all in my head - even remembering how many shells I had open to do what - takes more thinking and effort than I want it to. It is far easier for me to just say, "This is where all the stuff for X goes" and physically isolate it from everything for Y and Z. And when I go back to it, it's all where I left it. I find this a much easier workflow.
Keeping this all in my head - even remembering how many shells I had open to do what - takes more thinking and effort than I want it to. It is far easier for me to just say, "This is where all the stuff for X goes" and physically isolate it from everything for Y and Z. And when I go back to it, it's all where I left it. I find this a much easier workflow.
That sounds a lot like my workflow actually.
You can still actually use tmux with it, with one session per workflow ('^b $' can name the session from inside it).
I found it useful, especially with Clojure and vim. The splits are nice everywhere, and it's way better to be in the habit of opening a tmux/screen when sshing.
That workflow is also why I hate OSX updates that force a reboot, which piles all the terminal and Chrome windows in one desktop. And then it's just an update for RAW camera files or something that I don't care about, but it nags me every day. /rant
I found it useful, especially with Clojure and vim. The splits are nice everywhere, and it's way better to be in the habit of opening a tmux/screen when sshing.
That workflow is also why I hate OSX updates that force a reboot, which piles all the terminal and Chrome windows in one desktop. And then it's just an update for RAW camera files or something that I don't care about, but it nags me every day. /rant
I still use screen remotely. This workflow is for the Mac in front of me. A lot of the terminals I have locally are associated with a screen session remotely. But keeping the local sessions open, active and logically grouped helps me remember what I was doing, and need to do.
Almost sounds like a cause for making some type of TODO tool for TMUX
Thanks for that about '$', I didn't know we could rename sessions.
You have some good points. Please try Xiki and let us know what you think. -The Internet.
> as I haven't tried it yet
Maybe it would be prudent to try it first, before commenting..
Maybe it would be prudent to try it first, before commenting..
I agree with this. I'm concerned with having to move my mouse cursor a lot. When it comes to doing terminal stuff, mouse cursors slow me down.
Right way I wondering about working remotely since its the shell in your editor (which I don't have).
without having tried it myself, the guy started work on it 13 years ago. that would give enough time to polish off rough edges like you mention, even redesign out some design errors.
IMO this should link to https://www.kickstarter.com/projects/xiki/xiki-the-command-r... and not one of the most awful, bottom feeder sites out there. I challenge you to find a single bit of information on the TC page that is not on the Kickstarter page.
Eh, I don't think Techcrunch is so bad. They don't usually have link baity titles like wired, they genuinely try to do a good job reporting on new startups and many yc companies get an initial post on TC which gives them that first boost of users. A Techcrunch article and Techcrunch coverage is like one of the biggest boosts from getting into YC.
Well Xiki has been posted several times here and it's the first time it reaches 1st link just St because of TC....
[deleted]
> “Originally I created Xiki for my own use,” said Muth. “When I was supposed to be doing my boring job as a software dev at banks and insurance companies in Ohio 13 years ago, I started making this thing that let me run commands and navigate files directly from my notes. Ever since then I’ve found myself unable to resist working on it. I use it for everything.”
Isn't this a bit concerning? It sounds like this was created on employer time with employer resources, yet there is nothing about this in the Kickstarter page itself. It seems like there could be a potential legal issue because of this, but there is no reassurance that either it's already been cleared, or that it's a potential risk.
Seems like a big oversight that might prevent some people who read this from contributing.
Isn't this a bit concerning? It sounds like this was created on employer time with employer resources, yet there is nothing about this in the Kickstarter page itself. It seems like there could be a potential legal issue because of this, but there is no reassurance that either it's already been cleared, or that it's a potential risk.
Seems like a big oversight that might prevent some people who read this from contributing.
Maybe he does own the IP outright. He negotiated for the right to create side projects and has paperwork to prove it?
Or maybe he figures it's his because it's not within the scope of his employment. i.e. -- has nothing to do with banks in and of itself.
Or maybe he figures it's his because it's not within the scope of his employment. i.e. -- has nothing to do with banks in and of itself.
> when I was supposed to be doing my job
No negotiating your way out of that. I know lots of people have done this type of thing at work, but I guarantee you he didn't have anything in his employment agreement that said "If I dick around instead of working and get paid for it like I was working, everything is fine, don't even worry about it."
That's a fire-able offense for any sane employer that doesn't have a 20% time deal or something similar. Hell, most employers specifically address this in the employment agreement.
I've got 15% time at my job, and I still wouldn't do this unless it was going to directly benefit my company, including other people that work here.
No negotiating your way out of that. I know lots of people have done this type of thing at work, but I guarantee you he didn't have anything in his employment agreement that said "If I dick around instead of working and get paid for it like I was working, everything is fine, don't even worry about it."
That's a fire-able offense for any sane employer that doesn't have a 20% time deal or something similar. Hell, most employers specifically address this in the employment agreement.
I've got 15% time at my job, and I still wouldn't do this unless it was going to directly benefit my company, including other people that work here.
Well I know I negotiate for the right to keep developing my own projects. Also, I work remote, and to me -- time is fungible -- I work nights/weekends etc. So if I work on a fun project 'during the workday' it is still mine, didn't become my employers suddenly, I just have to make up the worktime.
That's a major advantage to WFH. Just don't use company equipment when you do it.
I don't like to sound derogatory, but xiki would have to turn into a multi million dollar business before insurance or bank companies would consider any legal action.
"but xiki would have to turn into a multi million dollar business before insurance or bank companies would consider any legal action."
Or until they step on the wrong foot, or rub some executive the wrong way.
It's murky water and just because in most situations it'll be "okay", doesn't mean we shouldn't worry about it from the start.
It's murky water and just because in most situations it'll be "okay", doesn't mean we shouldn't worry about it from the start.
Holy freaking crap that's amazing. I love how the video all of the sudden starts to show 9000 features/ways it can be used. Looks like the paradigm adapts well to many different common workflows.
It's really great to see someone really thinking from scratch about the shell -- something that very rarely goes through any meaningful changes like this. I hope this project goes far and becomes the new default.
It's really great to see someone really thinking from scratch about the shell -- something that very rarely goes through any meaningful changes like this. I hope this project goes far and becomes the new default.
This reminds me of ACME http://en.wikipedia.org/wiki/Acme_(text_editor). To me it doesn't look like something new at all.
The cool thing about this project is it doesn't interrupt how you use your mouse. Using acme makes you learn how to use a mouse again like going from vim to emacs makes all your keybindings screw up.
Not that i'm saying copying acme is a bad thing, that editor is really underated.
The cool thing about this project is it doesn't interrupt how you use your mouse. Using acme makes you learn how to use a mouse again like going from vim to emacs makes all your keybindings screw up.
Not that i'm saying copying acme is a bad thing, that editor is really underated.
I played with Acme the other day and was blown away. The everything as a command idea is really powerful. Definitely underrated, would be great if it got a modern reboot.
For the unfamiliar this video by Russ Cox covers it pretty well. http://research.swtch.com/acme
For the unfamiliar this video by Russ Cox covers it pretty well. http://research.swtch.com/acme
> It's really great to see someone really thinking from scratch about the shell
Arguably, PowerShell is shell reinvented too. But IMO someone definitely should revamp the Unix shell. If we're not talking about the actual functionality (commands etc.) but the "building blocks", I actually like PowerShell more than traditional Unix shells at this point.
This shell however fails to impress me, I don't see the point.
Arguably, PowerShell is shell reinvented too. But IMO someone definitely should revamp the Unix shell. If we're not talking about the actual functionality (commands etc.) but the "building blocks", I actually like PowerShell more than traditional Unix shells at this point.
This shell however fails to impress me, I don't see the point.
What features would you like to see in a Unix-like shell that are not available?
I think passing around real objects instead of character strings is cool. It's less brittle, and you don't have to have an ad-hoc and flawed parser at every step.
As someone who thinks powershell and objects are really great.. Until you want to create a firewall rule with a principal exception using the docs: http://technet.microsoft.com/en-us/library/jj554906.aspx.
:|
:|
I love PS too but creating a new ACL is very sucky too.
I think PS is so good it exposes the really shit bits MS built decades ago but covered up with a pretty UI.
I'm sure they'll eventually make a pass over these crap parts and refactor them. This must be what they mean by an API driver vs Text driven OS. At least anything nix you just have to spit out a text file and you're good.
I think PS is so good it exposes the really shit bits MS built decades ago but covered up with a pretty UI.
I'm sure they'll eventually make a pass over these crap parts and refactor them. This must be what they mean by an API driver vs Text driven OS. At least anything nix you just have to spit out a text file and you're good.
Something like a Python/Ruby/whatever REPL with shell functions? Something like 'ls' would return an array of objects describing files, like:
def name(text):
return lambda file: file.name.find(text) > -1
ls().filter(name('.txt'))
> Something like 'ls' would return an array of objects describing files
You probably think of type-safe pipes similar to Go channels.
You probably think of type-safe pipes similar to Go channels.
I was actually thinking I'd like a Go-like CLI. Realistically, I probably more want to convert a couple shitty shell scripts into proper Go programs and keep on using bash where it is appropriate.
So, shell commands that produce and consume JSON?
No, objects. Non-text. Real data. Plus methods.
Read a PowerShell primer to better understand this. PowerShell is geniusly designed and horribly implemented, so there's little point actually using it, but UNIX could really really use some of its ideas.
Read a PowerShell primer to better understand this. PowerShell is geniusly designed and horribly implemented, so there's little point actually using it, but UNIX could really really use some of its ideas.
PS is absolutely essential if you are stuck administering Windows machines (esp. large numbers of them in a server farm). It makes working with Windows (mostly) tolerable if you are using a reasonably modern Windows version (2012+).
Powershell has some nice features like native arrays and hashmaps which can be mixed together into complex objects and then converted to JSON. Combined with native web request cmdlets (Invoke-RestMethod et al) it makes interacting with web services easier than the bash equivalent, where you have to use curl/wget, string munging and jq (which isn't usually part of the standard install).
Powershell has some nice features like native arrays and hashmaps which can be mixed together into complex objects and then converted to JSON. Combined with native web request cmdlets (Invoke-RestMethod et al) it makes interacting with web services easier than the bash equivalent, where you have to use curl/wget, string munging and jq (which isn't usually part of the standard install).
It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies. And classic pipes are not so bad as PS evangelists saying. PS “objects” are basically .Net objects and you can't easily write python or perl applications compatible with PS features.
> It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies.
This is not true. In fact, despite its many flaws, PowerShell did solve this particular one: any object stream can also be rendered as a string. This is exactly what happens when you just type `ls` into a PowerShell window.
I can completely imagine that a UNIX `ls` implementation would return a stream of objects (not necessarily .NET objects - just some runtime's native object format) that, when called .toString() on, would return exactly the same textual output as common UNIX `ls`. Then, you'd need a way to differentiate between two pipes. Maybe with syntax (i.e. | for string pipes, [] for object pipes, whatever) or maybe through magic ("hey, these two processes both have the capability to pipe objects instead of characters, let's tie them together as objects" somewhere at the shell level). I'm not sure how feasible either are, but I'm sure you can imagine that this problem could be solved. Then, if the shell sees that whichever process accepts the output of `ls` doesn't understand objects, just text, then it calls `.toString` on every object and renders that to oldschool character stdout.
This is not true. In fact, despite its many flaws, PowerShell did solve this particular one: any object stream can also be rendered as a string. This is exactly what happens when you just type `ls` into a PowerShell window.
I can completely imagine that a UNIX `ls` implementation would return a stream of objects (not necessarily .NET objects - just some runtime's native object format) that, when called .toString() on, would return exactly the same textual output as common UNIX `ls`. Then, you'd need a way to differentiate between two pipes. Maybe with syntax (i.e. | for string pipes, [] for object pipes, whatever) or maybe through magic ("hey, these two processes both have the capability to pipe objects instead of characters, let's tie them together as objects" somewhere at the shell level). I'm not sure how feasible either are, but I'm sure you can imagine that this problem could be solved. Then, if the shell sees that whichever process accepts the output of `ls` doesn't understand objects, just text, then it calls `.toString` on every object and renders that to oldschool character stdout.
>It's impossible to “redesign” shell fundamentals in Unix because it will be incompatible with all other old-style utilies
So?
For one, you could redesign the basic utilities too. Or offer a sumplementary revamp versions of some.
Second, you could use them in a less capable "text mode" and still get all the other benefits from the new shell.
>And classic pipes are not so bad as PS evangelists saying.
Well, they are not that relevant to 2014 either.
So?
For one, you could redesign the basic utilities too. Or offer a sumplementary revamp versions of some.
Second, you could use them in a less capable "text mode" and still get all the other benefits from the new shell.
>And classic pipes are not so bad as PS evangelists saying.
Well, they are not that relevant to 2014 either.
Colin Walters tried with Hotwire Shell [1]. However, it has been abandoned for years.
1: http://blog.verbum.org/2008/03/23/hotwire-hypershell-0-721-r...
1: http://blog.verbum.org/2008/03/23/hotwire-hypershell-0-721-r...
What makes you say PS is horribly implemented ?
Just a bunch:
Doing really common things, such as "find the directory of the currently executing script" can only by done by copy-pasting a non-trivial 3-line function from Stack Overflow. In batch (of all scripting languages), it's "%~dp0". Cryptic, yes, but at least it's in there. Similarly, the internet is full of blog posts with 1000-word articles explain how "easy" it is to do something in PowerShell that should've been a one liner to begin with. Basically, the builtins just suck. Batteries included? No way.
Someone at the MS marketing department decided that, in order to make PowerShell popular, it has to be cool. As a result, the above-mentioned blog posts contain example code like `echo "I Love PowerShell"`, making it sound amazing that should-be trivial stuff is only a matter of copying five lines of code [0].
In general, writing PS scripts is a really odd mishmash of bash-isms, batch-isms and .NET-isms.
Because PS is such a weird mismash of things, the ecosystem generally consists of people who don't even try to understand what's going on, but just hack some stuff together until it kind of works. This makes online resources, well, less useful than they could be.
Writing stuff that works like native Cmdlets is weird. You can make functions, but they're not entirely the same, and if you really want Cmdlets, you have to use a .NET language. I really wonder why the hell there's such a fundamental difference between functions and Cmdlets, they could just be the same thing. I also wonder why PowerShell can't just be a real .NET language just like all the others. It's a weird half-assed-in-the-middle thing.
[0] http://blogs.msdn.com/b/powershell/archive/2007/06/19/get-sc...
Doing really common things, such as "find the directory of the currently executing script" can only by done by copy-pasting a non-trivial 3-line function from Stack Overflow. In batch (of all scripting languages), it's "%~dp0". Cryptic, yes, but at least it's in there. Similarly, the internet is full of blog posts with 1000-word articles explain how "easy" it is to do something in PowerShell that should've been a one liner to begin with. Basically, the builtins just suck. Batteries included? No way.
Someone at the MS marketing department decided that, in order to make PowerShell popular, it has to be cool. As a result, the above-mentioned blog posts contain example code like `echo "I Love PowerShell"`, making it sound amazing that should-be trivial stuff is only a matter of copying five lines of code [0].
In general, writing PS scripts is a really odd mishmash of bash-isms, batch-isms and .NET-isms.
Because PS is such a weird mismash of things, the ecosystem generally consists of people who don't even try to understand what's going on, but just hack some stuff together until it kind of works. This makes online resources, well, less useful than they could be.
Writing stuff that works like native Cmdlets is weird. You can make functions, but they're not entirely the same, and if you really want Cmdlets, you have to use a .NET language. I really wonder why the hell there's such a fundamental difference between functions and Cmdlets, they could just be the same thing. I also wonder why PowerShell can't just be a real .NET language just like all the others. It's a weird half-assed-in-the-middle thing.
[0] http://blogs.msdn.com/b/powershell/archive/2007/06/19/get-sc...
Here's the thing about PowerShell: the community is not nearly as strong as bash/linux/unix. There's also been a substantial amount of churn between versions. These two things (combined with the insanity that is Technet) result in frequently less-than-helpful Google results when researching a particular problem. More often than not the first Stackoverflow result is either flat out wrong or non-idiomatic.
It doesn't help that (as you mentioned) you can do straight .NET stuff in Powershell also, so even if there is a cleaner, native cmdlet available half the Google results for a given problem will be some weird .NET mashup.
Also, Windows has it's own bizarre legacy command line tools ("net", "sc", etc.) which predate PS and further convolute any attempt to find the "right" solution to any given problem.
In general, if you're using Windows 2012+, 95% of systems administration and programming tasks now have native Powershell cmdlets. There is very little need to dive into .NET or WMI crap anymore, thank God.
It doesn't help that (as you mentioned) you can do straight .NET stuff in Powershell also, so even if there is a cleaner, native cmdlet available half the Google results for a given problem will be some weird .NET mashup.
Also, Windows has it's own bizarre legacy command line tools ("net", "sc", etc.) which predate PS and further convolute any attempt to find the "right" solution to any given problem.
In general, if you're using Windows 2012+, 95% of systems administration and programming tasks now have native Powershell cmdlets. There is very little need to dive into .NET or WMI crap anymore, thank God.
Yeah, I think what you call legacy command line tools are the biggest part of the problem, but the mere fact that there are new and old ways to do things _will_ be a problem in the future.
In general, Windows tends to give you an API whereas UNIX historically is data centric. My experience is that I prefer the latter. Greatly.
For example, to get change stuff in the AD environment at work, the local windowshead wants me to send the changeset in a home cooked format for his horrible PS muck to parse. Integration with configuration management systems is spotty at best, and if I in two years time need to revisit the change I have to pray that particular backend still exists.
If I did it in UNIX I would just accept standard diff:s, keep data version controlled, and be done with it.
In general, Windows tends to give you an API whereas UNIX historically is data centric. My experience is that I prefer the latter. Greatly.
For example, to get change stuff in the AD environment at work, the local windowshead wants me to send the changeset in a home cooked format for his horrible PS muck to parse. Integration with configuration management systems is spotty at best, and if I in two years time need to revisit the change I have to pray that particular backend still exists.
If I did it in UNIX I would just accept standard diff:s, keep data version controlled, and be done with it.
> "find the directory of the currently executing script"
Did you miss `$PSScriptRoot` ? Can piping that to split-path help you out?
Since PS 2.0 you got to write completely equal cmdlets in PS or .NET there's no different at all anymore.
Your link is dated 19 Jun 2007 which would be PS 1.0, 2 years before windows 7 came out. Were on 4.0 now 6 years later maybe it's time for another look.
I feel your reference experience with PS is out of date. You get to grips with how the get-help platform works PS is amazingly consistent. Where it isn't is busting out .NET.
Did you miss `$PSScriptRoot` ? Can piping that to split-path help you out?
Since PS 2.0 you got to write completely equal cmdlets in PS or .NET there's no different at all anymore.
Your link is dated 19 Jun 2007 which would be PS 1.0, 2 years before windows 7 came out. Were on 4.0 now 6 years later maybe it's time for another look.
I feel your reference experience with PS is out of date. You get to grips with how the get-help platform works PS is amazingly consistent. Where it isn't is busting out .NET.
Hmmm, cool! Indeed my experience is 3-ish years old. I'll give it another chance next time I need something like it! Thanks for pointing this out.
ksh allows you to define and return types - their declarations are very close to those of C++.
[deleted]
Actually, that's exactly where the video lost me. A few additional shell capabilities? I'm interested -- cool!
But throw in a database editor and a million other unrelated-to-the-shell features? I've been down that road before, and it's a maintenance nightmare. Unless this project has huge community backing, it seems inevitable that the development resources will be stretched too thin. Then it won't work on my next computer and the bug report will sit in the queue for months while I return to bash. I don't think I want to play this game.
But throw in a database editor and a million other unrelated-to-the-shell features? I've been down that road before, and it's a maintenance nightmare. Unless this project has huge community backing, it seems inevitable that the development resources will be stretched too thin. Then it won't work on my next computer and the bug report will sit in the queue for months while I return to bash. I don't think I want to play this game.
Yeah, reminds me of https://twitter.com/korkyplunger/status/485729264432472065.
I quite like fish and have been using it painlessly for nearly 6 months now. I wish fish included an actual programming language that could replace bash scripts, but the sane advice from fish devs is to use a real programming language instead of bash or another shell script. Other than that I've become quite dependent on the nice autocomplete and suggestions from fish. It just works and I never have to deal with any problems once you get over the initial learning curve bump which isn't that big.
I've been thinking about trying out Fish shell for awhile, though I have zsh setup to my liking.
Concerning Xiki, it definitely remind me of Emacs org mode / shell.
Concerning Xiki, it definitely remind me of Emacs org mode / shell.
You can go a long way with bash; it's worth learning because it lets you glue tools written in different "real" languages together very easily, as long as they all talk text. There aren't many other languages specifically designed for process control, orchestration and piping.
I don't like fish because it has almost no features, compared with bash.
I don't like fish because it has almost no features, compared with bash.
> I don't like fish because it has almost no features, compared with bash.
Which features would that be?
Which features would that be?
I've never understood why anyone would inflict oneself with bash scripting. If you really need something portable you should use standard /bin/sh anyway since bash is not installed by default everywhere (I believe many linux distros don't even ship with bash anymore, but a lightweight clone called "dash"?).
And if you don't care about portability out of the box, why not use... Well basically anything else? Perl, python, ruby, lua, scheme, whatever.
The only shell scripts I ever write are basically a list of command to execute sequentially. If I need something more complex (control flow, user input, proper error handling, nontrivial string manipulation) I switch to some other programming language, it's just not worth the pain.
And if you don't care about portability out of the box, why not use... Well basically anything else? Perl, python, ruby, lua, scheme, whatever.
The only shell scripts I ever write are basically a list of command to execute sequentially. If I need something more complex (control flow, user input, proper error handling, nontrivial string manipulation) I switch to some other programming language, it's just not worth the pain.
Many Linux distros ship with /bin/sh being dash, but they also come with /bin/bash. A lot of scripts obviously depend on bash, so distro maintainers have had to either fix them to depend only on POSIXy "sh" or just put #!/bin/bash at the top.
The reason to use dash instead of bash is speed and to a lesser extent memory usage. The goal isn't to stop needing bash, it's to speed up boot times etc. Or at least it was five years ago when this transition was happening.
The reason to use dash instead of bash is speed and to a lesser extent memory usage. The goal isn't to stop needing bash, it's to speed up boot times etc. Or at least it was five years ago when this transition was happening.
When I write scripts, I often need to execute programs written in different languages. Writing such scripts in a languages like Python and Ruby is very clumsy.
Whereas the scripts I write in Ruby tend to rely heavily on a bunch of gems that add enormously to startup time. These scripts also often end up as stages in a pipeline executed from bash.
Fork/join shared-nothing parallelism is also very easy to do in bash, and is how I normally use more cores to get jobs done more quickly.
Whereas the scripts I write in Ruby tend to rely heavily on a bunch of gems that add enormously to startup time. These scripts also often end up as stages in a pipeline executed from bash.
Fork/join shared-nothing parallelism is also very easy to do in bash, and is how I normally use more cores to get jobs done more quickly.
I don't know, I feel like POpen and friends in python just aren't as nice as doing 'thing-one | thing-two' kinda stuff, with some ifs, and some variables.
Fish is interesting and grows on you but suffers from a number of showstopper bugs (e.g [0]) that prevent me from using it.
[0]: https://github.com/fish-shell/fish-shell/issues/1374
[0]: https://github.com/fish-shell/fish-shell/issues/1374
I used fish for several years and fortunately never came across that one. It's pretty awful.
The whole bash shell is built around input/output. A command generates output. Which might be input for another program. This forces commands to be non-interactive, and just plaint text. But it comes with the immense power of building great programs using functional composition. It looks like Xiki breaks that in its core, and provides "UIX" ouputs to programs. I'm not sure i like that complexity. I'd prefer the simplicity that bash provides.
> "When I was supposed to be doing my boring job as a software dev at banks and insurance companies in Ohio 13 years ago, I started making this thing that let me run commands and navigate files directly from my notes."
With all the stories of disgruntled developers complaining that their employer took ownership of something they'd worked on in their spare time, I wouldn't be surprised if his old employers came a knocking.
If it wasn't for that, I'd likely already be backing the new version, it feels very good to use. The video is very slick, there are some companies out there making good money producing these things!
With all the stories of disgruntled developers complaining that their employer took ownership of something they'd worked on in their spare time, I wouldn't be surprised if his old employers came a knocking.
If it wasn't for that, I'd likely already be backing the new version, it feels very good to use. The video is very slick, there are some companies out there making good money producing these things!
He would have to be very unlucky for that to happen, but admitting it online was perhaps not the best move.
Installed, started. xiki status says it's running but I'm back in my usual shell and nothing works any different. No mouse interaction like in the video. Maybe I'm missing something obvious, maybe the tutorial (Where is it?) or is it an OSX only thing? I'm on Linux.
I started the web interface, used it to hook xiki to emacs, restarted emacs and run into the unfixed "error: el4r-instance is dead" bug.
I stopped using xiki. Maybe I'll give it a try when I'll have time to investigate but it's 2014. There are too many tools battling for mindshare and if something doesn't have a good tutorial and doesn't work out of the box isn't giving a good signal.
I started the web interface, used it to hook xiki to emacs, restarted emacs and run into the unfixed "error: el4r-instance is dead" bug.
I stopped using xiki. Maybe I'll give it a try when I'll have time to investigate but it's 2014. There are too many tools battling for mindshare and if something doesn't have a good tutorial and doesn't work out of the box isn't giving a good signal.
With all due respect, this looks like an early-stage project. If everyone adopts such a dismissive attitude, Show HN might as well not exist.
The first commit in git is from 2008.
https://github.com/trogdoro/xiki/commits/master?page=17
From http://www.linux.com/learn/tutorials/778419-meet-xiki-the-re... it turns out than "Craig Muth, has been working on Xiki for ten years". Maybe not a mature project but not an early stage one.
I think the opposite is true: If the cultural norm here was to insist on good, simple installation and basic usage tutorials, then we'd see more of them and everyone would benefit.
This doesn't imply that you can't share rough, buggy prototypes. It just means that before you do, it would be expected that you spend more time guiding people to get up and running and pointing out possible pitfalls.
I'd argue that in many cases this doesn't even take that much time and yet is the single most important thing you can do when sharing.
Note: I'm just addressing your general point and not making a comment on xiki's install process in particular.
This doesn't imply that you can't share rough, buggy prototypes. It just means that before you do, it would be expected that you spend more time guiding people to get up and running and pointing out possible pitfalls.
I'd argue that in many cases this doesn't even take that much time and yet is the single most important thing you can do when sharing.
Note: I'm just addressing your general point and not making a comment on xiki's install process in particular.
I actually like my shell as it is. I like the old fashion with no mouse interaction except for scrolling. Is it just me? But I have to say the interactive search is appealing.
My approach to CLI is basically: if I wanted to use the mouse, I wouldn't be in the terminal. Having to reach for the mouse is a huge waste of time and I only do it if I need to scroll (rare) or copy+paste (relatively common).
Although since I use OS X (Darwin) I don't always need the mouse to copy+paste (ie. pbcopy -> cmd+V).
Although since I use OS X (Darwin) I don't always need the mouse to copy+paste (ie. pbcopy -> cmd+V).
Yes! I agree completely.
There's also one more situation where we need the mouse: selecting a specific text on the console to copy & paste.
There's also one more situation where we need the mouse: selecting a specific text on the console to copy & paste.
Speaking of shells, I wish there were a shell inspired by python, able to conveniently use python libraries (perhaps even auto-import them), but with the convenience features of common shells. I can never remember the ghastly syntax of bash.
Maybe the now defunct pysh profile of ipython [1] is close to what you want. (It's defunct because it is mostly unneccesary in recent versions of ipython, that page shows how to get most (all?) of the functionality it used to provide.)
For Perl instead of Python there are psh [2] and zoidberg [3].
[1] http://ipython.org/ipython-doc/dev/interactive/shell.html
[2] http://gnp.github.io/psh/
[3] https://github.com/jberger/Zoidberg
For Perl instead of Python there are psh [2] and zoidberg [3].
[1] http://ipython.org/ipython-doc/dev/interactive/shell.html
[2] http://gnp.github.io/psh/
[3] https://github.com/jberger/Zoidberg
This feels very like what iPython notebooks provides, but applied to shell commands rather than code.
It's a cute video, but I can't quite help feeling this is going to be far less useful in practice than it's made out to be.
It's a cute video, but I can't quite help feeling this is going to be far less useful in practice than it's made out to be.
I tend to agree. The biggest leap for me was switching to oh-my-zsh (near life changing). :-)
Autocomplete all the things
I love oh-my-zsh as well, but I ended up switching to prezto (https://github.com/sorin-ionescu/prezto), which is extremely similar but has less code and is considerably faster. Shell sessions were taking more than a few seconds to start up, and I'm using the latest MacBook Air.
The fact that this shell has Twitter functionality is a signal, and I can't decide if it's a negative signal or not. I've worked very hard to avoid a Twitter capable refrigerator.
I think the means you can use it to script twitter functionality via twitter's REST API.
Seems like a lot of ideas from GNU Emacs and Plan 9 (such as interactive text and evaluating within text buffers) rolled into one, so in that sense it isn't anything revolutionary. Of course it could end up being something nice, but the way the Kickstarter video rubs off on me makes me doubt it.
Sorry but the cognitive load for this shell is just too darn high. I understand the power, I even get close to grok'ing the 'why', but I just don't see how I can intuit all the various features from the app. Do I need to spend a few hours doing a tutorial first? If so: forget it. I don't have time to do that, not for a shell, no matter how fancy it is .. however, if there is a neat and easy and fast way to learn these powerful features built-in, I'll give it a chance. As it stands though, the video just makes me glaze over about 1/5th of the way into it .. I'm impressed by the awesome power, but the load is just too high.
There's at least one use case I want this for: Interactive documentation of shell based programs. As a start, imagine a git tutorial with this thing - beautiful.
The most revolutionist change to a shell. The feature i found very much interesting is "in xiki commands can be run from the notes"
We used to call them shell scripts... I mean, it's not particularly new, only now you have to ctrl+enter each individual command.
I think the OP video's demonstrated use-case makes xiki preferable to creating a shell script.
With a shell script if I want to run some copy-pasta from a blog post or somesuch then I need to edit to remove non-script parts, then I'm flitting between shells to make edits that will work. Then I use the script, and remove it. All just to run a few commands; copy paste, edit in place and ctrl+enter to execute seems far slicker to me (but haven't used it yet).
Xiki looks great for navigation too.
Currently I use bash/dash (Kubuntu) and the greatest change to me has been discovering ctrl+R (surprisingly recently!) and a couple of scripts that I made/modified following a post on HN that make an archive of input commands and enable me to grep it easily.
With a shell script if I want to run some copy-pasta from a blog post or somesuch then I need to edit to remove non-script parts, then I'm flitting between shells to make edits that will work. Then I use the script, and remove it. All just to run a few commands; copy paste, edit in place and ctrl+enter to execute seems far slicker to me (but haven't used it yet).
Xiki looks great for navigation too.
Currently I use bash/dash (Kubuntu) and the greatest change to me has been discovering ctrl+R (surprisingly recently!) and a couple of scripts that I made/modified following a post on HN that make an archive of input commands and enable me to grep it easily.
The visual file navigation looks like it would be a real step down. If I already know the directory I'm navigating to, it would almost certainly be less keystrokes to cd [first letter of first directory]<tab>/[first letter of second]<tab>, etc. If I wanted to visually navigate files, I'd use Finder.
It looks like a good solution to a lot of tedious problems, especially considering navigation.
On the other hand, it seems like there's no boundaries for what problems Xiki should solve.
Where do you draw the line? I would for instance never expect my shell to be able to manage my database. It just doesn't make sense to delegate that job to the shell.
On the other hand, it seems like there's no boundaries for what problems Xiki should solve.
Where do you draw the line? I would for instance never expect my shell to be able to manage my database. It just doesn't make sense to delegate that job to the shell.
Most recent discussion here: https://news.ycombinator.com/item?id=7869246, and previously here: https://news.ycombinator.com/item?id=4512928.
I'm personally keeping my eye on the oh shell [0]. It adds some scheme goodness to the shell without throwing familiarity to the wind.
[0]: https://github.com/michaelmacinnis/oh
[0]: https://github.com/michaelmacinnis/oh
It's cool, but I can't imagine it making my life any better over a Unix prompt. What I really want is a Windows shell that acts exactly like my OSX Unix shell. I did a little look but didn't see anything satisfactory.
Really cool!
A few months ago, I started to use vim mode in shell, for the raw way is not convenient. Furthermore, I have formed an similar idea of "interactive shell", whereas I have to finish my GRE firstly...
A few months ago, I started to use vim mode in shell, for the raw way is not convenient. Furthermore, I have formed an similar idea of "interactive shell", whereas I have to finish my GRE firstly...
Supporting 2 new text editors or IDEs: 4 months (likely Vim and Sublime, but it depends on what everyone votes for - also which one is implemented first depends on the votes)
--> Please all vote for Vim :)
--> Please all vote for Vim :)
For some reason I think I saw some of this in Smalltalk and Oberon.
I like that it can "run" things beside programs. eg URLs, phone numbers. That seems like a good idea other shells could do.
To be honest, a lot of these functionalities really don't seem to fit into a shell but into some sort of a GUI file manager.
This reminds me of the TempleOS HolyC shell.
The first part (filtering/searching/expansion) is pretty similar to emacs's helm/anything.
I need it. Anything similar already available?
Native Oberon.
No, I'm kidding, but Native Oberon is pretty much this as a (research) operating system; the interface is a bunch of text editor panes, you type out commands and run them by middle-clicking on them, commands tend to produce output in the form of further commands you can run, and you can save these panes as files at any time.
It's almost like a generalised version of the core operating system shown in The Mother Of All Demos.
No, I'm kidding, but Native Oberon is pretty much this as a (research) operating system; the interface is a bunch of text editor panes, you type out commands and run them by middle-clicking on them, commands tend to produce output in the form of further commands you can run, and you can save these panes as files at any time.
It's almost like a generalised version of the core operating system shown in The Mother Of All Demos.
I believe this is it isn't it?
https://github.com/trogdoro/xiki
Acme,or Plan9 terminal, EMACS Org Mode
From the brief time I spent with Emacs, I think its shell integration can work like that, but you'll need to write some elisp code to get all the features he shows for xiki.
The video is amazing.
looks like the vim browser with a bash file that can be commented (and run and given to friends).
Great.. Wake me up when it hits 1.0.
It is already at v1.0 (https://github.com/trogdoro/xiki/tree/master). It has been under development for over 10 years.
This comment makes me wonder why he suddenly needs money for it now. Many huge projects started without kickstarter, even if they receive lots of contributions and donations nowadays, they never used to need it.
Hmm, and I remember some post on HN a few months ago about why open source projects should not ask for money/donations in the first place. The crux of it was that they basically become a company then: they work for money. People will expect something for that money, and A) features might be made simply because the developer feels he needs to do something in return for they money he's getting and B) people who donate a lot (i.e. have a lot of money) get a huge say in the project even if their ideas turn out to be horrible in practice.
Hmm, and I remember some post on HN a few months ago about why open source projects should not ask for money/donations in the first place. The crux of it was that they basically become a company then: they work for money. People will expect something for that money, and A) features might be made simply because the developer feels he needs to do something in return for they money he's getting and B) people who donate a lot (i.e. have a lot of money) get a huge say in the project even if their ideas turn out to be horrible in practice.
The TC post includes this quote from Xiki's author. "If this campaign succeeds, the money will let me dedicate the time needed to bring this next, drastically improved, version of Xiki to the world."
Apparently he's looking for about one year's worth of money to work full time on Xiki. Why he didn't do that before, I don't know and it doesn't matter much. But using Kickstarter he's able to be very specific about what one should expect to get as a reward. Example: 35 $ buy a t-shirt and 10 votes for vim or sublime support, no specific features. 2k $ buy a command for your company. He writes "See the Twilio command in the video for an example". So it's true that if you donate a lot you get more. If only companies from a specific domain fund Xiki it could turn out to be a very domain specific shell. However being strong on a vertical market could be a nice strategy. Unfortunately it's out of Xiki's control.
Apparently he's looking for about one year's worth of money to work full time on Xiki. Why he didn't do that before, I don't know and it doesn't matter much. But using Kickstarter he's able to be very specific about what one should expect to get as a reward. Example: 35 $ buy a t-shirt and 10 votes for vim or sublime support, no specific features. 2k $ buy a command for your company. He writes "See the Twilio command in the video for an example". So it's true that if you donate a lot you get more. If only companies from a specific domain fund Xiki it could turn out to be a very domain specific shell. However being strong on a vertical market could be a nice strategy. Unfortunately it's out of Xiki's control.
[deleted]
- Some are extremely slow, especially those that rely on complete webservers / node.js / whatever as a backend
- Memory-hungry. I've got an average of about 30 terminals open at all times. 50 Mb per terminal really is a bit too much. 10 Mb is the upper limit on what a single terminal should ever use.
- Don't work remote. If it doesn't work remotely without installation (and none do), it's pointless to me.
- Don't integrate properly. For instance, copy-pasting is suddenly painfully impossible or unicode fails or it doesn't handle ncurses or escape sequences properly.
- Doesn't add anything that the history and copy-pasting don't already do nearly perfectly.
- Doesn't follow the "Simple things should be simple, complex things should be possible" philosophy. For example, catting large (10mb) log files or a binary file completely barfs it.
I wonder if Xiki is any different, as I haven't tried it yet. It seems unwieldy to use. Why would I want to physically move the cursor to a previous command 50 lines up when I can just do Ctrl-R <part of the command> and be done with it?
This all sounds a bit negative, which isn't my intention. It's just that I've become quite a skeptic when it comes to "(email|shell|editor|etc) reinvented" claims.