for example (| is the cursor and everything after it is grey text)
>echo hello world
hello world
>echo |hello world # alt-f
>echo hello| world
Fish and oh-my-zsh both take about 5 seconds to init though. If you don't like that you should be using prezto (which is the fork he mentions in the article)
You must have a lot of expensive stuff crammed into your config.fish file, for me fish takes < 1 second to init.
Oh-My-Fish[0] is the preferred and popular plugin framework for Fish. The guy behind Fisherman abused DMCA to discredit OMF, which was a pretty shady tactic for an open-source project.
Greatly disagree on the fish startup time, for me it takes approximately the same time as bash. Can't comment on zsh though.
The intro to this article is as much a caution of becoming dependant on non-standard tools, as it is a pitch for omzsh. If you can't sit down at a normal bash window and get shit done, your shortcuts are hurting you.
There's no shame in customizing shortcuts. Isn't that the entire point of emacs?
Customize all you want, but don't become dependant on your customizations.
I find that I mostly use systems that I can make match my setup...
I don't see a problem with any of those as long as you have a mental model of how the 'shortcuts' you've configured work.
That said, if a tool gives you a net productivity boost, you should probably adopt it. I'm pretty sure I was working with Robby when he started down this road. (Hi Robby!)
And when you ssh into another machine, or have to use a different machine, well you're just as slow as other people using no config at all.
Over time I've customized my bash config and have all the information I want in my prompt. If I ever switched to zsh I'd just learn how to translate what I have in bash. Why would I want to start with someone's big framework for configuration?
It's meant to give you a lot of sensible (think like vim-sensible) defaults as well as the settings that make it feel more like bash yet show the awesome features of zsh.
A lot of people don't like to configure shells. omz gives them a head start and a source of inspiration into features they might not know.
I've never been much of a tools guy. I generally use what the default configuration is for whatever tool I use. It's just never been particularly important to me (and I don't feel like it's made even a small difference in my productivity as a programmer).
Projects like oh-my-zsh are nice because they provide a much richer default that lazy folks like me can use without ever having to know or care about how to actually configure a shell because the alternative is that I just won't do it. I'm not going to take the time to learn about the universe of configuration options. When I'm exposed to a feature it has to be really useful before I'm going to bother to learn about how to configure it. So plugins and the like are huge, they allow me to tailor my environment to the actual work I do with rich functionality that I otherwise wouldn't have.
So for me projects like this are awesome.
Edit: to clarify what I mean by the distinction being artificial, I don't see why you couldn't think of the kernel as someone else's configuration for your processor, or zsh itself as someone else's configuration for your terminal window.
My test for "bloat" –
1. Has the project grown so large that it's starting to run into real-world performance issues? (I can't imagine this could be the case with even the largest of shell configurations except on very low-end embedded devices).
2. Has the project grown so large that bugs are popping up faster than the developers can do maintenance? Is there no or only one person who can read and understand the entire codebase? (AFAIK, no and no).
3. Are there many undocumented/poorly-documented features? Are there features that are both undocumented/poorly-documented and dangerous? Are there many deprecated or outdated features that have yet to be removed? (AFAIK, no, no, no).
4. Are there many features that both duplicate and do not improve on functionality found elsewhere? (Debatable and mostly subjective).
oh-my-zsh is noticeably slower than prezto on multiple 'high end' machines I have with the same 'capabilities', i.e. plugins that provide the same feature set on both.
Software that's prone to be subject to (arguably!) unfair charges of bloat includes old standbys that have lately been challenged by upstarts (e.g. jQuery, Apache), or that developers already dislike for reasons other than quality (e.g. Oracle, Microsoft products).
---
[0] I'll demonstrate by applying my tests as I see it to everyone's favorite poster child for bloat – the C++ programming language.
Has the project grown so large that it's starting to run into real-world performance issues?
Compilers have, and how. The binaries they produce mostly haven't, although certain language features, particularly amongst those that didn't come from C, compare unfavorably to their equivalents in "slower" languages. And the language has become complex enough as to be pretty slow on the meta level of writing or learning it.
I'll say ambiguous, leaning fail.
Has the project grown so large that bugs are popping up faster than the developers can do maintenance?
Well, the invalid pointer access meta-bug has been around for (CURRENT_YEAR - 1972) years...
Personal view is it doesn't matter if the reason for failing this test is because the maintainers place artificial restrictions on their ability to fix stuff, so I'd say fail on this one, although others might disagree.
Is there no or only one person who can read and understand the entire codebase?
Hard to define in this case. Is it the standard? The most popular compiler? Every popular compiler?
I'll say ambiguous, leaning pass. But few programming languages would pass this completely unambiguously.
Are there many undocumented/poorly-documented features?
"undefined behavior"
FAIL
Are there features that are both undocumented/poorly-documented and dangerous?
"undefined behavior"
FAIL
Are there many deprecated or outdated features that have yet to be removed?
FFFFF AAAAA I L !!
F A A I L !!
FFFF AAAAA I L !!
F A A I L
F A A I LLLL !!
Are there many features that both duplicate and do not improve on functionality found elsewhere?[Dig trenches, commence C vs. C++ flamewar]
---
In conclusion, yes, C++ is bloated.
This. The key to using Emacs well is to start with something fairly basic. Whenever you find some behavior that annoys you, take a few minutes to figure out how to fix it once and for all in your config. After a few years you will end up with a giant mess of a config that makes Emacs behave almost exactly the way you want, which you can copy over to any machine where you do serious work. You will also be able to get basic work done in a vanilla `/usr/bin/emacs`.
FWIW, after several years of zsh, I've been mostly happy with a stock fish in a terminal. It's way less broken by default than either zsh or (ugh) eshell.
I've been using basically that config ever since.
When I first started using zsh I went down the road of writing custom completion functions, but pretty quickly discovered that they just didn't pay off in the long run and stopped doing it. My shell absolutely doesn't take 5s+ to open up either, it's pretty much instantaneous.
In bad news, it appears Ubuntu no longer ships the manpages for zsh and instead ships info pages. Barf.
I actually find it valuable to nuke my bashrc customisations every few years and reevaluate. Assumptions and practices entrenched in those customisations can be anti-patterns or counterproductive.
Aren't you already doing that when you load up a vanilla zsh? Its just that that "somebody else" was the guy that wrote the tool. In either case, you still will want to tweak it to get exactly what you want.
However, in one of the cases, the thing you start out with is 0 features, and an extra week of work doing the same thing that thousands of people have done exactly the same before you. Only after that do you get to making it really "custom"
If you're worried about the project stagnating, why don't you offer to donate some cash? Why not offer to help in whatever way you can, even if it's just triaging tickets?
As it happens, I am probably in the running for worst/poorest developer on HN, and that's using the term "developer" broadly. To the degree that I have any resources that aren't being put towards subsistence, I'm not sure I could help anyone with anything. It doesn't feel particularly good to have to explain that, especially since everyone on here seems to be in a vastly different social situation, but either way, I'd appreciate fewer personal reflections.
[0]http://joshldavis.com/2014/07/26/oh-my-zsh-is-a-disease-anti... [1]https://www.bountysource.com/issues/102375-move-plugins-to-s...
Personally, I just built my own zsh config that solves my problems without all the framework mess. Its less than 150 lines + some related dot files for aliases, vim, etc.
> This wouldn’t my first foray into open source software;
> nor my last.
I know that I'm annoyed perhaps too easily by poor grammar - but the opening sentence, really?!I used to work on a fairly underpowered ARM5 and I could feel the impact of most prompt customisations on the speed of the system, especially on initial login. That feeling is still there - mainly because I haven't found the right SD card for my Raspberry Pi.
To avoid this becoming a complete ramble - are there any advantages to switching to zsh as someone who's reasonably comfortable with bash? Hell, even OS X switched (and boy, t/csh was a shock when using FreeBSD).
Try these things in bash (with completions installed):
1. cd to a git repository and type "git [TAB]". Do you see a list of git-specific completions?
2. cd to a directory that has a makefile and type "make [TAB]" do you see a bunch of make targets?
3. cd to a directory that has some PDF files and some other files. Type "okular [TAB]" (or whatever you use to view PDF's. Do you see just the PDF files as completions?
4. Same as 3, but try other programs like python, perl, etc. How well do bash completions keep up with zsh completions?
I'd be very surprised if bash supports completions for programs that zsh has missed.
In general, switching from bash is very easy. Your muscle-memory from bash transfers very well to zsh. You may want to change the prompt to look similar to your bash prompt, so you'll feel at home. Translating my bashrc and bashprofile took just a few minutes.
I tried oh-my-zsh and it did not feel right for me. If this is the reason you're switching, all I can say is that zsh offers benefits even without it.
No, annoyia be praised. It must be when the user has focused for longer then 5 Mins on something.
Periodic automated arbitrary code execution from a remote source.
Here is a list of the stupid ideas that old coders warned from
- abritrary remote code execution [X] this, curl|bash
- too much dependencies [X] npm
- lack of specifications, staging [X] Agile
- non deterministic HW [X] Intel
- non deterministic software [X] llvm/gcc/AI
- Single point of failure [X] github/CA
- attack by majority on P2P [X] blockchain, bitcoin
- bigger sloc is more bugs [X] heavy frameworks
- using immature technologies [X] haskell
- bloatwares [X] angular
- private corp standardizing [X] QUIC & al, browser wars
- beware of information entropy [X] big data
- moving parts [X] the Cloud
- higher surface of vulnerability [X] IoT
- monopolies [X] google
- using private cie for infra [X] github is the new sourceforge
- putting half backed std in prod [X] IPv6
- lack of consistency [X] most nosql tech
- legal risk due to IP law [X] coding by copy/pasting
If I was an old coder still coding I would say we are very close to a singularity : the total lack of trust that could result in all this is simply customers reverting to fax, teletypes, snail mail... or going to court to ask for financial compensations.If you need an expert to help you on this, I can help.
[0]: https://github.com/grml/grml-etc-core/tree/master/etc/zsh
http://i.imgur.com/3FKaEIy.png
It's incredibly easy to set up, I have a script to do it[1] but doing it by hand is trivial.
[1]: https://github.com/beefsack/bash-powerline-installer/blob/ma...
Not oh-my-zsh. It was top trending for the Shell category, not for all of GitHub.
Customization is nice but I guess I mostly prefer to spend as little time thinking about shells as possible.