I don’t know bash scripting

if [ -d ~/.bashrc.d ]; then
	for rc in ~/.bashrc.d/*; do
		if [ -f "$rc" ]; then
			. "$rc"
		fi
	done

I asked chatgpt and it said this is non standard? There is no bashrc.d directory on my home folder, I have uncommented the lines for now but dont know if this is benign or malignant

      • @[email protected]
        link
        fedilink
        English
        11
        edit-2
        2 months ago

        Then it should have no effect.

        This is just a nice way to define file-discrete .rc scripts. Like, maybe you have one for shell stuff, one for your custom collection of command aliases, one for initializing pyenv+pyenv-virtualenv, etc. That way, you have domain-constrained .rcs, and it’s easier to scan through things to see if something funny is going on / is broken or whatever.

      • @[email protected]
        link
        fedilink
        62 months ago

        It just checks to see if there is anything in a bash.d folder, if there isn’t it moves on. Just somebody being preemptively helpful to check for other locations

  • SavvyWolf
    link
    fedilink
    English
    282 months ago

    Check /etc/skel/.bashrc, if it’s in there as well, it was set up by your distro.

    What it does is check for the existence of ~/.bashrc.d and, if it finds one, sources all the files inside it. This effectively means that you can create script files like ~/.bashrc.d/myfile.sh and they will have the same effect as if they had been put directly into .bashrc. Some people prefer having one file for each “bashrc thing” whilst some prefer just having one big file. Ultimately it’s personal preference.

  • Badabinski
    link
    fedilink
    142 months ago

    Ugh, I hate ChatGPT. If this is Bash (which it is, because it’s literally looking for files in a directory called ~/.bashrc.d), then it should god damned well be using syntax and language features that we’ve had for at least twenty fucking years. Specifically, if you’re writing for Bash (and not POSIX shell), you better be using [[ ]] rather than [ ]. This wiki is my holy book I use to keep the demons away when writing Bash, and it does a simply fantastic job of explaining why you should use God damned double square brackets.

    ChatGPT writes shitty, horrible, buggy ass Bash. This is relatively decent for ChatGPT (it even makes sure the files are real files and not symlinks), but I’ve had to fix enough terrible fucking shitty AI Bash to have no tolerance for even the smallest misstep from it.

    Sincerely, A senior developer who is known as the Bash wizard at work.

    EDIT: Sorry, OP. ChatGPT did not, in fact, write this code, and I am going to leave my comment here as a testament to what a big smelly dick I was here.

    • @JustAnotherKay
      link
      182 months ago

      I think you misread both the question and how they used ChatGPT Mr Bash Wizard

      • Badabinski
        link
        fedilink
        212 months ago

        oh fuck I did misread it. Man, now I sound like a big ol’ asshole. Sorry, OP :/ I had a bad week thanks to some ChatGPT code and just kinda jumped out when I saw the word “ChatGPT” next to Bash.

  • 𝘋𝘪𝘳𝘬
    link
    fedilink
    102 months ago

    It first checks if ~/.bashrc.d is an existing directory. If this it the case it then iterates over all entries in that directory. In this iteration it checks if the entry is a file and if this is the case it sources that file using the bash-internal shorthand . for source.

    So it basically executes all scripts in ~/.bashrc.d. This makes it possible for you to split your bash configuration into multiple files. This quite common and a lot of programs already support it (100% depends on the program, though).

    This is absolutely harmless as it is. But: if you or a program places anything in the directory ~/.bashrc.d it WILL be sourced everytime you start a bash.

    A slightly better variant would be iterating over ~/.bashrc.d/*.sh instead of just ~/.bashrc.d/* to make sure to only grab files with the .sh suffix (even if suffixes are basically meaningless from a technical point of view) and also test for the file being executable (-x instead of -f).

    This would make sure that only files that are ending with .sh and that are executable are sourced. The “attack vector”, if you want to call it like that, would then be a bit more narrow than just placing a file in a directory.

    As for why it’s there: Did you ever touch your .bashrc? If not, maybe it is there since the beginning because it’s in the so-called skeleton (see /etc/skel/.bashrc) that was used to initialize certain files on user account creation.

  • @JubilantJaguar
    link
    72 months ago

    Damn, now I want this too!

    As others have said, all it does is pull in any other config files in that may be in that folder. And storing them separately like that is much better for backup and portability.

    Ubuntu doesn’t do this.

  • @[email protected]
    link
    fedilink
    52 months ago

    Definitely non-standard, but I have something almost identical that I very consciously added and really simplifies a lot of things.

  • @[email protected]
    link
    fedilink
    English
    32 months ago

    i don’t know much bash, so anyone else who responds is probably more right, but since no one has responded, here’s my 2 cents: it appears to be a script to run all scripts in .bashrc.d. That would be similar to how some apps will let you separate a configuration file into multiple files in a directory conf.d. If there is no .bashrc.d, then it should be fine.

  • @TootSweet
    link
    English
    32 months ago

    If you’re thinking it may be malicious, I think it’s innocuous.

    Try cat’ing /etc/skel/.bashrc and see if the code in question in in there. My guess is it will be. When a new user’s home directory is created, it copies all the files from /etc/skel into the newly-created home directory. So, that directory is basically a “new user home directory template.”

    The code you posted (is missing an fi at the end, but anyway) just looks like a utility for making it easier to organize your .bashrc into separate files rather than one big file. That’s a common technique for various configuration files that a lot of distros commonly do. And I personally find that technique nice.

    If you want to delete that code, it’s not going to hurt anything to remove it (unless someday you add a ~/.bashrc.d/ directory and some file in there “doesn’t work” and it confuses you why.)

    Also, what distro are you on?

  • @[email protected]
    link
    fedilink
    12 months ago

    seems similar to the set up for systemd snippets, where you can avoid changing default config files for systemd units and instead use a drop in file in that created .d dir to load and overwrite the defaults on boot for whatever specific thing. don’t know anything that uses this for bashrc, tho. most likely harmless, especially if there’s no created bashrc.d yet.