Yeah. It also seems to me like budget Murktide Regent for Standard, because it’s easier to cast (you don’t need to exile) but doesn’t grow

Replying from w3m!

Yeah, I see on my side that the community page here on SDF (e.g. https://lemmy.sdf.org/c/[email protected]) still has an RSS feed URL from the actual instance (in this case, https://programming.dev/feeds/c/programming.xml?sort=New)

Anyone know of a way around this?

I also mainly read SDF starting from RSS, but I use the singular feed for all my subscriptions. These always have links that take me to https://lemmy.sdf.org/post/XXXXXX. From newsboat (emphasis on link [3]):

Feed: SDF Chatter - Subscribed
Title: 2048 game I made in POSIX Shell
Author: https://iusearchlinux.fyi/u/narshee
Date: Tue, 11 Jul 2023 22:19:45 +0800
Link: https://github.com/narshee/2048.sh/

submitted by narshee[1] to shell[2]
12 points | 2 comments[3]
https://github.com/narshee/2048.sh/[4]

Links:
[1]: https://iusearchlinux.fyi/u/narshee (link)
[2]: https://lemmy.sdf.org/c/shell (link)
[3]: https://lemmy.sdf.org/post/741605 (link)
[4]: https://github.com/narshee/2048.sh/ (link)

Side-note: Only by pasting the above did I realize that the second link there is broken; it should go to https://lemmy.sdf.org/c/[email protected]

Perhaps this could be a workaround for you instead of having one feed per community? Perhaps also check if this is a feature request for Lemmy already?

Worth noting that this is GNU-specific! For macOS for example, you’d have to install GNU userland (e.g. from homebrew) to get the flag. There’s still value in using other solutions (such as ln), portability-wise.

As an aside: I mostly think of the ln param orders as exactly the same as cp and mv:

cp FROM TO
mv FROM TO
ln [-s] FROM TO

Maybe that could help!

If we’re talking specifically about executable scripts, here is #bash’s (libera.chat) factoid on the matter:

Don’t use extensions for your scripts. Scripts define new commands that you can run, and commands are generally not given extensions. Do you run ls.elf? Also: bash scripts are not sh scripts (so don’t use .sh) and the extension will only cause dependencies headaches if the script gets rewritten in another language. See http://www.talisman.org/~erlkonig/documents/commandname-extensions-considered-harmful

It’s for these reasons that I keep my executable scripts named without extensions (e.g. install).

I sometimes have non-executable scripts: they’re chmod -x, they don’t have a shebang, and they’re explicitly made for source-ing (e.g. library functions). For these, I give them an extension depending on what shell I wrote them for (and thus, what shell you need to use to source them), e.g. library.bash or library.zsh.

Right! Recursive is implied by -a

Yep. There’s a single ./install script in project root that calls install-cfg and install-plugins. I only really need to run it once (first time I set up on a machine), and every time I add a new file. If all I’ve done is update existing files, a simple git pull will update my dotfiles’ content automatically, as everything is symlinked already.

I agree with @[email protected], all of these are just different ways to skin the cat. Whatever gets the files in the proper directories. Once you pick one (even arbitrarily, to a degree), you’ll very likely find no reason to push you toward another solution. I myself use symlinks with GNU cp -s

There had been posts here, but we might be getting hit with this issue: https://lemmy.sdf.org/post/602126

Quite a few times, sure. git bisect is a specific case of a more general technique – binary search fault localization – which comes in handy every once in a while (you can go a long while without needing it, but when you do need it, you’ll be thankful for it). If you can’t otherwise trace where in the code something is going wrong, bisect the code: comment or remove half of it out, see if it reproduces (therefore localizing it to either the removed or the remaining half), and repeat. If you’re working with some software that’s breaking on your config after a major version bump, bisect your config. Don’t have an idea what introduced a bug into your branch? git bisect.

Yeah, I didn’t like the debates back then either, because they tended toward elitist gatekeeping.

That said, I think having a common language for rogue-likes, rogue-lites, roguelike-likes, and etc is useful enough still, but not for the purpose of exclusion. More so just for the purpose of being precise about discussion.

Someone asks “hey I like roguelikes, can you recommend me some?”, and the world might be a little bit better if I could instantly understand what they’re asking for without doing the whole “well, what do you mean by roguelikes, what do you play now” dance – do I recommend Rogue Legacy or Sil, that sort of thing.

I’ve made my peace with the names for the genres being imprecise as is (when are genres ever precise, anyway), but I think the Berlin Interpretation has a nice enough connotation where you go “oh, THAT kind of roguelike” to quickly establish shared context.