I dislike heavily how flow control works on it, and the lack of indication where it starts to where it ends, the function layout, not to mention attempting to pipe anything via it. This combined with the fact that it’s a lesser used shell and as such has less of a presence online to research made it not worth the time and effort to actually use it. I swapped to ZSH which at least maintains a large POSIX compliance which makes it easier to share the scripts as well and also supports adding many of fish’s features.
It may be nicer to read but, actually getting established, learning it, using it and then maintaining compatibility with other programs and scripts when using it, just made it not worth it. I have better things to do with my free time then to try and fight a shell every step of the way to make it look cleaner.
You mean its if and switch statements? For and while loops? Just like bash and zsh has?
the lack of indication where it starts to where it ends
You mean the end keyword? The start of things should be clear enough. Keywords are used for them depending on what you’re starting. I like the fact that everything ends with the same keyword. Much simpler.
the function layout, not to mention attempting to pipe anything via it
Piping something “via the function layout”? I’m not even sure what that means. I’d love to know more if you would.
maintaining compatibility with other programs and scripts when using it, just made it not worth it
This should be fully transparent. It’s a shell. I switched all my scripts to fish, and my integration with my desktop environment was completely unchanged. It’s just text in and text out.
I have better things to do with my free time th[a]n to try and fight a shell every step of the way to make it look cleaner.
I mean… It took me like an hour to read through the documentation, and all the syntax is so small you can memorize the entire language.
It comes with a nice web based documentation built in. And all the built-in commands have their own man page for easy reading, compared to the jumbled mess of zsh’s docs. I could never find a goddamn thing in zsh’s two handfuls of different man pages. Nothing was where I thought it would be.
It kind of sounds like you were fighting fish rather than it fighting you, every step of the way. That sounds absolutely crazy compared to my experience.
My experience with fish is that I finally understood what my shell was doing and how it works, compared to zsh. I even understood what bash was doing. zsh, no. And all these files it was leaving around my home directory.
What I will concede is that you should not convert your shell scripts if you need portability. If your scripts will be on multiple computers, fish is a bad idea if you don’t control them all.
Otherwise it feels like some other issue is bigger here, because fish is so much simpler. Coming from me who’s been scripting in bash and zsh for about 20 years, and zsh is the only one that has stumped me, and whose documentation I’ve been struggling with. Even bash’s is better. 💀
You mean its if and switch statements? For and while loops? Just like bash and zsh has?
No i mean the flow in general. It’s ugly and not transparent when compared to bash or any other language
the lack of indication where it starts to where it ends
Yes and no, I mean how it chooses to start and end, there is no punctuation, it seems to emulate a tab oriented language without being a tab oriented language.
Piping something “via the function layout”? I’m not even sure what that means. I’d love to know more if you would.
Two separate complaints, I dislike how they manage functions (but yes bash does similar on this case). Piping and redirecting are badly implemented and what would be an accepted pipe in ZSH or Bash will fail in fish. I made a script that had to pipe a file via wget and it wouldn’t function unless I used a pager which wasn’t needed in Bash or Zsh and wasn’t documented as a requirement anywhere on their piping or redirection documentation. Took me almost an hour of troubleshooting why the command was failing and how to fix it due to it.
I mean… It took me like an hour to read through the documentation, and all the syntax is so small you can memorize the entire
language.
Maybe this has changed since I last tried about a year or two ago, but last time I tried to read the documentation it sucked hardcore and lacked examples of more advanced parts of the shell.
It kind of sounds like you were fighting fish rather than it fighting you, every step of the way. That sounds absolutely crazy compared to my experience.
I would rather take the path of least resistance for a program, with fish it had way too much resistance trying to use it, so I went to the path that had a lesser resistance, which was ZSH, and then just proceeded to add fish’s core capabilities to zsh. This let me use a scripting language that has a lot of documentation and examples to assist in learning, while having the benefits of the shell. Plus it lets me actually share the scripts with friends because it’s already hard to find someone on linux, and its even moreso difficult to find someone who uses fish shell.
the flow in general. It’s ugly and not transparent when compared to bash or any other language
Could you give a single example of this “ugly” and not “transparent” control flow, so I can compare it to bash? I’m having a hard time relating to those subjective and fuzzy adjectives. To me, fish is more clear by a mile. And that is the opinion of someone who has been scripting proficiently in bash for almost two decades, and in fish for like two years. So I’m super curious what you mean, specifically.
Is this possibly a question of bias? You are used to bash-like syntax and weren’t really open to, excited about, or even neutral to fish to begin with? Could that have been a factor?
how it chooses to start and end, there is no punctuation, it seems to emulate a tab oriented language
I don’t get this. Everything that starts a block of statements or control flow is a statement in itself, like function, or if. You can do the next statement on the next line, or add punctuation (;) and add the next statement on the same line. Just like bash.
What’s weird, I always thought, was that bash had these weird, required, extra statements that are needed, like then, and do, etc. Those are ugly to me, and make no sense when you think about it for a little bit. They are excessive and unneeded. The first keyword indicates the start of the thing, by itself. Really simple, and a good design choice IMO. Fewer LOC, less verbosity, without being too terse and sacrificing legibility but only increasing it.
Piping and redirecting are badly implemented
it wouldn’t function unless I used a pager which wasn’t needed in Bash
Super curious about this scenario. Piping isn’t different in fish. You just pipe output to an input. So yeah, very curious about this specific case.
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)
Okay cool, I think I’m starting to understand a bit better now. 😄✨
I do find that using [] or [[]] is cleaner looking than using the standard test command
If I may blow your mind (really hoping you don’t already know this, otherwise it will be long, boring repetition, but here goes 😅):
[ is actually just an alias for the test command, for which the closing ] is a required last argument (in fish it’s required; in bash it’s even optional!).
In the documentation for both fish and bash, it really just starts with if list;, where list is a list of commands. This means we can do stuff like:
if wget ...
then
# download successful
fi
And that’s why we can do this in bash too:
if test ...
then
...
fi
And even (in bash only; not fish):
if [ $foo = 1 # no ending `]`
then
...
fi
Further cementing that if can be seen as just a command that runs another command (its argument(s)), then controls the flow.
I think this knowledge helps me feel more comfortable with the fish syntax, to have always in my mind that these can be considered “commands”, more than they are “syntax”. Sort of. Even if they are syntax to a certain degree of course.
Does that all makes sense? 😅💫
But anyway, I see and acknowledge all your points you’ve made throughout, even though I ignored them and focused only on those things I didn’t understand for the sake of profession. So I validate your feelings regarding those as well. Like, if you aren’t feeling comfortable with fish from the start, it won’t be easy since the community is smaller. For me, almost everything I needed was in the documentation, but sometimes people learn best by surfing around community information. Fish also isn’t exactly portable, indeed. Etc, etc. All these points you made, all good and valid. 👌
You know what, I think fish is probably the kind of shell with which you sort of “fall in love”. It might not be a “try it for a month and see” thing, but more of a “hey I’m curious about this, let me check it out… Oh wow, I really like the opinionated design philosophy here, I will probably use this a long time, so let me install it” kind of deal. It’s for a specific kind of mindset I guess. Which I’m sure more people would realize that they actually have if they only knew about fish, but it’s still not for everyone, clearly. 🙂
So while it does enable a more condensed scripting language, objectively, it might not be subjectively more legible if it’s hard to break free from the habit of bash and POSIX like syntax, which is very understandable.
To wrap up, I thank you very much for going on this journey with me. I hope it was half as interesting for you as it was for me. I learned some things for sure. 😊 So thanks for your patience and replies! 🙏
I dislike heavily how flow control works on it, and the lack of indication where it starts to where it ends, the function layout, not to mention attempting to pipe anything via it. This combined with the fact that it’s a lesser used shell and as such has less of a presence online to research made it not worth the time and effort to actually use it. I swapped to ZSH which at least maintains a large POSIX compliance which makes it easier to share the scripts as well and also supports adding many of fish’s features.
It may be nicer to read but, actually getting established, learning it, using it and then maintaining compatibility with other programs and scripts when using it, just made it not worth it. I have better things to do with my free time then to try and fight a shell every step of the way to make it look cleaner.
You mean its if and switch statements? For and while loops? Just like bash and zsh has?
You mean the
endkeyword? The start of things should be clear enough. Keywords are used for them depending on what you’re starting. I like the fact that everything ends with the same keyword. Much simpler.Piping something “via the function layout”? I’m not even sure what that means. I’d love to know more if you would.
This should be fully transparent. It’s a shell. I switched all my scripts to fish, and my integration with my desktop environment was completely unchanged. It’s just text in and text out.
I mean… It took me like an hour to read through the documentation, and all the syntax is so small you can memorize the entire language.
It comes with a nice web based documentation built in. And all the built-in commands have their own man page for easy reading, compared to the jumbled mess of zsh’s docs. I could never find a goddamn thing in zsh’s two handfuls of different man pages. Nothing was where I thought it would be.
It kind of sounds like you were fighting fish rather than it fighting you, every step of the way. That sounds absolutely crazy compared to my experience.
My experience with fish is that I finally understood what my shell was doing and how it works, compared to zsh. I even understood what bash was doing. zsh, no. And all these files it was leaving around my home directory.
What I will concede is that you should not convert your shell scripts if you need portability. If your scripts will be on multiple computers, fish is a bad idea if you don’t control them all.
Otherwise it feels like some other issue is bigger here, because fish is so much simpler. Coming from me who’s been scripting in bash and zsh for about 20 years, and zsh is the only one that has stumped me, and whose documentation I’ve been struggling with. Even bash’s is better. 💀
No i mean the flow in general. It’s ugly and not transparent when compared to bash or any other language
Yes and no, I mean how it chooses to start and end, there is no punctuation, it seems to emulate a tab oriented language without being a tab oriented language.
Two separate complaints, I dislike how they manage functions (but yes bash does similar on this case). Piping and redirecting are badly implemented and what would be an accepted pipe in ZSH or Bash will fail in fish. I made a script that had to pipe a file via wget and it wouldn’t function unless I used a pager which wasn’t needed in Bash or Zsh and wasn’t documented as a requirement anywhere on their piping or redirection documentation. Took me almost an hour of troubleshooting why the command was failing and how to fix it due to it.
Maybe this has changed since I last tried about a year or two ago, but last time I tried to read the documentation it sucked hardcore and lacked examples of more advanced parts of the shell.
I would rather take the path of least resistance for a program, with fish it had way too much resistance trying to use it, so I went to the path that had a lesser resistance, which was ZSH, and then just proceeded to add fish’s core capabilities to zsh. This let me use a scripting language that has a lot of documentation and examples to assist in learning, while having the benefits of the shell. Plus it lets me actually share the scripts with friends because it’s already hard to find someone on linux, and its even moreso difficult to find someone who uses fish shell.
Could you give a single example of this “ugly” and not “transparent” control flow, so I can compare it to bash? I’m having a hard time relating to those subjective and fuzzy adjectives. To me, fish is more clear by a mile. And that is the opinion of someone who has been scripting proficiently in bash for almost two decades, and in fish for like two years. So I’m super curious what you mean, specifically.
Is this possibly a question of bias? You are used to bash-like syntax and weren’t really open to, excited about, or even neutral to fish to begin with? Could that have been a factor?
I don’t get this. Everything that starts a block of statements or control flow is a statement in itself, like
function, orif. You can do the next statement on the next line, or add punctuation (;) and add the next statement on the same line. Just like bash.What’s weird, I always thought, was that bash had these weird, required, extra statements that are needed, like
then, anddo, etc. Those are ugly to me, and make no sense when you think about it for a little bit. They are excessive and unneeded. The first keyword indicates the start of the thing, by itself. Really simple, and a good design choice IMO. Fewer LOC, less verbosity, without being too terse and sacrificing legibility but only increasing it.Super curious about this scenario. Piping isn’t different in fish. You just pipe output to an input. So yeah, very curious about this specific case.
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)
Okay cool, I think I’m starting to understand a bit better now. 😄✨
If I may blow your mind (really hoping you don’t already know this, otherwise it will be long, boring repetition, but here goes 😅):
[is actually just an alias for thetestcommand, for which the closing]is a required last argument (in fish it’s required; in bash it’s even optional!).In the documentation for both fish and bash, it really just starts with
if list;, wherelistis a list of commands. This means we can do stuff like:And that’s why we can do this in bash too:
And even (in bash only; not fish):
Further cementing that
ifcan be seen as just a command that runs another command (its argument(s)), then controls the flow.I think this knowledge helps me feel more comfortable with the fish syntax, to have always in my mind that these can be considered “commands”, more than they are “syntax”. Sort of. Even if they are syntax to a certain degree of course.
Does that all makes sense? 😅💫
But anyway, I see and acknowledge all your points you’ve made throughout, even though I ignored them and focused only on those things I didn’t understand for the sake of profession. So I validate your feelings regarding those as well. Like, if you aren’t feeling comfortable with fish from the start, it won’t be easy since the community is smaller. For me, almost everything I needed was in the documentation, but sometimes people learn best by surfing around community information. Fish also isn’t exactly portable, indeed. Etc, etc. All these points you made, all good and valid. 👌
You know what, I think fish is probably the kind of shell with which you sort of “fall in love”. It might not be a “try it for a month and see” thing, but more of a “hey I’m curious about this, let me check it out… Oh wow, I really like the opinionated design philosophy here, I will probably use this a long time, so let me install it” kind of deal. It’s for a specific kind of mindset I guess. Which I’m sure more people would realize that they actually have if they only knew about fish, but it’s still not for everyone, clearly. 🙂
So while it does enable a more condensed scripting language, objectively, it might not be subjectively more legible if it’s hard to break free from the habit of bash and POSIX like syntax, which is very understandable.
To wrap up, I thank you very much for going on this journey with me. I hope it was half as interesting for you as it was for me. I learned some things for sure. 😊 So thanks for your patience and replies! 🙏