Meet Carla Shroder's New Favorite GUI-Textmode Hybrid Shell, Xiki

New submitter trogdoro (3716731) writes with an excerpt from Linux Cookbook author Carla Schroder's enthusiastic introduction to what looks like a tempting tool, combining elements of GUI and text-mode interfaces: Command-line lovers, allow me to introduce you to Xiki, the incredibly interactive, flexible, and revolutionary command shell. I do not use the word "revolutionary" lightly. The command shell has not advanced all that much since the ancient days of Unix. Xiki is a giant leap forward. If you're looking for the Next Big Thing in FOSS, Xiki is it. It's not the first tool meant to combine text and graphic interface, but from the screencast demo, Xiki looks like it gets a lot of things right.

Comments

Oberon?

[K. S. Kyosuke]

It looks a bit like Oberon, only without the live graphics objects goodness. (Although admittedly, the "output right behind the command" is more like Smalltalk workplaces...)

Re:Oberon?

[Anonymous Coward]

if it looked like prince oberon I would be all over that shizz.

Re:Oberon?

[K. S. Kyosuke]

Uh..."prince"!?

Re:Oberon?

[Anonymous Coward]

yes, prince oberon. the character from game of thrones.

Re:Oberon?

[K. S. Kyosuke]

There is no such character in any of the GoT books.

Re:Oberon?

[Anonymous Coward]

So? What's your point?

Re:Oberon?

[Anonymous Coward]

His point is: learn to fucking spell "Oberyn"

Re:Oberon?

[Anonymous Coward]

Oberyn

Re:Oberon?

[ttucker]

His point is: learn to fucking spell "Oberyn"

That is an uncivil response to a simple error.

Re:Oberon?

[K. S. Kyosuke]

Try visiting the front of the White House and yelling appreciatively "I love Osama!"

Re:Oberon?

[Anonymous Coward]

Yes, it is an uncivil response to an ignorant time-waster who replies "So? What's your point" after being corrected and corrected again.

Good thing I have the day off.

Re:Oberon?

[Anonymous Coward]

books?
There is only one GoT book.

Re:Oberon?

[Anonymous Coward]

Welcome to slashdot, you must be new here.

Re:Oberon?

[lonestr]

Given the track record of this administration, you would probably get a cabinet position.

Re:Oberon?

[Anonymous Coward]

Given the track record of this administration, you would probably get a cabinet position.

He said, "I love Osama," not "I killed Osama." Say what you will about the POTUS, his administration will forever have that fact noted in the history books.

The Xiki Wiki

[Anonymous Coward]

is Tricky

Re:The Xiki Wiki

[camperdave]

... but it still won't get you a hickey.

Re:The Xiki Wiki

[Zaiff Urgulbunger]

is Tricky

but worth a clicky

Next Big Thing!

[Anonymous Coward]

That phrase in particular is a pretty serious red flag. It is an obvious attempt to gain publicity and/or investment for something which is nothing particularly novel or new or useful.

If I'm wrong, and the thing is actually practical, please, don't use idiotic tired red-flag buzzwords like that. It turns smart investors off.

Re:Next Big Thing!

[Anonymous Coward]

Yawn; wake me when I can get the code from github.

Did you even look? It takes two seconds of scanning TFA to find the github page.

Re:Next Big Thing!

[dotancohen]

Practical? Take a look:
https://www.youtube.com/watch?...

It looks like it just recognizes bash commands and dumps their output into the text buffer. You can then cut and paste it! You can even 'edit' the output: the example shows `df` returning 22% room free on the disk, and the user 'edits' it to 42%. Sounds practical, no?

For those already on VIM: Prefix your commands with `:r!` and VIM will already do this. Granted, you already need to know that `:` starts a command, `!` runs a Bash command, and prefixing it with `r` will dump the output into the current buffer.

Re:Next Big Thing!

[goarilla]

You can just press !!, and type your shell command in vim to do the same.

Re:Next Big Thing!

[ThePhilips]

For those already on VIM: [...]

I already do something similar in VIM, and xiki is far from been the same as ":r!". You probably should watch the first screencast.

The xiki thing is basically a Ruby shell, with built-in free-form text editor. But primarily it is a wrapper around the Ruby. Thus it limits its appeal to mostly Ruby users and developers.

The concept is definitely interesting. It basically brings back to CLI some capabilities that many have given up to GUIs. Adding something like this to an editor like VIM is definitely possible, but not trivial, since VIM's support for scripting and scripted buffers is very limited.

OTOH the xiki reminds me of what Emacs does to the shell prompt. Unfortunately, Emacs' integration with the shell ends with the repetition of commands and copy-paste from the buffer. Xiki goes a step further.

Re:Next Big Thing!

[dotancohen]

Thank you. I've watched the screencast but I really do fail to see any utility in Xiki, only novelty. Can you describe something that Xiki can do that cannot be done with `:r!`? I would really love to add Xiki to my toolbox if it is useful, but I fail to see that.

Re:Next Big Thing!

[ThePhilips]

Can you describe something that Xiki can do that cannot be done with `:r!`?

I can't. Because I do not use Xiki. I use something much simpler coded in VIM.

But the paradigm as I use it, in VIM terms: the command and the output are kept in the same editor window. You can apply exiting VIM functions to both - commands and output. You can save and load both at the same time - since in the essence it is an ordinary text file. With a special ':g//' I can rerun all the statements in file at once. Or I can selectively rerun only particular ones by the mask. I can ':w' and it is all made persistent. (My small creation was born first as a text file to keep the shell pipelines I use often. But with a VIM macro I have integrated also the output of the commands into the file. And then I given names to the commands. And then I allowed in pipes to refer to other pipes by the given names. After adding folding, it is still mostly looks like a text file with shell pipelines. Replaced bunch of terminals I used to keep open to run small monitoring/diagnostic commands. And a calculator, which I use most often (iow, a text file full of formulas, which I can copy/paste/modify and recalculate).)

Xiki, being a cross of Ruby and a text editor, apparently does more: it recognizes and presents as interactive not only the shell commands, but also the file system hierarchy, the Ruby code, the SQL statements, the CSS, the HTML, and probably more.

Re:Next Big Thing!

[goose-incarnated]

Thank you. I've watched the screencast but I really do fail to see any utility in Xiki, only novelty. Can you describe something that Xiki can do that cannot be done with `:r!`? I would really love to add Xiki to my toolbox if it is useful, but I fail to see that.

