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?

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.

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.