71–80 of 97 posts
Earlier quoted context omitted.
You know it's a pun on conch shell, right? ;-)
That makes it worse. Too many names are based on insider-jokes, too many of it just scares away noobies. posh, I agree, with the other poster, is a fabulous name for something like this
In my opinion, such few-dependency, high-importance tools should linked statically.
Earlier quoted context omitted.
I have a better idea: don't write scripts in shell language at all. They're terrible at basically everything. Instead, use a scripting language, like Python, Ruby, or Perl. They have control flow that make sense, are not riddled with subtle bugs due to legacy and compatibility reasons, and are simply easier to wield. Shell scripts are a maintenance nightmare - even when used for personal scripts. They should be avoid…
shell is incredibly powerful when you interact with tools that use piping. Doing the same in python is much more verbose.
I love the concept, and I am generally happy with how it works. I think it should catch on. Except the damned name. Come on guys , there are already enough crazily named things out there, you didn't have to be another one :(
ehh.. I keep wanting to call it "nosh" or spell it "xnosh" but I'm sure if it catches on people will remember. Plus it's easy to use with a search engine, unlike "Go" or "Rust." I will say I prefer names that can be searched for on their own (e.g. with Go people typically search for "Go lang"). And as much as I love Void Linux, it's better named than all the xbps-* package manager commands.
Anybody switched from fish shell to this? What is your experience? I like fish shell because the preconfiguration is pretty good. Same on xon.sh or config hell like zsh?
Ugh. I have so many conflicting opinions on this question. So, Xonsh is superior in the manipulation of shell objects. I felt super at home changing the shell prompt and configuring/extending the default Xonsh functionality. This is all because it's literally a superset of Python. Fish however, blows Xonsh out of the water when it comes to autocomplete and navigation. Xonsh's autocomplete / suggestions are very very…
I work on fish, and one of the things that the upcoming fish 3.0 contains is a new `math` builtin (previously we shipped a function of that name that just wrapped `bc`).
So your math expressions here are interesting to me, because they work in math (with the caveat that `` is still the symbol for globbing, so it needs to be quoted or escaped):
$ math 0x113e8b3
18081971
$ math '719 * 114679'
82454201
Sometimes I wonder which languages people use for system tools. I mean, it is hard enough that C programs (with dynamic linking) break sometimes, but building a shell on top of Python seems like a particualar bad choice to me (similar to building a package manager with python). In my opinion, such few-dependency, high-importance tools should linked statically.
It's .NET based and very, very different from the sh lineage, but I absolutely love its ability to use objects instead of strings as the underlying transmission medium between "processes". E.g. ls gives you file descriptors, ps gives you process descriptors, etc.
XonSH has been my main shell for a solid two years now. The concept is awesome, but unfortunately it has many flaws. * Nesting bash and python scripts makes performance terrible compared to using python's subprocess module directly. I have a xonsh script at [0], with an equivalent written in straight bash. The python scripts ends in less than a second, the xonsh script takes ages. - As a sub-problem of the above: You…
I use zsh daily but type `xonsh` any time I do something in the shell that would normally require a google. “Uh ok so I have this JSON file. When I pipe this to `jq` I forget: to pivot an array of objects to an object keyed by array[x].id is it like `to_entries` then chain it to `map`? Uhh let’s look at the docs...” However in Python I can write that function at the speed of thought. It may be a couple more lines of…
Bash has a lot of pitfalls, but once you learn how to deal with them, it can also be quite superb for some tasks. Piping the output of a complex set of loops into GNU parallel and watching your computer process stuff at blazing speed is a very nice experience. Doing the same in python would be many time more verbose.
Sometimes I wonder which languages people use for system tools. I mean, it is hard enough that C programs (with dynamic linking) break sometimes, but building a shell on top of Python seems like a particualar bad choice to me (similar to building a package manager with python). In my opinion, such few-dependency, high-importance tools should linked statically.
XonSH has been my main shell for a solid two years now. The concept is awesome, but unfortunately it has many flaws. * Nesting bash and python scripts makes performance terrible compared to using python's subprocess module directly. I have a xonsh script at [0], with an equivalent written in straight bash. The python scripts ends in less than a second, the xonsh script takes ages. - As a sub-problem of the above: You…
I use zsh daily but type `xonsh` any time I do something in the shell that would normally require a google. “Uh ok so I have this JSON file. When I pipe this to `jq` I forget: to pivot an array of objects to an object keyed by array[x].id is it like `to_entries` then chain it to `map`? Uhh let’s look at the docs...” However in Python I can write that function at the speed of thought. It may be a couple more lines of…