If you want something better than :r! in vim, use emacs as a shell. I used emacs as a shell for years - you can cut-n-paste (multiple buffers), use the mouse to mark regions, save the entire session as a file, load a previously used session, search back, search forward, edit previous commands before running them, edit the output of previous commands (and then run them), execute the odd elisp expression (need a calculator quickly? It's built in), surf the web, read/send email, read usenet (or read slashdot), play rogue, elisa, snake or tetris, annotate previous commands, run multiple shells.

You still get all the normal stuff too - autocomplete, file and directory browsing, standard piping to forked processes, set/reset/unset variables, syntax highlighting of your shell, normal edit-compile-debug cycle, etc

(I've heard rumours that there's a text editor included with it too ;-)

Re:Next Big Thing!

[goose-incarnated]

Xiki, being a cross of Ruby and a text editor, apparently does more: it recognizes and presents as interactive not only the shell commands, but also the file system hierarchy, the Ruby code, the SQL statements, the CSS, the HTML, and probably more.

I dunno about the rest, but for filesystem browsing you can use vim :e on a directory which vim will then let you navigate

Re:Next Big Thing!

[ThePhilips]

I dunno about the rest, but for filesystem browsing you can use vim :e on a directory which vim will then let you navigate

Well, you really have to try it first to understand the difference.

Browsing a directory in VIM - ':E' - shows you the content of directory in a buffer. What xiki demo shows is more of ^X^F (because you edit the path right in the editor window, with the rest of your text) but allowing you to actually dynamically run ^X^F on different parts of the dir/file name, changing content of the window accordingly. IOW, while ':E' is a dedicated browser, xiki does something like ^X^F to allow to edit/browse/etc inline, right in the middle of the text file, at any time when you need it.

And that's where the "innovation" comes. The tools to do all the things exist. But they all have different (and typically graphical) user interfaces. Xiki/etc try to combine the tools by putting them into an text editor, and making their output interactive and/or ready to be fed to the another tool. Because despite all the chrome, the basic nature of the content of the editor's window doesn't change: it is plain text. Commands are just text lines. Output are just text lines. It all becomes alive when special macro is run, which looks at the current line and tries to decide what to do with it.

Another way to look at it, and the way I often use my VIM hack, is that the same text file serves dual purpose: it is at the same time the script and the output of the script. The script and its output are interleaved. (That for example allows a very nice minor perk: rerun any command, flip between undo/redo and see the differences between then and now.)

Re:Next Big Thing!

[goose-incarnated]

I dunno about the rest, but for filesystem browsing you can use vim :e on a directory which vim will then let you navigate

Well, you really have to try it first to understand the difference.

Browsing a directory in VIM - ':E' - shows you the content of directory in a buffer. What xiki demo shows is more of ^X^F (because you edit the path right in the editor window, with the rest of your text) but allowing you to actually dynamically run ^X^F on different parts of the dir/file name, changing content of the window accordingly. IOW, while ':E' is a dedicated browser, xiki does something like ^X^F to allow to edit/browse/etc inline, right in the middle of the text file, at any time when you need it.

And that's where the "innovation" comes. The tools to do all the things exist. But they all have different (and typically graphical) user interfaces. Xiki/etc try to combine the tools by putting them into an text editor, and making their output interactive and/or ready to be fed to the another tool. Because despite all the chrome, the basic nature of the content of the editor's window doesn't change: it is plain text. Commands are just text lines. Output are just text lines. It all becomes alive when special macro is run, which looks at the current line and tries to decide what to do with it.

Another way to look at it, and the way I often use my VIM hack, is that the same text file serves dual purpose: it is at the same time the script and the output of the script. The script and its output are interleaved. (That for example allows a very nice minor perk: rerun any command, flip between undo/redo and see the differences between then and now.)

I've used emacs for that (editing 'uneditable' things in the buffer and then re-executing). See my post above - handy link here

Re:Next Big Thing!

[goose-incarnated]

From TFA

Ruby is a wonderful language for [...] mobile devices, like phones, tablets, smart watches, smart glasses, and all the "Internet of things" that the buzzspeakers are so excited about.

It's hard to take a 'reviewer' seriously when they make goofs of such epic proportions, such as these. This blogger is obviously unaware that the IoT devices (along with a lot of the 'smart' devices) aren't going to be able to run ruby crap.

Re:Next Big Thing!

[ThePhilips]

I've used emacs for that (editing 'uneditable' things in the buffer and then re-executing). See my post above - handy link here

OK. You completely miss the point.

Emacs' shell wrapper is just that: shell wrapper. Typing anywhere but at command prompt makes no sense. Command goes at the bottom. Output after it. Command at the bottom. Output. Rinse and repeat. You can't have (a) commands/outputs out of order, (b) non-shell commands or (c) re-execute in-place part of output as command.

Probably you simply never met with such problems so it is hard for you to even realize where from I'm (and apparently authors of xiki are) coming.

Re:Next Big Thing!

[goose-incarnated]

Emacs' shell wrapper is just that: shell wrapper. Typing anywhere but at command prompt makes no sense. Command goes at the bottom. Output after it. Command at the bottom. Output. Rinse and repeat. You can't have (a) commands/outputs out of order, (b) non-shell commands or (c) re-execute in-place part of output as command.

Well, perhaps my emacs is broken then, because it lets me type anywhere and accepts the line as a command upon pressing enter. I can also scroll up and position the cursor on any line in the emacs window and press enter and it will accept that line as a command to execute, even if that line was not a command previously but the output of a command.

Probably you simply never met with such problems so it is hard for you to even realize where from I'm (and apparently authors of xiki are) coming.

I'm afraid you are correct - I simply cannot see anything in that video which I cannot also do using a shell from emacs, and I'm way too lazy to make and post a video of myself doing emacs-as-a-shell. There's a slime video on youtube somewhere that shows the user using emacs exactly as the FA video shows, but with more functionality (and with software from over a decade ago).

Not convinced

[mstefanro]

I believe the tradeoff of CLI is between working more efficiently (by typing commands and not having to use your mouse too often to interrupt your flow)
and a steeper learning curve (learn commands and their params, config file locations and their syntax etc.).

This shell seems to provide a lot of features that most of the people are not interested in, or already use specialized tools for those tasks. It is unclear to me why would one prefer to use such a shell to execute SQL or modify the DOM of a webpage rather than spawn a full-featured querying tool, respectively Firebug.

Their syntax coloring looks pretty poor, and they seem to ask you to "double-click" whenever you want to do anything. I am currently using terminator + fish, which I can highly recommend. It makes me way more productive, has very interesting completion features and uses a really large number of colors to make things more easily distinguishable.

The fact that you can move things around is quite cool, but I don't see any significant advantages, although I've only watched the first ~6 mins of video. Can someone competent perhaps voice his opinion on what does this bring?

Re:Not convinced

[K. S. Kyosuke]

It is unclear to me why would one prefer to use such a shell to execute SQL or modify the DOM of a webpage rather than spawn a full-featured querying tool, respectively Firebug.

Some people are concerned that "traditional" specialized tools have uncomposable interfaces. There seems to be some convergence between this and the Hopscotch interface pioneered by Gilad Bracha. I believe that the aim of both, despite the two being different in approach, is to ultimately give you the tools to make your own (specialized) interfaces on the fly, rather than to force you into having to deal with multitudes of specialized large windows and to constantly "hunt" for UI elements or displays in a lot of noise.

Re:Not convinced

[blue trane]

"the tradeoff of CLI is between working more efficiently (by typing commands and not having to use your mouse too often to interrupt your flow)
and a steeper learning curve (learn commands and their params, config file locations and their syntax etc.)."

Solution: use natural language to tell the computer what you want to do. "Copy myfile.txt to mydirectory." "Change my password from old to new." "Change the file permissions on myfile.txt so anyone can read or write to it."

Re:Not convinced

[Noah Haders]

I am currently using terminator + fish, which I can highly recommend. It makes me way more productive, has very interesting completion features and uses a really large number of colors to make things more easily distinguishable.

you say that your terminal interface makes you more productive, and yet here you are commenting on slashdot. which one is it?

Re:Not convinced

[Noah Haders]

Solution: use natural language to tell the computer what you want to do. "Copy myfile.txt to mydirectory." "Change my password from old to new." "Change the file permissions on myfile.txt so anyone can read or write to it."

first you have to say "OK Google" (or "hey SIRI" if you're a hiptard)

Re:Not convinced

[Anonymous Coward]

The time saved by using a better interface is subsequently wasted^H^H^H^H^H invested in browsing slashdot.

Re:Not convinced

[mstefanro]

I am skeptical to the idea tbh. For commonly used commands the effort of learning them is relatively small and the rewards are great (if I ever had to type "change the permissions such that" instead of "chmod" I would just give up and use GUI) .

Re:Not convinced

[fnj]

Please read Robert Heinlein's The Number of the Beast and then tell me if you still think natural language is appropriate to command computers.

The use of natural language to interact with Star Trek: The Next Generation's computer has an extremely powerful appeal. I read Heinlein's novel prior to the debut of STTNG and I was still impressed by the latter, but my belief in the feasibility of the idea is greatly tempered by the former.

Re:Not convinced

[Anonymous Coward]

Solution: use natural language

Never thought I'd see that phrase.

Re:Not convinced

[ShanghaiBill]

Other advantages of a CLI:
1. You can save the sequence of commands in a script, edit the script, and re-run it later, perhaps on different computers.
2. You can run commands in a remote SSH session.
3. You are learning skills that are applicable across a wide variety of Unix-like OSes.
4. You are learning to use powerful and flexible tools that can be piped together to automate complex tasks.

Re:Not convinced

[Capt.Albatross]

I believe the tradeoff of CLI is between working more efficiently (by typing commands and not having to use your mouse too often to interrupt your flow)
and a steeper learning curve (learn commands and their params, config file locations and their syntax etc.).

For me, the primary benefit of a CLI, when presented by a decent shell, is the flexibility and power of being able to write and run tiny programs whenever it helps.

A CLI not backed by a decent shell is miserable, as was demonstrated by ms-dos.

Re:Not convinced

[Anonymous Coward]

Scotty: Computer? Computer?
McCoy: (hands Scotty the mouse)
Scotty: (speaking into mouse) Hello Computer?
Plant Manager: Just use the keyboard.
Scotty: A keyboard. How quaint.

Re:Not convinced

[epyT-R]

which quickly gets tiresome because of how much text you end up typing.

instead of:
passwd
cp myfile.txt /dir/
chmod 777 myfile.txt

Re:Not convinced

[sootman]

Agree. I watched the "can your shell do this?" video and saw nothing that I would want a shell to do.

He built a shell that does cool things he wants? Great. I could build a shell that does neat things I want it to, but I don't think anyone else would want to download it.

Re:Not convinced

[FuzzNugget]

I believe the tradeoff of CLI is between working more efficiently (by typing commands and not having to use your mouse too often to interrupt your flow)

If they did it right, one should be able to navigate entirely using the keyboard, the mouse being optional.

Re:Not convinced

[fustakrakich]

A CLI not backed by a decent shell is miserable, as was demonstrated by ms-dos.

Eh, doskey made it okay. And what can't be done with a .bat file? :-)

Re:Not convinced

[vtcodger]

Solution: use natural language

Interesting idea. ten to one, you would get a great lesson in how ambiguous "natural language" is. A language that does not distinguish between inclusive and exclusive OR, has no rules for resolving the order/priority of ANDs and ORs when both occur in a clause, and which has a rather cavalier approach to NOT ("Isn't the door open?" is likely to mean "I think the door is open" rather than "Is the door closed?") may not be the ideal medium for communicating your wishes to a box.

Re:Not convinced

[Livius]

Solution: use natural language to tell the computer what you want to do.

Because we all know that all programmers do is follow the requirements document from the client, which never requires any clarification/investigation/analysis/follow-up/etc.

Re:Not convinced

[trogdoro]

You can do everything without the mouse! There's even a text-only keyboard-only equivalent of right-clicking. I rarely use the mouse, but it's helpful when demo-ing, and making it seem approachable to new users.

Re:Not convinced

[phantomfive]

And what can't be done with a .bat file?

Every time I have to write a .bat file, I consider whether it would be more comfortable to stab myself with a fork. After I am done, the answer is always that I'd rather have stabbed myself with a fork.

Re:Not convinced

[Anonymous Coward]

he posted from lynx

Re: Not convinced

[loufoque]

Natural language is both ambiguous and unprecise.

Converting it to a programming language forces you to be specific about what you really want.

Re:Not convinced

[Anonymous Coward]

No, it didn't.
Tab completion made it okay. DOSShell just helped to make things less painful to re-run something that was run in the past. And that's assuming that you already ran DOSShell in the past.
Of course, that didn't come along to consumer-targeted operating systems until after the turn of the century, and by then MS-DOS was just a bundled component of some product named after a graphical interface.
For those who wanted a decent shell before then, JP Software's 4DOS was the best option. Those who had a copy of certain versions of Norton software may have been familiar with this product by the name NDOS. These products provided more functionality and were able to use less of the most scarce categorization of memory.

Regarding what can't be done with a .bat file, the answer is: nothing. After all, a batch file could run LoadLin which could load Linux. However, what couldn't be done without a batch file if you weren't relying on external executable files? A lot. Getting user input comes to mind.

I'm fully aware of what can be done with batch files. For fun, I wrote a virus in batch, targeting a specific computer lab so that the software would spread among floppy disks from one machine to another, infecting both hard drives and floppies. The software even backed up changed files (like AutoExec.bat), and checked for a parameter to run a cleaning subroutine that would restore the unaffected files. Despite such accomplishments, I never felt like Batch was a versatile as, well, anything else I've used, including BASIC. User input and conditions were not easily handled.

Re:Not convinced

[vux984]

first you have to say "OK Google" (or "hey SIRI" if you're a hiptard)

Honestly, all things considered "Siri" is far less obnoxious to say than "OK Google" in my books.

Re: Not convinced

[Anonymous Coward]

> Natural language is both ambiguous and unprecise.

Imprecise?

Re:Not convinced

[brer_rabbit]

I'm all for the natural language approach. I'm holding off til I can say something like "give me a histogram of all occurences of this regex across all files in subdirectory X....". Til that time it's a pipeline of grep/sort/uniq.

Re:Not convinced

[bondsbw]

Interesting idea. ten to one, you would get a great lesson in how ambiguous "natural language" is. A language that does not distinguish between inclusive and exclusive OR, has no rules for resolving the order/priority of ANDs and ORs when both occur in a clause, and which has a rather cavalier approach to NOT ("Isn't the door open?" is likely to mean "I think the door is open" rather than "Is the door closed?") may not be the ideal medium for communicating your wishes to a box.

Humans can distinguish such ambiguous language constructs. For example: "I once saw a deer riding my bicycle." Although there are at least two ways to interpret the sentence, only one makes sense in nearly all contexts. Now since I am able to figure it out, it stands to reason that sufficiently intelligent algorithm can do the same.

Worst case scenario, if the language interpreter cannot figure it out, it does what humans do in the same situation: it asks for clarification.

Re:Not convinced

[Anonymous Coward]

Now since I am able to figure it out, it stands to reason that sufficiently intelligent algorithm can do the same.

The premise of "strong AI." They've been saying that for 50 years. What's the answer? "More computing power!" But all the evidence points to us using the wrong approach.

Re:Not convinced

[Anonymous Coward]

Another one:
5. You are learning skills that will likely be useful for decades.

Unlike GUIs, the *nix shell hasn't changed that much since the nineteen-seventies. [1] [2]

Thanks to the Unix Philosophy [3], the system is more future-proof than other operating systems.
I don't think it would be unreasable to expect it to still look, feel, and work similar in, say, the fifties.

[1] Screenshot of Unix Version 6, released 39 years ago in 1975
[2] This site will let you emulate Unix V6 in your browser
[3] "Basics of the Unix Philosophy"

Re:Not convinced

[stjobe]

Solution: use natural language to tell the computer what you want to do.

It's hard to wreck a nice beach.

Re:Not convinced

[Anonymous Coward]

I was about the say the same thing, when I noticed you had already written it.

Fun book though :-)

Re:Not convinced

[mwvdlee]

I for one am constantly aching for a CLI that can play musical notes. It's an essential feature and one I cannot possibly do without.

Re:Not convinced

[lars_stefan_axelsson]

And also something I came to value when working in industry and developing both cli and GUI admin tools for telecoms equipment:

You can easily document, email and (to a lesser extent) talk about a cli. A GUI not so much. When you've tried to walk someone through finding the hidden option in a GUI over the phone for the tenth time you're ready to tear your hair out. With a cli you can just email some commands and that's that. Documenting a GUI invariably devolved to a lot of screenshots which makes any workflow tens of pages long, instead of ten lines of commands which you then have ample space to explain and comment on. It's also much easier to read and follow along as you're e.g. installing, than leafing through screenshot after screenshot.

Re:Not convinced

[martin-boundary]

Unfortunately, natural language is less powerful than the CLI. The problem is that it is very difficult to express a sequence of instructions in a natural language. Very quickly, you end up with paragraphs full of clarifications, which look very much like legal documents (legal documents are in fact an early attempt at using natural language to express precise ideas - and it just doesn't work very well either).

A CLI is simpler and more regular than natural language, and succeeds in allowing complex instructions to be expressed in few words.

Re:Not convinced

[smittyoneeach]

You probably aren't using enough Object Oriented Programming. I mean, XML. I mean, Agile Methods. I mean, Big Data. I mean, Cloud. I mean. . .

Re:Not convinced

[Anonymous Coward]

But the mouse is faster than the keyboard. So the true CLI tradeoff isn't gaining speed, losing learnability. It's gaining flexibility and composability, losing speed.

Re:Not convinced

[Anonymous Coward]

i'm not convinced either, but for different reasons..

i saw mention of ruby and quit reading right there

Re: Not convinced

[MrKaos]

> Natural language is both ambiguous and unprecise.

Imprecise?

No, (ambiguous && !precise).

Re:Not convinced

[ItsJustAPseudonym]

"Gay bounce, Gay bounce, Gay bounce"

Re:Not convinced

[goarilla]

No cut ?

Re:Not convinced

[MrKaos]

Which is where cygwin comes in. Microsoft sees this and answers it with powershell, which I don't mind actually, and fits in ok with the iterations sh has gone through.

Otherwise you are back to stabbing yourself with a fork.

Re:Not convinced

[MrKaos]

And what can't be done with a .bat file?

Every time I have to write a .bat file, I consider whether it would be more comfortable to stab myself with a fork. After I am done, the answer is always that I'd rather have stabbed myself with a fork.

If someone asks you to write a .bat file you should tell them to go fork them selves into a background process.

Re:Not convinced

[Anonymous Coward]

It has an incredible appeal until you watch the Geordi episodes. Geordi is the power-user who can never get the computer to do what he wants.

Re: Not convinced

[Anonymous Coward]

Wreck ignition is hard

Re:Not convinced

[Anonymous Coward]

The main benefit of a command line is that once you've done something twice you can script it and not have to do it again by hand. I've yet to encounter any GUI tool that lets you do that. (That was a beef I had with Windows - learning Windows was learning chains of click, click, click paths through dialog boxes that often changed between releases of the OS, Visual Studio, etc; but they've made it better with PowerShell since I used to use Windows.) After a while, you build up new levels of abstraction with higher level scripts and don't have to do as much work.

Re:Not convinced

[Anonymous Coward]

The main benefit of a command line is that once you've done something twice you can script it and not have to do it again by hand. I've yet to encounter any GUI tool that lets you do that.

There are lots of GUI tools that allow scripting, e.g. Automator. The key is that while scripting can incorporate CLI commands, it doesn't have to. Scripting is really a separate tool orthogonal to the interface itself.

Re:Not convinced

[Eunuchswear]

Please read Robert Heinlein's The Number of the Beast and then tell me if you still think natural language is appropriate to command computers.

Yeah, avoid that shit, it ends up in incest and worse.

Re:Not convinced

[Eunuchswear]

Time flies like an arrow,

Fruit flies like a banana..

Re: Not convinced

[bill_mcgonigle]

Google makes it clear you're talking to a corporation, Apple forces you to anthropomorphize your machine. Match goes to Google.

Re:Not convinced

[Eunuchswear]

When you've tried to walk someone through finding the hidden option in a GUI over the phone for the tenth time you're ready to tear your hair out.

And it will change in the next version of Gnome/KDE/Windows/whatever-that-apple-thing-is-called-today.

Re:Not convinced

[Eunuchswear]

I for one am constantly aching for a CLI that can play musical notes. It's an essential feature and one I cannot possibly do without.

echo doesn't have an option for that?

Re:Not convinced

[Anonymous Coward]

You too can play music tones from CLI:

1. Download qodem from http://qodem.sf.net/ .
2. Compile it with SDL audio support (on Debian, have libsdl1.2-dev installed) OR plan to use it on the raw Linux console.
3. Create a LOCAL phonebook entry with ANSI emulation.
4. Embed ANSI music (http://www.bbsdocumentary.com/library/PROGRAMS/GRAPHICS/ANSI/ansimusic.txt) sequences in you CLI output.
5. Enjoy 1980's era sine wave tones blasting from your speaker system.

Re:Not convinced

[cant_get_a_good_nick]

I was writing on my notepad when I put the baby in the playpen to calm her down. Then I discovered the pen was not working.

Natural language can be pretty vague. Talk to a programmer who takes down a ISP router with a misplaced semicolon on how strict they can be. Computers are not smart enough yet to do true natural language. When Watson can answer every single question, maybe.

Re: Not convinced

[vux984]

Google makes it clear you're talking to a corporation

Yeah, and that's part of the problem right there. I don't want to be talking to a corp... 90% of what I'd consider using voice for shouldn't need internet. I'd like voice-recognition on, but give it no internet access.

Make calls, answer calls, add stuff to calendar, send a text, look up a contact, etc... nothing should need to go to google.

And I'd be ok adding a keyword "bing" or "google" to any search that specifically needed to go there.

e.g. hey phone, google the nearest chevron west of me... I'd be ok with that.

Apple forces you to anthropomorphize your machine.

I'm actually perfectly ok anthropomorphizing 'my machine'; but it has to be MY machine, operating for MY benefit, and not sending everything I say to someone else.

Match goes to Google.

If anything they both lose.

Is there something out there that just runs locally and that's decent?

Re:Not convinced

[bondsbw]

I'll repeat myself: Since I am able to figure it out, it stands to reason that sufficiently intelligent algorithm can do the same.

Re:Not convinced

[Anonymous Coward]

You're able to figure it out through the use of abstraction, perception, imagination, and context. The notion that an algorithm can be written to duplicate these things is still unproven. We've got AI at the parlor-trick level today.

Re: Not convinced

[Noah Haders]

to boot, you don't actually have to say "hey siri". you can just tell it what to do. I really like siri. it's great for some things, and if you just use it for those things then it's great. I use it all the time to set a timer. hold down home button, "set a timer for 20 minutes from now". Or "set an alarm for 7:30 tomorrow morning". it's much faster to do this than to unlock your phone, open the timer app, etc.

it's also good when I'm walking and want to shoot a quick text message "text Frank I'm running 10 minutes late." This would likely work well in a car if you didn't have to hold the home button.

re local vs. upload to server. I think siri uploads the message for processing anyway, even if it's just a local function like set the alarm. From ZD Net:

The sounds of your speech were immediately encoded into a compact digital form that preserves its information. The signal from your connected phone was relayed wirelessly through a nearby cell tower and through a series of land lines back to your Internet Service Provider where it then communicated with a server in the cloud, loaded with a series of models honed to comprehend language.

Simultaneously, your speech was evaluated locally, on your device. A recognizer installed on your phone communicates with that server in the cloud to gauge whether the command can be best handled locally -- such as if you had asked it to play a song on your phone -- or if it must connect to the network for further assistance. (If the local recognizer deems its model sufficient to process your speech, it tells the server in the cloud that it is no longer needed: "Thanks very much, we're OK here.")

The server compares your speech against a statistical model to estimate, based on the sounds you spoke and the order in which you spoke them, what letters might constitute it. (At the same time, the local recognizer compares your speech to an abridged version of that statistical model.) For both, the highest-probability estimates get the go-ahead.

Based on these opinions, your speech -- now understood as a series of vowels and consonants -- is then run through a language model, which estimates the words that your speech is comprised of. Given a sufficient level of confidence, the computer then creates a candidate list of interpretations for what the sequence of words in your speech might mean.

If there is enough confidence in this result, and there is -- the computer determines that your intent is to send an SMS, Erica Olssen is your addressee (and therefore her contact information should be pulled from your phone's contact list) and the rest is your actual note to her -- your text message magically appears on screen, no hands necessary. If your speech is too ambiguous at any point during the process, the computers will defer to you, the user: did you mean Erica Olssen, or Erica Schmidt?

Re:Not convinced

[goose-incarnated]

Humans can distinguish such ambiguous language constructs. For example: "I once saw a deer riding my bicycle." Although there are at least two ways to interpret the sentence, only one makes sense in nearly all contexts. Now since I am able to figure it out,

No, you haven't.

it stands to reason that sufficiently intelligent algorithm can do the same.

Well, you thought that I meant "I was out on my bicycle when I saw a deer", but what I actually meant was "I was in my yard when a deer rode past on my bicycle". How the hell can you be sure that I meant the former and not the latter?

Worst case scenario, if the language interpreter cannot figure it out, it does what humans do in the same situation: it asks for clarification.

Nope, wrong again - worst case scenario is that the language interpreter does not figure it out, and doesn't realise that it hasn't figured it out!. Best case scenario in case of errors is the interpreter managing to figure out that it got the incorrect meaning.

Re:Not convinced

[goose-incarnated]

I'll repeat myself: Since I am able to figure it out, it stands to reason that sufficiently intelligent algorithm can do the same.

I'll repeat myself too: You haven't figured it out, you're only convinced that you have. How can you know that I'm not saying "All fruit have the same trajectory as a banana?".

Your problem is probably lack of interaction with the real world. Go to court some day and watch proceedings of a trial - there is no such thing that a sentence is "obvious". In even the most trivial of defences the defence attorney is going to argue, sometimes successfully, that a much structured and mostly unambiguous piece of legislation is too vague to apply to his client.

Re:Not convinced

[bondsbw]

What would a human do?

A human would likely recognize the ambiguity, and wait until there's a point in which enough context is provided to disambiguate. For example, "I once saw a deer riding my bicycle. I then slowed my bicycle in order to slow down and see the deer more closely." Or, "I once saw a deer riding my bicycle. But it crashed because deer don't know how to ride bicycles."

If the context is never clarified, the human would probably accept the most reasonable explanation, that "riding my bicycle" was being used as a modifier of the verb "saw" and not as a modifier of the noun "deer".

In cases that it is still unclear, the human would probably think, "Does it matter enough for me to question the meaning?" Perhaps not; the human would smile and pretend to understand knowing it makes little difference.

But in most imperative contexts, it is important to know the difference. The human would ask for clarity.

The computer can be built to do the same as the human in any of these cases.

Re:Not convinced

[bondsbw]

We're not talking about writing laws. Laws are written by one group of people, applied by a different group, and interpreted by yet a different group of people. Imperative commands executed immediately are different because the interpreter can directly interact with the writer, and (again repeating myself):

if the language interpreter cannot figure it out, it does what humans do in the same situation: it asks for clarification.

Re:Not convinced

[Gavagai80]

A computer smart enough to understand natural language as reliably as humans would probably be as intelligent as humans, and it would then be unethical for you to enslave it.

Re:Not convinced

[goose-incarnated]

The human would ask for clarity.

The computer can be built to do the same as the human in any of these cases.

No, it can't. In order to ask for clarity it first has to recognise that there is a 0.00000000000000000000000000000000001% chance of ambiguity. This would result in it always asking for clarity. A human is allowed to make mistakes in comprehension because the producer of the sentence might recognise that there was incorrect understanding. Then again, they might not. The computer doesn't have the luxury of taking the chance that there is no ambiguity.

Put differently - the human assumes that the other human will understand him or ask for clarification. Sometimes they are wrong in this assumption but no harm is done. With a computer: if the human takes the chance that the computer understands him OR will ask for clarification and the computer assumes a different meaning then there will be hell to pay. In essence, what you are saying is "given the sentence 'I once saw a deer riding my bicycle' I want the machine to sometimes ask for clarification and sometimes not, but the machine won't be told in advance which time to ask for clarification and which time to assume non-ambiguity." This is clearly impossible.

TLDR: You're asking a deterministic machine to perform non-deterministic actions; mathematically this is impossible, hence it will never be a reality.

Re:Not convinced

[bondsbw]

Put differently - the human assumes that the other human will understand him or ask for clarification. Sometimes they are wrong in this assumption but no harm is done. With a computer: if the human takes the chance that the computer understands him OR will ask for clarification and the computer assumes a different meaning then there will be hell to pay.

Why? Why does the human get to slide but the computer doesn't?

Re:Not convinced

[bondsbw]

1) Why does the ability to understand natural language have anything to do with intelligence in other areas? A natural language parser won't necessarily have a clue how to track moving objects or how to play chess.

2) What does intelligence have to do with ethics? Saying "Humans are intelligent beings and humans should not be enslaved, thus intelligent beings should not be enslaved", is like saying "Mario is a plumber and Mario is a game, therefore plumbers are games."

Re:Not convinced

[Anonymous Coward]

Why? Why does the human get to slide but the computer doesn't?

http://en.wikipedia.org/wiki/Determinism

Re:Not convinced

[MikeBabcock]

This and lars_stefan's reply are right on. Its amazing how often I've worked my way through scripting a sequence of shell commands that gives me the result I want, then I either save it as a shell script for later, or execute it on a remote machine or send it to a colleague by E-mail with "run this to find out who's E-mail is clogging the pipes" or something.

Re:Not convinced

[goose-incarnated]

Put differently - the human assumes that the other human will understand him or ask for clarification. Sometimes they are wrong in this assumption but no harm is done. With a computer: if the human takes the chance that the computer understands him OR will ask for clarification and the computer assumes a different meaning then there will be hell to pay.

Why? Why does the human get to slide but the computer doesn't?

Because the human is nondeterministic and the computer isn't. A computer, given a certain input, will always respond with a certain output. Humans, dogs, cats and most other animals don't do this. I'm finding it hard to understand why you have trouble with determinism vs non-determinism.

For the input "fruit flies like a banana", the computer must always EITHER ask for clarification OR assume what the sentence means. It cannot do ask for clarification some of the time and not others as a human will do.

Re:Not convinced

[lars_stefan_axelsson]

To be fair, that was a smaller problem in telecoms. We never change anything, in any way, if we can help it. :-)

But I hear ya, and in the general case of course you're as right as can be.

Re:Not convinced

[Anonymous Coward]

Yes, but it doesn't take into account that you can script in a GUI just as easily as in a CLI.

"GUI" doesn't mean "no text ever."

Re:Not convinced

[bondsbw]

I'm finding it hard to understand why you have trouble with determinism vs non-determinism.

Not at all. I just believe you're using it wrong.

For the input "fruit flies like a banana", the computer must always EITHER ask for clarification OR assume what the sentence means. It cannot do ask for clarification some of the time and not others as a human will do.

Why? Both the human and computer can be made to understand context, in order to interpret the likelihood that one interpretation is correct. They both can understand whether knowing the correct interpretation is worthwhile.

The human does have an emotional element, such as being embarrassed to ask the question. But typically the embarrassment lies with whether the human correctly understands the likelihood one interpretation is correct, which is handled deterministically with a computer and thus has no true merit to such situations.

The human can be random. But what good does this do a computer? What good does it even do the human? I'd call this a weakness if people responded differently to what I say, without reason. Besides, the computer certainly can simulate randomness even though there's no practical use for it here.

So no, a computer would certainly not always have to ask for clarification or always not ask for clarification. An example is using "echo Hello World!". The computer could ask, "Where do you want me to echo this input?" But it doesn't because, according to its programming (a form of context) and options (another form of context), it knows where to echo by default.

Re:Not convinced

[Anonymous Coward]

Both the human and computer can be made to understand context

I don't think there's any justification for saying the computer can be made to understand context.

It can be programmed to isolate various possibilities and use various algorithms to weigh the likelihood of each of them, but if anyone has ever made a computer "understand" anything, I have yet to hear about it. That would be big news.

Re: Not convinced

[Anonymous Coward]

> Apple forces you to anthropomorphize your machine.

"Don't anthropomorphize computers-- they HATE that!"

Next Big Thing!

[Anonymous Coward]

You're not wrong. It's just a mockup looking for kickstarter green. Yawn; wake me when I can get the code from github.

And, actually, don't. I'll stick with bash autocomplete, I have no use for over half of the stuff on that promo.

Re:Ho.. hum

[Anonymous Coward]

https://github.com/trogdoro/xi...

trogdoro? someone likes strongbad

Re:Ho.. hum

[Anonymous Coward]

Follow the links to github.

It is available !

The kickstart is for additional work

Re:Ho.. hum

[Anonymous Coward]

There is no Xiki yet.

That's odd... what did I just find here?

Welcome to Macintosh Programmers Workshop, 1985

[buserror]

The "commands everywhere, hit enter to resample them" existed back then for macintosh programmers Workshop, as many developers will remember. Basically there were no need for real 'scripts', you could type commands, hit 'enter' then hit 'undo' and 'enter' again to re-run it, and yes you could 'execute' anything you selected.

That was the only use I had for the 'enter' key of the numeric keypad of the old mac's keyboard in fact.

So, revolutionary... hmmm. I also reimplemented JUST that as a text-input extension quite a few years ago for OSx, where I could do pretty much exactly that from any text editor on the mac, like SubEthaEdit etc.

Re:Welcome to Macintosh Programmers Workshop, 1985

[Anonymous Coward]

I used to love blowing people's minds with MPW when they said silly things like "the Mac doesn't have a command line." :)

Commando was an excellent feature, and when they applied it to A/UX I thought, "someday all Unix boxes will work like this." How wrong I was; they only became more fragmented.

Re:Welcome to Macintosh Programmers Workshop, 1985

[Darinbob]

But go back in time further and people were experimenting with graphical interfaces combined with a CLI. Even the Smalltalk 80 systems could be said to be an integration of graphical interface with a command line (the command line being the "workspace" window). And of course Lisp machines and their combined graphics with a more conventional CLI.

It's sort of like the history of computing is completely blank to people before the introduction of PC and Macintosh. Or maybe it's Babbage and Lady Lovelace, then a missing century where nothing happened, then poof, the PC and DOS appears.

Re:Welcome to Macintosh Programmers Workshop, 1985

[Mostly a lurker]

Believe it or not, using 2260 terminals connected to an IBM 360 mainframe running MVT/ASP, I was able to rerun commands anywhere on the screen back in 1973!

Re:Welcome to Macintosh Programmers Workshop, 1985

[Anonymous Coward]

Yeah, I'm well aware of the precedents... and how few people actually saw them in action.

It's not so much that history was completely blank before PC and Mac, just that it was nearly invisible.

Tell me that you knew about that stuff before 1981, and I won't believe you (unless you were working at Xerox PARC or Stanford labs in the 1970s)

Re:Welcome to Macintosh Programmers Workshop, 1985

[dinfinity]

Or, or: CTRL+R and keyup.

If you take away the mouse in this newfangled interface, I bet CTRL+R and keyup require fewer keystrokes on average than moving the cursor to the command you want to re-run. Granted, CTRL+R and keyup could be slightly less destructive in certain cases, but other than that they're pretty much perfect.

Xiki Sucks..

[Anonymous Coward]

..Because it does not support vim. Also, what problems does it solve exactly?

Re:Xiki Sucks..

[Anonymous Coward]

It smells like hipsters.

Re:Xiki Sucks..

[epyT-R]

yes.. the references to javascript and ruby are dead giveaways. I don't want javascript or ruby anywhere near my command line.

Re:Xiki Sucks..

[ghettoimp]

A pity. Every time I convert a shell script into a ruby script, the world gets just a little better.

Re:Xiki Sucks..

[smallfries]

Also I went through a phase of doing most of this inside vim anyway. It was a time when I was doing a lot of string manipulation in bash with long complex pipelines and I needed to explicitly show the state / track the output of each component.

In vim you just need to keep a :r! at the beginning of each command line, to execute just check that you are in command mode with esc then select the cmd line and middle click to execute, allows piping in results by selecting the input and dropping the r to get :!. There is no support for custom hit regions for the mouse, but in compensation it works everywhere already.

If you already use vim, then having access to vim motions and commands to edit output makes for a surprisingly good shell.

Re:Xiki Sucks..

[iluvcapra]

Also, what problems does it solve exactly?

It is yet another attempt by Rails developers to construct a web app IDE that squares with their idealism.

Too many security issues.

[shellster_dude]

The command placement and directory browsing is cool, but I don't want any command line that accidentally runs things when I click on them. I don't want any command line that tries to interpret my input as multiple scripting languages. Both of those sound like a security disaster.

Onions have layers...shells have layers?

[dacarr]

So, lemme see if I have this right.

This is a new take on a shell.

...which is run from within my editor of choice, emacs.

...which I run in a shell.

...which I run from an xterm, which I spawn in the gui.

Or, maybe, I run it in a browser.

...which I spawn from an icon in Gnome.

I'm not seeing how this is a Good Thing.

Re:Onions have layers...shells have layers?

[jrumney]

...which is run from within my editor of choice, emacs.

...which I run in a shell.

You seem to be confused about the program that emacs is replacing. It is not replacing vi, it is replacing init. Once you realize that, you will find it perfectly natural to run your shell inside Emacs.

Re:Onions have layers...shells have layers?

[dcollins117]

I tried running emacs from the emacs shell and got the error
emacs: Terminal type "dumb" is not powerful enough to run Emacs.

I am somber.

Double clicking?

[Anonymous Coward]

The major selling point seems to be that you can just double click after typing things.
Why would I want that when I can just hit enter?

Re:Double clicking?

[Anonymous Coward]

The major selling point seems to be that you can just double click after typing things.
Why would I want that when I can just hit enter?

Did you watch the video? You can type a command and hit Ctrl+Enter or Cmd+Enter to run it.

Why would I want it to run the command when I just hit 'Enter'? (normally you want that to transmit a newline)

Re: Double clicking?

[Anonymous Coward]

The major selling point is debugging a users problem. Not having them type commands they don't use to do it.

Send them a file. Start a chat.

"Run the first command for me "

"Here is the output"

"ah, try the second command"
"Failed; here's the error"

Your libFoo is the wrong version, I'll get that fixed for you.

don't need, already have emacs.

[SilentTristero]

Emacs does all this, or at least what I need from it, but without the weird interface. Or maybe with a weirder interface.

Re:don't need, already have emacs.

[Anonymous Coward]

Yep. I've been doing most of that for *years* . . . with Emacs.

what if you could....

[Trailer Trash]

nut kick the guy who keeps asking "what if you could...." in the screencast? That got annoying real fast.

Re:what if you could....

[Anonymous Coward]

More annoying with a high squeaky voice

Re:what if you could....

[Anonymous Coward]

Indeed, he kind of deserves it. One of the first "what ifs" involved ressing Ctrl+Enter, which doesn't work via ssh connections - thus xiki is obviously only for local use .Well, it does support remote commands, but you always have to have xiki installed locally, or run it via an X11 - possibly tunneled through ssh.

Re:what if you could....

[Chelloveck]

I can't be the only one who was mentally replacing "what if you could...?" with "why would I want to...?" and coming up dry most of the time.

Not for me.

[Anonymous Coward]

I'll stick with zsh and tmux and being a super awesome typist for now.

Re:Not for me.

[Anonymous Coward]

I'll stick with zsh and tmux and being a super awesome typist for now.

Me too. What is this supposed to be, a command line + extra crap.

What's old is new again ...

[MacTO]

MPW did something similar, only they used their own command set. This had a unique benefit: the output from MPW utilities often included commands that could be executed by clicking on the line with your mouse and pressing enter. It worked very well since the utilities themselves generated those executable commands, and users could extend upon the system with their own utilities. (MPW was a development environment after all.)

Here's the thing though, Xiki cannot do that because its trying to use existing Unix utilities and development tools. While the output from that software is usually intended to be used by other software (e.g. via pipes), it is rarely intended to be used by the shell itself. That means Xiki needs to understand how to interact with each piece of software. As a result, it will end up being an unwieldy mess of plugins and unsupported commands.

Don't get me wrong. The Xiki demos were doing some pretty neat and fairly useful stuff. In that sense, it is a success. The problem is that you'll never be able to use the full power of the metaphor because the software that it interacts with was never designed to interact in the way Xiki needs it to.

Re:What's old is new again ...

[Darinbob]

This was something done with Lisp Machines as well. Symbolics Inc with their Genera operating system combined CLI with the GUI, and you could get a list of valid command options and then either click on the option you want or just type it in.

Re:What's old is new again ...

[trogdoro]

There's a simple metaphor of "text-in, text-out" that xiki stays true to. It interacts with shell commands, scripts, text files, just about anything. You can call a shell command directly, wrap some lightweight code around it let its output be interactive, or wrap a full script around it. > it is rarely intended to be used by the shell itself I'm going to be post a new video very soon showing a new way of jumping quickly back and forth between your standard shell and Xiki, and making them work together, which I think is a missing piece that solves some of the awkwardness you allude to. I wish I'd gotten it out there before this thread!

Re:What's old is new again ...

[Indigo]

MPW - that brings back some good memories. What a great development environment. Crunchy CLI-based power and scriptability wrapped in chewy GUI editing and ease-of-use. I miss using that every day.

Re:What's old is new again ...

[Indigo]

Sounds interesting. Will be on the lookout for it.

Was skeptical, but...

[FuzzNugget]

I was pretty skeptical that this would just be a CLI superfluously decorated with GUI candy, but I ended up being pleasantly surprised. At the very least, this has potential.

Good lord, another shell written in ruby?

[Anonymous Coward]

Didn't we have some poorly written hack job of a shell a while back on /.

Something about a git shell?

http://developers.slashdot.org...

If it involves some crap written in ruby, can we just assume its a bad idea? Also what is it with ruby devs being publicity whores?

Ruby / Emacs hybrid

[Anonymous Coward]

Is something like that useful? Yup. Several systems have provided it in the past.

But this implementation just seems like a mess: a Ruby/Emacs hybrid that hides Emacs?

Re:Ho.. hum

[trogdoro]

Indeed. I looove strongbad/hsr :) Those guys were geniuses, imo.

Re:Ho.. hum

[trogdoro]

Indeed. It's been out there, and I've been doing live demos of it for years. At RubyConf, QCon, Strange Loop, and about 20 usergroup presentations. The problem is the installer sucks, and people are confused by how to start using it, which the Kickstarter is meant to address. I'm going to post a new video showing some progress on addressing the latter issue very soon.

The whole point of a shell

[msobkow]

The whole point of a shell is to not need the mouse. Keyboarding is inherently faster than mousing -- you're using 8 fingers, not one pointer -- especially if you're a touch typist.

Being able to put your commands in a script for re-execution is an added bonus.

Re:The whole point of a shell

[msobkow]

The whole approach reminds me of a "graphical programming" tool for web interfaces that I used a few years back. While I was intrigued to try something new, I soon realized it was the slowest and clumsiest means of programming I had ever used, and just as prone to errors (though not syntax errors -- but those are but a small fraction of the mistakes programmers make, especially with any decent syntax highlighting editor.)

Re:The whole point of a shell

[Anonymous Coward]

The good thing about a shell isn't that you don't use the mouse, it's that you can combine things together, use and and or and if and unless, copy your transscript to another window or to a file (long as you have a blank $PS2), etc...

And you use the mouse all the time even in a normal shell. Copy and paste.

And there's ctrl-enter, although I can't see myself ever using it when there's the mouse.

For me the icky thing about Xiki is having to use Ruby and insistence (to a degree) on running in a terminal emulator. If the Ruby thing is to avoid having to start up an interpreter in a different (and insulated) process every time you want to run a script, shells like rc and es get functions (superset of aliases) and everything from the environment, so an rc within an rc within an rc never feels like a separate thing.

Re:The whole point of a shell

[msobkow]

I can type a copy of whatever I want to paste far more quickly than I can shift my hand to do it with the mouse, or I can use these little features offered by control keys like ^V and ^C. The mouse is a crutch.

Re:The whole point of a shell

[SpaceBuggy]

It's something of a myth that keyboarding is faster than mousing for equivalent tasks - for example, people compare using keyboard shortcuts for selecting, copying, and pasting when they should be comparing selection with arrow keys.

Likewise, if you use VIM shortcuts to jump through the text, you're really comparing a find-and-replace feature which is just as fast with the mouse.

The real speed gains come from using keyboard shortcuts in combination with the mouse - it's not either/or. When you have a bunch of copy-pasting to do, keeping your right hand on the mouse for selection and left on Ctrl+C Ctrl+V is the fastest method.

Re:The whole point of a shell

[dbIII]

I soon realized it was the slowest and clumsiest means of programming I had ever used

I doubt it is as slow as LabView :(
Never go full GUI.

Once you go past anything that can be flowcharted on a single A4/letter sheet of paper you end up with lines crossing both over and under so it becomes a "write only" program that is not easily debugged and difficult for anyone other than the original writer/drawer to understand.

Re:The whole point of a shell

[MikeBabcock]

I remember asking a Mac user years ago why he loved his Mac so much and he said 'because of the keyboard shortcuts, I can work so much faster'.

What if...

[Excelcia]

What if you could have a shell you had to sit out and plan a custom UI for? What if you had a shell that took one of your most excellently trained typing hands away from the keyboard every command or two to make you do stuff with the mouse. What if you had to pay kickstarter money to get this shell rather than stick with existing open source tools?

++notinterested. I'm not even sure why I'm taking the time t

ithkuil

[SgtChaireBourne]

"natural langauges" are too imprecise. Even native speakers often get confused talking to each other. It's just that most people don't notice the back and forth with clarifying questions since it comes "naturally". It seems that for any high level of natural language processing a fully sentient AI would be needed for the interpreter.

An interesting experiment might be to use ithkuil for the UI at first to reduce ambiguity and imprecision. That might make it easier to gauge how much AI would ultimately be needed.

Re:ithkuil

[iluvcapra]

We used to think something like a simple text web search was "too impercise" and you needed a hierarchical organization or semantic web to organize information on the Internet...

When the domain is restricted natural language can be quite sufficient- SHRDLU had a workable natural language system in the 1960s, and the relevant Siri/Android solutions today are quite up to the task of creating and copying logical objects, selection by attribute, transformation...

Selecting files

[kimhanse]

The one thing I have felt that GUI does better than CLI is selecting some files out of others where a glob can't handle the selection. I didn't see anything in the "what if" screencast about that, will Xiki help me there?

Re:Selecting files

[eMBee]

yes, i just saw this in one of the two videos on kickstarter.
it lets you manually filter the output of ls for example.

greetings, eMBee.

Re:Selecting files

[MikeBabcock]

I've only very rarely run into this scenario. Typically a glob can describe exactly what I want to the shell where clicking will miss files.

All files between two dates? easy. All files over a certain size? easy. All files matching a pattern created before a date? easy. All files with a semi-matching pattern in another directory? easy enough. Files created since the last backup stored in the wrong directory who's names match files on the NFS server? easy.

I rarely find a GUI helpful for file selection. Exception: thumbnails for photos.

Oberon

[smittyoneeach]

http://en.wikipedia.org/wiki/Oberon

Commodore

[Lorens]

The "commands everywhere, hit enter to resample them" existed back then for macintosh programmers Workshop

The Commodore interface was like that too.

Oh, hey, someone invented Plan 9

[seebs]

Glad to see that things I was hearing about back in college, and used to experiment with Unix ports of in the early 90s, and which were also found in the pre-OSX Mac dev environment, are being reinvented as though they were new.

Re:Oh, hey, someone invented Plan 9

[BitcoinBenny]

Everything old is new again once enough people forget about it.

Reminds me of iPython notebook

[pieleric]

This reminds me of iPython notebook. It allows to run/re-run python commands and display either text or graphics. You can also insert "formated comments", save a session, and share it. It's now reaching a good maturity, and is becoming a kind of "python" killer apps for scientists.

As a side note, in addition to Python, it accepts shell commands, when preceding them with a !, to it could even replace a normal shell.

just change bash

[Anonymous Coward]

bash is great, but its variables and quoting are a nightmare. it would be nice if you just always had to encode variables in quotes. it would make life a 'lot easier".

What if...

[theshowmecanuck]

you don't have mouse support?

Hurray for CLI improvements!

[lannocc]

I like what Xiki is shooting for and look forward to trying it out. I have a similar interest in finding new ways to interact with a command shell. One such feature would be a shell and simple commands (in the Unix spirit) that natively work with URI resources rather than simply (local) file handles and sockets. My attempts to achieve this over the past 5 years has resulted in what I call IOVAR (hosted on Google Code and iovar.com), a BASH-like shell for the web written in Java and currently running in Tomcat on Linux. It supports a mix of shell scripts and single-purpose servlets, among a mix of any other system commands, to easily chain together processes that work with web resources.

IOVAR works, I've been using it to build a new back-end services and front-end player for our community Internet radio station MT Radio.Net. We'll be launching the new system July 4th!

I'm glad to see there are others that are finding really cool ways to improve our interaction with the PC, and this Xiki looks interesting! Now if I could just complete some more documentation and ease the installation for IOVAR, in combination with the working use cases I've now built, it could turn into something. But I really could use the help! The entire stack is open-source and everything I have written is MIT-licensed.

No kidding.

[binary paladin]

Shell scripts work but talk about awful languages to work in for anything remotely complex.

Doug Engelbart did this in 1968

[marciot]

If you watch Doug's demo in its entirety, you can't help but see the similarities to this new project:

      http://www.1968demo.org/

get fucked you pedantic loser

[Anonymous Coward]

GTFo

How sufficient is 'sufficient' ??

[Anonymous Coward]

I'll repeat myself: Since I am able to figure it out, it stands to reason that sufficiently intelligent algorithm can do the same

Am curious at what you mean by " Sufficient "

Care to elaborate ?

Re:How sufficient is 'sufficient' ??

[bondsbw]

No.

Re:How sufficient is 'sufficient' ??

[Anonymous Coward]

>> Care to elaborate?
> No.

Then we can safely write off your assertion as hand-waving.

"vim support is immature, try emacs"

[Anonymous Coward]

Take it to alt.religion.editors, lady.

              mark, whose personal website proudly proclaims "this site built in vi"