- 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.

> - 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. :/

To keep track of what I need to do in the short term, I have a simple TODO text file.

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.

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.

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.

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.

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

Maybe it would be prudent to try it first, before commenting..

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.

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.

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.

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 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.

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.

For the unfamiliar this video by Russ Cox covers it pretty well. http://research.swtch.com/acme

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.

:|

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.

  def name(text):
    return lambda file: file.name.find(text) > -1

  ls().filter(name('.txt'))

You probably think of type-safe pipes similar to Go channels.

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.

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).

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.

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.

1: http://blog.verbum.org/2008/03/23/hotwire-hypershell-0-721-r...

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...

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.

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.

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.

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.

Concerning Xiki, it definitely remind me of Emacs org mode / shell.

I don't like fish because it has almost no features, compared with bash.

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.

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.

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.

Which features would that be?

[0]: https://github.com/fish-shell/fish-shell/issues/1374

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!

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.

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.

Although since I use OS X (Darwin) I don't always need the mouse to copy+paste (ie. pbcopy -> cmd+V).

There's also one more situation where we need the mouse: selecting a specific text on the console to copy & paste.

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

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.

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.

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.

[0]: https://github.com/michaelmacinnis/oh

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...

--> Please all vote for Vim :)

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.

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.