Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Xiki: An amazing shell

techcrunch.com

Post reply on HN
Print view View original

121–130 of 130 posts

Re: Xiki: An amazing shell

#121

Post by xorcist »

bkeroack wrote: post #96
skrebbel wrote: post #72

Earlier quoted context omitted.

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…

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 h…

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.

Re: Xiki: An amazing shell

#122

Post by GrinningFool »

Tyr42 wrote: post #114
scott_s wrote: post #112

Earlier quoted context omitted.

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 t…

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 an…

Thanks for that about '$', I didn't know we could rename sessions.

Re: Xiki: An amazing shell

#123

Post by baweaver »

scott_s wrote: post #117
Tyr42 wrote: post #114

Earlier quoted context omitted.

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 an…

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

Re: Xiki: An amazing shell

#124

Post by zorbo »

KhalPanda wrote: post #45
zorbo wrote: post #34

These alternative shells always get me really excited, until I try them out. Then the drawbacks become immediately and very painfully obvious: - 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 t…

Wow, an average of 30 terminals at all times? Just out of curiosity... what for exactly? Real-time monitoring?

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.

Re: Xiki: An amazing shell

#125

Post by barrkel »

simias wrote: post #89
barrkel wrote: post #67

Earlier quoted context omitted.

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'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, pyth…

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.

Re: Xiki: An amazing shell

#126

Post by skrebbel »

Already__Taken wrote: post #88
skrebbel wrote: post #72

Earlier quoted context omitted.

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…

> "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 experie…

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.

Re: Xiki: An amazing shell

#127

Post by BPm »

thathonkey wrote: post #82
BPm wrote: post #68

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

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.

Re: Xiki: An amazing shell

#128

Post by 59nadir »

barrkel wrote: post #67
leorocky wrote: post #8

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…

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.

Which features would that be?

Re: Xiki: An amazing shell

#129

Post by exadeci »

chx wrote: post #3

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.

Well Xiki has been posted several times here and it's the first time it reaches 1st link just St because of TC....

Re: Xiki: An amazing shell

#130

Post by tizzdogg »

KhalPanda wrote: post #45
zorbo wrote: post #34

These alternative shells always get me really excited, until I try them out. Then the drawbacks become immediately and very painfully obvious: - 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 t…

Wow, an average of 30 terminals at all times? Just out of curiosity... what for exactly? Real-time monitoring?

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.

Post reply on HN