Re: problem with zsh and wildcards in scp commands
❤️ Click here: Zsh no matches found scp
Autocorrection is just one of the only things that, in my opinion, don't work well, so it's strange to market them. Yes, the syntax is non-compatible, and not even POSIX. Maybe I dumbed the post down too much, was just listing a few features that I use every day that IMO work better then the comparable Bash features.
That describes a lot of people using shells now. Yes, I just use the builtin's. It's happened so often to me that I wrote a script to reconstruct my history file by combining the last handful of backups. In zsh this throws an error instead.
Re: problem with zsh and wildcards in scp commands - The pre configured setup of oh-my-zsh is a nice starting point. If your primary job is to be a sysadmin, then Bash is Required Reading.
While from what I have read about it zsh is a nice shell, it doesn't deal with what I find to be the biggest problem with bash, sh, and just about every shell that isn't fish: the horribly ugly and inconsistent syntax. I have been using fish for several years now. It's a modern shell, that uses colors, UTF, and processing power that didn't exist when the others were designed. I feel the best thing about it is the sane defaults and large number of prebuilt completions. For any other shell, I have to dive into bashrc's and esoteric commands to get what I want. Fish just does what I want. It's made me far more productive, and for that, it gets my best shell award. Its scripting support is good, very similar to other shells. Yes, the syntax is non-compatible, and not even POSIX. But, it makes more sense. Besides, for anything except the simplest of scripts, I use lua. I doubt you'd want to use bash to do something very complicated. Some people want their shell scripts to be compatible and do a lot of cool things. I feel that the days of a shell being used for scripting are past. For me, a shell is a way of interacting with the system. Fish does this really well. Scripting is a slight afterthought, as it should be. I do minimal system administration, so that is not a concern for me. I tend to use a shell for system interaction more than scripting. In that regard, I give more importance to interactivity enhancements. On the other hand, I have found myself using bash to automate simple things in our company testbed. As soon as I need a datastructure more than an array, or recursive functions, I jump to lua. If your primary job is to be a sysadmin, then Bash is Required Reading. As a programmer I can represent inputs and outputs as text and write code to do intended transformations. As a quick ad hoc test I can easily knock up a shell pipeline to give confidence in those results, even if it would be too slow for production. There's many occasions when powerful shell usage is quicker to write than Python, etc. My comment in reply to is one example. I tried out fish a month back, but got stuck on 2 things, one which i use frequently. I use the Alt-. I asked on reddit, but got no replies. It is a history feature to get the last command. It's like using '! Yes, I just use the builtin's. Popen is not the greatest because you can't get exit statuses from it. But for a quick script that is too messy in shell, it suffices. I believe that there is an extension to lua that has a popen that returns exit statuses. That can be used too. For pattern matching, I either pipe to perl and capture the output, or use the inbuilt pattern matching system. This might be one reason fish isn't more widely used. That describes a lot of people using shells now. Once you learn the zen of shell script, like any programming language, those problems pretty much go away. Shell script is a tiny language packed with features and can be learned through constant use in a week, but like any language, it takes time to master. It's incredibly powerful for interactive use and data manipulation combined with the standard Unix tools and sometimes pulling out perl or python is more work than just banging out a pipeline on the command line. Quoting does take some time, but just remember that when in double to quote your variable expansions with double quotes. There's more too it, but that's a good rule to start with. I reccommend ksh over bash. That's all I use these days. It was sh done right, although it does have a bit of history to it for compatibility. Edit: forgot to dereference column when setting value in table. One of my favourite aspects of rc is the sane array handling. And then you have to quote it in case one of the elements has spaces. For this reason rc doesn't even need double-quoting; it only has single-quoting for escaping spaces in string literals. The rc example is worse than the first of yours. I hate the zsh special syntax in the second: it violates a deeply ingrained code feel I have about the syntax of shell code. The semantics of rc's expansion is much less thorny. I prefer real examples - here, why not just write seq 1 100 - what is the loop for? And shell loops can frequently always, if you are willing to write helper scripts be replaced with xargs, which tends to be very much faster, e. It's just the 'test' command. But it's small enough to keep in your head, and I find that makes it far more pleasant to use. The thing I like about fish is the easy history nav. I'll often remember I typed an svn command three weeks ago, but forget the parameters, and I'll have it back within 15 seconds. Init scripts are about the only shell scripts I write anymore, but I use frequently use it from the commandline, typically on remote terminals. I have long lived terminals open, each dedicated to a specific purpose. Shared history would intermingle them. Certainly there must be some advantages to ZSH, but you haven't listed any yet. Note that I didn't have to configure any of this. Ubuntu probably did, but I didn't. Fwiw on 3, it's not the same at all. Your feature comes from Ubuntu, not bash 2. More importantly, in ZSH if the correction is accepted by the user the command gets executed with the fix without any manual redoing. The correction can even be made permanent for frequent typos. GRRR Shared history in zsh is essential to my workflow. I also keep many terminals open, and while I do separate them by task, I often just pick one which happens to be in the right directory and start typing away. I always search through history using Ctrl-R, and almost never use up-arrow cycling. Shared history makes this work seamlessly. This is obviously configurable, so if you prefer a different workflow, zsh will accomodate it. Zsh use's zle Z-Shell Line Editor , which is different then libreadline as its part of the shell not a separate library. Zle's behavior is editable through your. Maybe I dumbed the post down too much, was just listing a few features that I use every day that IMO work better then the comparable Bash features. Shared history can be either a burden or a godsend, I like it but I usually just end up using whatever basic bash shell I'm on without a custom config as most of the things I do are remote. The zsh autocorrect works much differently than what you have given. Where you may be able to type gut status and get No command found the setup in zsh would allow either for gut status to be autocorrected to git status or would ask you if you meant git status while waiting for a confirmation. Zsh has knobs for shared history. You can configure all terminals to have the same history at the same time, but I have it set to add history to the. So ctrl-r in a shell lists commands entered into that shell or preexisting when it started , and opening a new terminal starts with the shared history from all terminals. This is really the best of both worlds. This comes in handy sometimes in simple scripts. Zsh is significantly faster. Zsh autocomplete is much more advanced. It also runs --help and parses out GNU style help text for completing options. I think you can actually make bash do this but it's some obscure key binding. edit: oops meant to reply to grandparent im pretty sure bash does shared history if you desire it, the configuration is just not as directly obvious. I prefer a long histfile unlimited really, i. It's happened so often to me that I wrote a script to reconstruct my history file by combining the last handful of backups. I still haven't figured out how the history file gets trashed though :- Edit: Since I'm in ZSH company, here's the script: These are the history setopt's I have, but I don't know if they all make sense with each other though. I set it up once and haven't touched it in years. Being prompted if I meant 'git' when I type 'gut' interrups my thinking flow, while 'command not found' doesn't. That being said, I'm a happy zsh user, for all it provides. Autocorrection is just one of the only things that, in my opinion, don't work well, so it's strange to market them. I like the idea, but I'm too used to bash's autocompletion the Emacs-provided autocompletion is similar but not quite the same , the autocd option, CDPATH, etc. And changing directories in the shell with anything other than cd pushd, or an alias or script confuses Emacs's directory completion. The last couple of days I've been trying terminal-mode rather than shell-mode, and it works much better. Many standard Emacs keybindings get remapped though. Zsh was never part of a commercial Unix, so I suspect you are thinking of Ksh. As far as I can tell, Zsh has always been free software: the earliest version I could find used the GPL, but it now uses something more MIT-like. I just spent a bit of time yesterday tweaking information in my prompt just so: And it's made a huge quality of life difference to what I had before. Worth spending a bit of time making your shell environment optimized for yourself though, and not just copying someone else's setup, in my opinion. You spend a lot of time there, programming for UNIX, why not make it rock? I used to use a lot of zsh at work, and one thing that drove me nuts was overzealous wildcard expansion. It probably got fixed since then, but this raw frustration is my most vivid memory from zsh usage. This behavior can be turned off by adding this to. The pre configured setup of oh-my-zsh is a nice starting point. Thanks for the article and your response here. I tried that and about a million other things in Ubuntu. When I hit tab I see options, but nothing I put in my. I am using oh my zsh but I tried turning it off and it didn't seem to matter. Maybe only Mac users use zsh? Due to the poor spelling and grammar, gross oversimplification of zsh's advantages, and the inclusion of oh-my-zsh as a reason to switch, I found this post insulting as a long time zsh user. And I actually want more people to use zsh, because that would mean more collaboration, more tips, and better script compatibility. This post was intended as a nice introductory shoutout to Zsh. Oh-my-zsh is a great way for someone to get started with zsh if they wanted to try it out. It was never meant to be a complete guide to Zsh, and I wasn't going to list all the features, just a few that people who don't know anything about Zsh might be interested in. But Hey, thanks for trying to give me a hard time. When you submit an article that you wrote to HN you could at least have the decency to spend 5 minutes proofreading it, couldn't you? I never said I expected you to list every feature. That's a pretty ridiculous hyperbole on your part. I was merely expressing my opinion. I'm sorry that you can't handle any criticism. Perhaps the purpose of this article is too complicated for your oversimplified brain. Grouchy taking the time to outline some of the finer things zsh has to offer. If you REALLY wanted people to adopt zsh, and grow the community, you should probably try to list some other things that you enjoy. But Hey, thanks for trying to integrate yourself. I suppose having and stating an opinion that isn't kissing someone's ass makes me a douchebag according to richardlblair. I think I can live with that. Grouchy did was give a couple examples of completion and oh-my-zsh. I think you would have to be really fed up with bash or whatever default shell your system has to take that bait. I never said I expected him to write a complete job. I just think there are better arguments to be made. In fact, there are hundreds of posts on HN that give someone's evangelical tale of trying a new program, and several about zsh. This one is far from exceptional in my mind.
No matches found!
Bash, on the other hand, passes the unexpanded glob to the app, which is a potential zsh no matches found scp if you don't know for certain what will match or if you make a mistake. Besides, for anything except the simplest of scripts, I use lua. Here, calling rm when the glob doesn't match is wrong. And then you have to quote it in case one of the elements has spaces. By default, if a command line contains a globbing expression which doesn't match anything, Zsh will tout the error message you're seeing, and not run the command at all. But for a quick script that is too messy in shell, it suffices. While from what I have read about it zsh is a nice shell, it doesn't deal with what I find to be the biggest problem with bash, sh, and just about every shell that isn't fish: the horribly ugly and inconsistent syntax. I tend to use a shell for system interaction more than scripting.
