87
CachyOS is now Bigger than Arch Linux Ever Was! (boilingsteam.com)
submitted 5 months ago by to c/linux_gaming@lemmy.world
40 comments fedilink hide all child comments
you are viewing a single comment's thread
view the rest of the comments
[–] 7 points 5 months ago (9 children)

I used Alacritty and Fish before and I'm not interested into the features and complexity of BTRFS. Alacritty is a fine editor and wouldn't mind using, but it lacks features to me and there are better alternatives. I would prefer Kitty. Right now I use Konsole and that's good. Fish on the other hand, is more problematic to me. I use the terminal a lot and I am used to Bash, even write lot of Bash scripts. They are very similar, but still different and not compatible; so for me its a struggle in the terminal to remember the differences between Fish and Bash. There is 0 reason for me to use Fish and prefer Bash.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 9 child comments
    •
  • [–] 2 points 5 months ago (4 children)

    I instantly fell in love with the design choices of fish. It does things differently and more simply than bash. The syntax is actually readable linguistically compared to bash. Very conscious choices, and there's usually just one way of doing things, and they just make sense.

    I converted all my scripts from bash to fish. They are 50% less LOC, have zero comments in them, and I can actually come back a year later and instantly make an edit because I can actually read what the code does. In my bash scripts I did have comments, and I still had to bring up the manual to make an edit...

    Fish's language really is very small, you basically can actually fit its entire syntax footprint in your brain's working memory. It's great to work with. Highly recommend giving it a more serious shot for anyone who is curious of a better world. 😊

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 4 child comments
    •
  • [–] 2 points 5 months ago (3 children)

    I agree with you that Fish is in language design choices and the default features. There is no denying in that and is the reason why I used Fish as my main interpreter for weeks. But that would not change the fact that I read and write scripts, either for me, to share or to help others, let alone the legacy stuff. Bash is the standard.

    So scripts would stay in Bash for me, and only the interactive interpreter was Fish. And that was a problem for me. Because Fish and Bash are similar, but they are different enough that I got always confused which way was to do and write scripts. Especially because Bash had some quirks (yes its bad, not denying it), and Fish didn't have them. I thought that I would get used to, but it was always confusing. I rather have a language that is completely different, not similar but different.

    So, if I was using a different language that is no longer compatible with POSIX or Bash, then why would I use Fish instead any other language? Why not Xonsh (Python) or Nushell in example? Because that's the category I am looking Fish at, not to replace Bash.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 2 points 5 months ago* (2 children)

    if I was using a different language that is no longer compatible with POSIX or Bash, then why would I use Fish instead any other language? Why not Xonsh (Python) or Nushell in example?

    I think this is a great question, and the answer is probably more nuanced and personal, even per use case.

    I use fish because of its simplicity, period. And it had all the features I wanted from zsh built-in, with zero or simpler (actually understandable) configuration.

    I don't help anyone with bash or write or share scripts, so I don't have that issue where I need to juggle multiple shells, which is lucky for me perhaps. 😌

    But those other steps you mentioned probably are a bit more niche, let's say. I think nushell is more tailored to people using the shell to process a lot of data. Digging through logs, perhaps. Debugging systems, or systems management/maintenance. Then it's really handy to be able to process output as data tables, with proper sorting capabilities etc. Nushell is really powerful for that. I actually have it installed because it's already useful sometimes but I barely know any of its specific commands. 😅

    Anyway, the choice of shell really is very personal. For me, fish and bash share the same purpose of being used both interactively and as general-purpose scripting languages. And since fish is better in my opinion I chose it. But if I had other use cases, maybe a different job with different requirements, I would make nushell my default. 😁

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 2 child comments
    •
  • [–] 1 point 5 months ago (1 child)

    To be clear, I understand the appeal of Fish and its reason to exist. It's just I convinced myself that the standard shell should be POSIX compatible (had used ZSH for years too, before trying out Fish). And frankly, I am good enough in Bash for daily use and for scripting, that I can use it. Every time I look at Fish (to almost try it again), I'm jelious about some of the syntax and trap cleanups and features. Maybe one day I change my mind. I actually have plans to install Fish again and see how it goes.

    Nushell is really an interesting one. This is how I imagine a modern shell should be like. But the reality is, that all the Linux tools and commandline are not based on this concept. That's why I never got into. And Xonsh, well I write Python too, and not sure how confusing that would be... I just brought up these shells to make a point about Fish being different and that I categorize it like those.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 2 points 5 months ago

    To be clear, I understand the appeal of Fish and its reason to exist.

    Oh yeah, you were clear about that, not to worry. 😊

    I actually have plans to install Fish again and see how it goes.

    Nice, I hope you do! You're welcome to join The School! 😄

    I just brought up these shells to make a point about Fish being different and that I categorize it like those.

    Yeah, I get you. Definitely a reasonable way of looking at it, too.

    Personally I find fish to be a general-purpose shell, despite the fact that it is not POSIX-compatible. So in my mind it's in the same category as bash, csh, zsh, ksh, etc. It just does things very differently. 😄 But that's just my personal mental model.

    Anyway I'm here if you ever want some tips on how to do stuff idiomatically in fish, if you ever do decide to get started. 👍🤝 Hit me up in the DMs or something.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 1 point 5 months ago (3 children)

    I would prefer Kitty.

    Is there any particular reason why you prefer that one specifically? Out of all the newer terminal emulators I have tried, the only one I disliked more than kitty was warp.

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 3 child comments
    •
  • [–] 5 points 5 months ago (1 child)

    I used both when I was a tiling window manager user. Kitty is feature rich and has everything I would want. I would prefer over Alacritty, because I miss feature. However on my last OS installation, I kept Konsole (from KDE) as terminal emulator before I did all the basic setups and was planning on installing Kitty again. But it turned out that Konsole is excellent and there was no need to change, so kept using it.

    Why did you dislike Kitty?

  • permalink
  • fedilink
  • source
  • parent
  • hideshow 1 child comment
    •
  • [–] 4 points 5 months ago* (last edited 5 months ago)

    The protocols designed for Kitty are great, but I when I last gave Kitty itself a try, I felt it was extremely opinionated in a very off-putting way.

    It was advertised as being highly extensible and scriptable, but despite that, I found it to be less flexible than my old setup which wired up tmux with Python scripts. For instance, I was able to track which pane was previously active when creating a new split, allowing me to have the newly-created pane's bashrc read the old pane's bash /proc/ entry to copy the environment variables. That wasn't possible in Kitty. And although Kitty's splits layout were functional, resizing the splits themselves was an unconfigurable pain in the ass because the sizing is based on width/height rather than bounding boxes.

    I would normally chalk that up to growing pains of a new project, but reading through the GitHub issues and documentation didn't leave me with the impression that the author cared about how something could be done in Kitty, but only that it could be done in the most basic sense. If the user's workflow would benefit from having a partial overlay or popup, tough shit—they can either use a full overlay or create a layout for it.

    It didn't sit well with me, and moving to Kitty full time would have been a downgrade in productivity for practically no real benefit.

  • permalink
  • fedilink
  • source
  • parent
  • [–] 4 points 5 months ago

    I'm not the one you asked, but I use Kitty.

    It's the only terminal emulator that has consistently worked without bugs for me out of all the terminal emulators I've tried. And I've tried soooo many. Probably about 20, given them all serious time and a real shot, configuring each to my liking.

    One thing I don't like about Kitty is its configuration file format. 🫤

  • permalink
  • fedilink
  • source
  • parent