11–20 of 298 posts
I see that this person has opted not to use python 3 because it is 'less-suited to shell-like problems' than python 2. In an effort to understand the reasons for actively choosing against 3, does anyone know what problems those would be?
Lots of overlap in design goals with fish, except fish also places a premium on users interactively using the shell (which means friendlier in-repl experience but a balancing act when it comes to features). Fish’ auto completions are incredible, too. Best of luck to them. Another interesting shell to check out is elvish, lots of new ideas there (even if awkward to use). (Disclosure: I’m one of the core fish devs/main…
Do you have anything to say about rc https://9fans.github.io/plan9port/man/man1/rc.html ?
...people frequently ask this? Tip #21 of "The Pragmatic Programmer" states: "Use the Power of Command Shells."
Finally a modern shell that understands the importance of COMPATIBILITY! This gives it a realistic chance of getting real adoption. Shells like zsh and fish will never get mainstream adoption because they are not compatible with bash.
https://en.wikipedia.org/wiki/Shebang_(Unix)
I used fish for years, never had a problem with bash or zsh scripts.
Finally a modern shell that understands the importance of COMPATIBILITY! This gives it a realistic chance of getting real adoption. Shells like zsh and fish will never get mainstream adoption because they are not compatible with bash.
> /bin/bash your_script.sh
And if your script is written with bash in mind, use a shebang:
> #! /bin/bash
And it will work perfectly fine on fish. As long as I have a bash binary, why do I need COMPATIBILITY?
> Shouldn't we discourage people from writing shell scripts? ...people frequently ask this? Tip #21 of "The Pragmatic Programmer" states: "Use the Power of Command Shells."
In a general purpose programming language there's a lot of overhead for doing the same things.
For maintainability, there are now linters for shell languages that can help making the job easier.
Finally a modern shell that understands the importance of COMPATIBILITY! This gives it a realistic chance of getting real adoption. Shells like zsh and fish will never get mainstream adoption because they are not compatible with bash.
e: sorry some connection interruption and now this is redundant to other comments.
Finally a modern shell that understands the importance of COMPATIBILITY! This gives it a realistic chance of getting real adoption. Shells like zsh and fish will never get mainstream adoption because they are not compatible with bash.
Why do people care about "COMPATIBILITY" so much w.r.t. shells? It's so easy to use other shells to run your script. > /bin/bash your_script.sh And if your script is written with bash in mind, use a shebang: > #! /bin/bash And it will work perfectly fine on fish. As long as I have a bash binary, why do I need COMPATIBILITY?
Finally a modern shell that understands the importance of COMPATIBILITY! This gives it a realistic chance of getting real adoption. Shells like zsh and fish will never get mainstream adoption because they are not compatible with bash.
Why do people care about "COMPATIBILITY" so much w.r.t. shells? It's so easy to use other shells to run your script. > /bin/bash your_script.sh And if your script is written with bash in mind, use a shebang: > #! /bin/bash And it will work perfectly fine on fish. As long as I have a bash binary, why do I need COMPATIBILITY?
After using fish for 3 years, I'm finding there is very little reason to have my login shell maintain backwards compatibility with bash. The only time I run into issues is when a command expects manipulate environment variables via bash syntax. I think the fish documentation WRT to scripting could be much better, but the language is more elegant than bash or PowerShell IMHO.
And in my experience 90% of those are in the form `FOO=bar command` which can be replaced with `env FOO=bar command` and works just fine in fish.