It turned out to be an issue with cookies. I deleted all my cookies for wired.com and then it worked. Strange, because the front page of the site showed but not the article.
Most of Chinese think Yuhuangdadi(玉皇大帝) and Wangmuniangniang(王母娘娘) are husband&wife, they work together to control all the gods(gods are not like western gods, they have 仙 and 神), but there are multiple versions of myths(books) and rumors mentioning them, none of them tells the relationship of them for sure, we can only deduce their relationship from the context. From different versions of sources, they can be: 1. husband&wife, 2. colleagues, 3. sister&brother, 4. mother&son.
I love fish-shell, but after years of using it I switched to Oh My ZSH!. The bash compatibility makes it a whole lot easier to use when you're the type of person who has to look up "how to do X on the command line" on the internet more often than you'd like to admit (that would be me).
But the whole reason I use fish is because I DON'T have to look things up on the internet because it uses sane syntax instead of some arcane combination of brackets, symbols, and the word “if” spelled backwards.
fwiw, we are shipping a number of features in fish 3.0 (any day now!) that are specifically targeting at maximizing compatibility with most bash scripts (still not POSIX).
That includes support for && and || and a few other things that should go a long way towards making most code you find drop-in ready.
Really? Doesn't that go against the stated fish design document and ridiculousfish's intention for fish?
I'm more concerned about making fish scripts work well than making fish run bash scripts. (Maybe fish 3.0 will improve that too.) I've tried to use fish for writing somewhat serious scripts several times, and I've always run into frustrating problems that sent me back to bash for scripting. Fish is an excellent interactive shell, of course.
You can see the discussions on GitHub but @ridiculousfish authored that series of commits fwiw.
However with regards to your other matter, I personally just finished rewriting the job control code to close out a lot of long standing bugs affecting correctness and child process behavior in complicated scripting cases, and other members like @faho have done an amazing job fixing up some of the builtins and scripting-related improvements as well as putting in insane effort into the interactive behavior of the shell and its insane library of completions.
Try the current fish master builds and see how if fares. If you have any specific concerns, please file a GitHub issue. It’s an open source project and it can only succeed with the help of the entire community.
fwiw I find the sanity fish brings to process substitution with sane tokenization and automatic escaping of shell substitution output to be a huge boon to productivity over writing in (ba)sh. These days, my scripts are either written in ninja or bmake if they are rule/output driven or fish otherwise.
Thanks for the updates. I have contributed to related discussions on GitHub for several years, but I haven't been able to keep up with all the issues.
> fwiw I find the sanity fish brings to process substitution with sane tokenization and automatic escaping of shell substitution output to be a huge boon to productivity over writing in (ba)sh.
I completely agree, this is why I would much prefer to use fish for scripting when feasible. I'm glad to hear that the scripting is being improved.
I also love zgen and used to use some parts of OMZ with it. But after debugging weird issues a bunch of times and always finding a funny opinionated config in OMZ I changed everything to Prezto. Zgen supports Prezto natively.
that would rather defeat the point, since fish breaks compatibility by design, that's part of what i like about it.
i can however appreciate that breaking bash compatibility is not for everyone.
i mix use of bash and fish. but more often than not i find myself in a situation where i switch to fish because it makes some complex command easier, than the reverse.
There are a few plugins you can use with oh-my-fish and similar tools, for example `fish-foreign-env`, which provide a command (`fenv`, in this case) which runs a given command in bash and then transfers environment variable changes to the fish environment from which it was called.
It's not bash compatibility, but it is good enough for one-offs and even for many scripts and tools that expect to be sourced in your dotfiles from bash.
I'm in the same boat as you. Also used Fish for several years and loved it, but there's some incompatibilities here and there (dont remember exactly what, I think it was difference in how to pipe streams vs bash/zsh).
In the end i switched to zsh & oh-my-zsh and haven't run into issues since (made the switch maybe 6 years ago). I'm a heavy terminal user so this part I'm not experimenting with again.
There is something wrong with the `eshell/x` function, if start `Ctrl-!` in scratch buffer, after execute `x` in eshell prompt, there will `Wrong type argument: integer-or-marker-p, nil x` in scratch buffer; if I start `Ctrl-!` in init.el, there will be `Marker points into wrong buffer: #<marker at 955 in scratch> x` in my init.el file.
I'm Chinese. The most confusing thing for me between English and Chinese is the number. English number is seperated by comma every 3 digits (thousand, million, billion)，no matter in formats like 3 billion or 100,000,000, but in Chinese, the number is seperated by 4 digits, and this happens in every format except one, printed 100,000,000 format. The printed ditgit format is affected by western world and for international convenience. When we say or write it in Chinese we use "万"(ten thousand) and "亿"(one hundred million) which are 1,0000 and 1,0000,0000 (I never see this digit format which is seperated by comma every 4 digits), so every time I see something like 123 million or 123,456,789 in English, I'll seperated it from 3 by 3 to 4 by 4, million is 1,000,000 which is 100,0000, so 123 million which is 123,000,000 will be converted into 1,2300,0000 which is 1亿2300万, in my head.
A similar confusion used to arise between the American and British meanings of "billion." An American billion (now the only version) was a thousand million. In Britain, this unit was called a "milliard", and a British billion was equal to a million million instead.
Effectively, the British were thinking in terms of a billion being "made out of" millions, to create numbers that would look intuitively like "1,000000,000000."
