is a downgrade in flow comprehensibility. Like I can see why it could be easier to read, but I prefer not having to analyze where statements, conditionals and functions begin and end. It’s very similar to how python works, and I disliked that in python. At the end of the day flow layout is subjective so you may or may not agree, but thats my mentality on it.
As for the piping example, I don’t have that snippet available anymore. I eventually remade the code from scratch and when I did I got rid of zenity as a dependancy which removed the need of having the pipe. It was a wget pipe into sed into zenity in order to use a progress bar for the download, and fish did not like that pipe at all, I’m not sure if it was because it was multiple pipes or if something else underlying was happening, but I could take that same pipe sequence and throw it into bash and it would function no issue, but with fish zenity wouldn’t give progress updates on it, so it was modifying the pipe somewhere.
Bias wise I wouldn’t say I was bias towards bash, I tried fish after recommendation from a friend because I hadn’t heard of it, and I had a bad experience. I moved to ZSH instead of going back to bash after all. I just found it easier to use over fish, and it was easier to research into issues when problems arose as it has a larger user-base and remained POSIX compatible (mostly). To me it made no sense to re-invent the wheel via fish. I’m sure fish had it’s advantages. I just didn’t see any during the week I was trialing it.
Is the main issue that you are using test and extra indentation with fish? Like, does this help?
function foo
if [ "$foo" == 1 ]
echo "found"
else
echo "not found"
end
end
Otherwise I don’t understand the difference except for the lack of curlies for the function. Bash also has a function keyword which can be optional. function is like a command with an argument (and options). It doesn’t need a symbol or anything signifying that the code will start, other than a new line, just like other shell statements/command invocations. if is the same way. It’s just a command that runs the rest of the command arguments and inspects the return code. Same as using the more idiomatic and and or commands, which are pretty neat to use sometimes.
test $foo = 1
and echo "found"
or echo "not found"
I digress. Otherwise it’s just {'s, and thens and dos. That’s the only difference.
If you are writing such big blocks of code that you can’t tell which end belongs to which opening thing, there is probably some abstraction needed. Extraction into a separate function. 😬 Maybe that’s what you mean?
I prefer not having to analyze where statements, conditionals and functions begin and end.
I’m very curious why you feel like you have to do that with fish and I never did. Like there must be something fundamental. What separates the two of us here. Because I don’t even know python. I can read python, but I never did anything in it. Like ever. So that’s not a factor. In fact I’m mostly used to C-like languages where everything that opens a block uses a {. So why do I not have an issue with fish and just find it much simpler.
Maybe you are thinking about fish more as a programming language? Whereas I’m thinking about it more like a series of commands (I guess more like a “purer” scripting language of sorts)?
Is the main issue that you are using test and extra indentation with fish? Like, does this help?
yes that is better, I do like the clearer differentiation on what is a command vs part of the flow control. I do find that using [] or [[]] is cleaner looking than using the standard test command, but the main point of it was showing the flow; functions having a beginning { and an ending }, conditionals clearly using if to mark the beginning, ; then to mark when the conditional portion of the flow ends and the processing portion begins, and the fi to indicate when the processing portion ended. Flow control statements like that. Could I be able to decipher it manually like I have to with python? yes, but it’s just something that as a personal preference I would prefer not to do if avoidable.
its easier to let me know that the previous line wasn’t done, and that I should be expecting the conditional to continue instead of start to work on the next line. The most noticeable would be with really long conditionals, I think its nice since bash and fish don’t use {} outside of functions to indicate open and close like other non-tab oriented languages. Moving longer lines to dedicated functions works well but doesn’t help when the entire conditional is related so it would just be in the main function block instead.
It’s a very subjective thing, definitely more of a minor thing since I already have to deal with it with tab oriented languages on the rare occasion I deal with them. My main issues with it were definitely was the lack of usage leading to fewer examples and documentation on how it worked, and then the piping issue was just the final nail in the coffin that made me drop it.
Maybe you are thinking about fish more as a programming language? Whereas I’m thinking about it more like a series of commands (I guess more like a “purer” scripting language of sorts)?
Yes, that is likely the differentiation. I understand that bash is more command based but, I do a lot of stuff in java, node and Rust, and those all have clear differentiation of start and end (although rust’s can be a pain at times)
I find that fish
vs bash
function foo () { if [[ "$foo" == 1 ]]; then echo "found" else echo "not found" fi }is a downgrade in flow comprehensibility. Like I can see why it could be easier to read, but I prefer not having to analyze where statements, conditionals and functions begin and end. It’s very similar to how python works, and I disliked that in python. At the end of the day flow layout is subjective so you may or may not agree, but thats my mentality on it.
As for the piping example, I don’t have that snippet available anymore. I eventually remade the code from scratch and when I did I got rid of zenity as a dependancy which removed the need of having the pipe. It was a wget pipe into sed into zenity in order to use a progress bar for the download, and fish did not like that pipe at all, I’m not sure if it was because it was multiple pipes or if something else underlying was happening, but I could take that same pipe sequence and throw it into bash and it would function no issue, but with fish zenity wouldn’t give progress updates on it, so it was modifying the pipe somewhere.
Bias wise I wouldn’t say I was bias towards bash, I tried fish after recommendation from a friend because I hadn’t heard of it, and I had a bad experience. I moved to ZSH instead of going back to bash after all. I just found it easier to use over fish, and it was easier to research into issues when problems arose as it has a larger user-base and remained POSIX compatible (mostly). To me it made no sense to re-invent the wheel via fish. I’m sure fish had it’s advantages. I just didn’t see any during the week I was trialing it.
Is the main issue that you are using
testand extra indentation with fish? Like, does this help?Otherwise I don’t understand the difference except for the lack of curlies for the function. Bash also has a function keyword which can be optional.
functionis like a command with an argument (and options). It doesn’t need a symbol or anything signifying that the code will start, other than a new line, just like other shell statements/command invocations.ifis the same way. It’s just a command that runs the rest of the command arguments and inspects the return code. Same as using the more idiomaticandandorcommands, which are pretty neat to use sometimes.I digress. Otherwise it’s just
{'s, andthens anddos. That’s the only difference.If you are writing such big blocks of code that you can’t tell which
endbelongs to which opening thing, there is probably some abstraction needed. Extraction into a separate function. 😬 Maybe that’s what you mean?I’m very curious why you feel like you have to do that with fish and I never did. Like there must be something fundamental. What separates the two of us here. Because I don’t even know python. I can read python, but I never did anything in it. Like ever. So that’s not a factor. In fact I’m mostly used to C-like languages where everything that opens a block uses a
{. So why do I not have an issue with fish and just find it much simpler.Maybe you are thinking about fish more as a programming language? Whereas I’m thinking about it more like a series of commands (I guess more like a “purer” scripting language of sorts)?
I dunno, this is getting very philosophical. 😆
yes that is better, I do like the clearer differentiation on what is a command vs part of the flow control. I do find that using
[]or[[]]is cleaner looking than using the standard test command, but the main point of it was showing the flow; functions having a beginning{and an ending}, conditionals clearly usingifto mark the beginning,; thento mark when the conditional portion of the flow ends and the processing portion begins, and thefito indicate when the processing portion ended. Flow control statements like that. Could I be able to decipher it manually like I have to with python? yes, but it’s just something that as a personal preference I would prefer not to do if avoidable.its easier to let me know that the previous line wasn’t done, and that I should be expecting the conditional to continue instead of start to work on the next line. The most noticeable would be with really long conditionals, I think its nice since bash and fish don’t use {} outside of functions to indicate open and close like other non-tab oriented languages. Moving longer lines to dedicated functions works well but doesn’t help when the entire conditional is related so it would just be in the main function block instead.
It’s a very subjective thing, definitely more of a minor thing since I already have to deal with it with tab oriented languages on the rare occasion I deal with them. My main issues with it were definitely was the lack of usage leading to fewer examples and documentation on how it worked, and then the piping issue was just the final nail in the coffin that made me drop it.
Yes, that is likely the differentiation. I understand that bash is more command based but, I do a lot of stuff in java, node and Rust, and those all have clear differentiation of start and end (although rust’s can be a pain at times)