this post was submitted on 08 Sep 2025
320 points (97.9% liked)

linuxmemes

27339 readers
389 users here now

Hint: :q!


Sister communities:


Community rules (click to expand)

1. Follow the site-wide rules

2. Be civil
  • Understand the difference between a joke and an insult.
  • Do not harrass or attack users for any reason. This includes using blanket terms, like "every user of thing".
  • Don't get baited into back-and-forth insults. We are not animals.
  • Leave remarks of "peasantry" to the PCMR community. If you dislike an OS/service/application, attack the thing you dislike, not the individuals who use it. Some people may not have a choice.
  • Bigotry will not be tolerated.
  • 3. Post Linux-related content
  • Including Unix and BSD.
  • Non-Linux content is acceptable as long as it makes a reference to Linux. For example, the poorly made mockery of sudo in Windows.
  • No porn, no politics, no trolling or ragebaiting.
  • 4. No recent reposts
  • Everybody uses Arch btw, can't quit Vim, <loves/tolerates/hates> systemd, and wants to interject for a moment. You can stop now.
  • 5. πŸ‡¬πŸ‡§ Language/язык/Sprache
  • This is primarily an English-speaking community. πŸ‡¬πŸ‡§πŸ‡¦πŸ‡ΊπŸ‡ΊπŸ‡Έ
  • Comments written in other languages are allowed.
  • The substance of a post should be comprehensible for people who only speak English.
  • Titles and post bodies written in other languages will be allowed, but only as long as the above rule is observed.
  • 6. (NEW!) Regarding public figuresWe all have our opinions, and certain public figures can be divisive. Keep in mind that this is a community for memes and light-hearted fun, not for airing grievances or leveling accusations.
  • Keep discussions polite and free of disparagement.
  • We are never in possession of all of the facts. Defamatory comments will not be tolerated.
  • Discussions that get too heated will be locked and offending comments removed.
  • Β 

    Please report posts and comments that break these rules!


    Important: never execute code or follow advice that you don't understand or can't verify, especially here. The word of the day is credibility. This is a meme community -- even the most helpful comments might just be shitposts that can damage your system. Be aware, be smart, don't remove France.

    founded 2 years ago
    MODERATORS
    320
    Fish rules (piefedimages.s3.eu-central-003.backblazeb2.com)
     

    fish, the friendly interactive shell, is a commandline shell intended to be interactive and user-friendly.

    fish is intentionally not fully POSIX compliant, it aims at addressing POSIX inconsistencies (as perceived by the creators) with a simplified or a different syntax. This means that even simple POSIX compliant scripts may require some significant adaptation or even full rewriting to run with fish.

    Source

    you are viewing a single comment's thread
    view the rest of the comments
    [–] somerandomperson@lemmy.dbzer0.com 29 points 1 week ago (2 children)

    I HIGHLY recommend using bash and zsh as posix-compliant shells at the beginning, then if you want something different; you can use whatever the hell you want. Nushell, fish, etc.

    [–] woelkchen@lemmy.world 15 points 1 week ago (1 children)

    I HIGHLY recommend using bash and zsh as posix-compliant shells at the beginning

    Why? All the usual shell scripts don't use Fish as interpreter.

    [–] somerandomperson@lemmy.dbzer0.com 2 points 1 week ago (3 children)

    No posix compliance is a headache. (Where the hell are my aliases!?) And also most scripts need to be executed in a posix-compliant shell.

    [–] Zozano@aussie.zone 14 points 1 week ago* (last edited 1 week ago) (1 children)

    Most scripts need to be executed in a posix-compliant shell

    Simple. Just add #!/bin/bash to the start of your script and call it a day.

    Or use #!/usr/bin/env bash if you're goated with the sauce. This won't work if you're not goated with the sauce.

    Those who are goated with the sauce know what's up.

    [–] joyjoy@lemmy.zip 6 points 1 week ago

    Whatever you do, do not link /bin/sh to /bin/fish.

    [–] dreadbeef@lemmy.dbzer0.com 6 points 1 week ago* (last edited 1 week ago) (1 children)

    why use aliases (they exist in fish) when you can use abbreviations and your history isnt determined by whatever you set your aliases up as? If you change an alias, your history does not reflect that. If you use abbreviations, your history is perfectly usable

    [–] somerandomperson@lemmy.dbzer0.com 1 points 1 week ago (1 children)

    The fuck is an abbreviation? Is it a knock-off alias?

    [–] dreadbeef@lemmy.dbzer0.com 9 points 1 week ago* (last edited 1 week ago) (1 children)

    basically a text expansion. I have g=git, so when I type "g push" after I hit space after g, it expands it to git in the terminal as if i just typed out git myself. My history doesnt show "g push" it shows "git push" before I push enter

    https://fishshell.com/docs/current/cmds/abbr.html

    [–] fleet@lemmy.ca 4 points 1 week ago

    Been using fish for years and did not know this.

    [–] woelkchen@lemmy.world 4 points 1 week ago

    And also most scripts need to be executed in a posix-compliant shell.

    That's why there is that shebang thingie in first line. Distributions like Debian use an entire different shell from bash for scripts: https://manpages.debian.org/buster/dash/dash.1.en.html

    [–] interdimensionalmeme@lemmy.ml 5 points 1 week ago (2 children)

    WIll I be able to take my shell with on to every other computer I meet ? I mean, these things are tiny, but how portable are shells ? I don't want to learn a bunch of useful custom commands and then become frustrated to do anything on every computer other than mine.

    That's why I have a qwerty keyboard, I don't want to become useless whenever I have to use a keyboard that isn't my keyboard...

    [–] Ephera@lemmy.ml 4 points 1 week ago

    Fish is not the worst in this regard, because:

    • The defaults are pretty good, so you don't typically need a config file for it to be usable.
    • As of version 4.0, Fish is (experimentally) available as a single executable for download from their GitHub page. So, even on hosts where you can't install anything, you may still be able to copy that executable file onto there and use it.

    But there may still be situations where it's annoying, like if you're working in a container, then you likely don't want to mount your fish executable every time.

    But I also have to say I don't find it too big of a deal.
    I still use Bash for scripting (just throw a #!/bin/sh or #!/bin/bash at the top of your script, like you should anyways), and then for interactive use, not that much of the shell syntax comes into play anyways.
    And if I ever do need to copy a complex Bash command into an interactive shell, I can just run bash, then run the command in there and then exit back out.

    [–] somerandomperson@lemmy.dbzer0.com 2 points 1 week ago* (last edited 1 week ago) (2 children)

    Shell configs are hard to move. Some in $HOME/.config , some in .[idk]rc files, etc.

    It's messy. Unless you write everything you modify. If you did not do that up to now...good luck moving shell configs.

    [–] AdamBomb@lemmy.sdf.org 5 points 1 week ago

    What? No they aren’t hard to move. They’re usually just one file. Copy to your new machine and done.

    [–] interdimensionalmeme@lemmy.ml 1 points 1 week ago (1 children)

    I have no shell configs of any kind because it seemed like everytime I used another computer, I would not have them and I would end up having the re-learn everything.

    So instead I google every command every time or ask chatgpt, like this

    I find it very annoying there's isn't a reliable way to use alias or shells, functions and stuff.

    [–] tal@lemmy.today 2 points 1 week ago* (last edited 1 week ago) (1 children)

    I have no shell configs of any kind because it seemed like everytime I used another computer, I would not have them and I would end up having the re-learn everything.

    What I do is store my dotfiles in a git repository, and leave symlinks to the files in that repository. Then, when I move to another computer, pulling over all my configuration consists of doing a git pull to pull the git repo over and then running a command to set up the symlinks on that new computer. I can also make changes and selectively push things in. Some things need to be specific to a computer, and those don't go in.

    I use a homebrew script to set up the symlinks. A number of people use GNU stow for this.

    kagis for an example of someone using stow

    https://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html?round=two

    If you edit the symlinks in emacs (and I imagine vim), it picks up on the fact that they're symlinks into a git repository and that they're version-controlled.

    So, like:

    • Have a bare git repository on home machine, the "master" copy.

    • Every machine with an account has a non-bare dotfiles git repository checked out and symlinks pointing into that repo.

    • Make any changes on a given machine like you normally would, then git commit them to the local non-bare dotfiles git repo and push them to the master repository.

    • If setting up on a new machine, pull the git repository, and then run the command to set up the symlinks.___

    [–] interdimensionalmeme@lemmy.ml 2 points 1 week ago (1 children)

    That does sound like a good plan and I do have my own git server but
    Can I expect to be able to do this in the various work shells I come across ?
    Or do I risk becoming afoul of IT security ?(especially as it is not practical to ask each of them)

    [–] tal@lemmy.today 1 points 1 week ago

    I mean, that's not a question I can answer for you. I have never had a problem, myself, but I have no idea what your professional situation is. There are a shit-ton of ways to move git repositories around. If you can ssh out, if you can move physical storage in and out, if you have https out (though that'll be unidirectional in). I doubt that a typical IT department is going to care about you moving your dotfiles in, so if they do block something, probably worth a try just saying "I just want to pull my dotfiles from home; what's a good way to do that?" My guess is that most IT departments aren't going to have an issue with that. If you work for an intelligence service or something that has really super-stringent security requirements, then having any data movement in or out may be more of a headache.

    I would be careful to avoid sticking credentials (keys, passwords, anything like that) in any git-managed dotfiles. Not an issue for most software, but there are a few packages that will do that (neonmodem, a BBS-themed console Linux Lemmy client, does that...was just trying it yesterday.) You don't want to be dumping your home credentials all over in your git history, and work isn't going to want you pushing work credentials out.