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.

Yeah, I use weechat.

But in the interest of sharing something new: I do also like ii, which is a minimal filesystem-based IRC client. To tail a channel’s messages, for example, you could do

tail -f #vim/out

Then to send a message,

echo 'Hello, world!' > #vim/in

Fun for the first five minutes just pulling together a makeshift IRC client with tmux panes and the above, but then you realize the depth of the iceberg with its scriptability with standard Unix pipelines. Tail out into a perl script that pipes back into in for example and you have a bot.

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.