JNRowe

Lots of commentary from a couple of days ago - https://news.ycombinator.com/item?id=31200989

Excellent, thanks!

I'm purposely being careful too. Big backoff on any error, curl's --time-cond from git commit timestamp, etag where possible, etc.

I'm not particularly concerned about an actual DoS'ing issue, more being on the end of one of those stories that pops up every so often("website owner sics lawyers on F12").

Slightly tangential to this post, but related to the series.

Have you had any pushback from the sources you've been scraping with actions? I can't imagine how lightly hitting GitHub from this action is a problem, but a few of the other scrapers you've discussed are hitting resources in ways we've definitely seen website operators get upset about before.

I ask because I've been playing with a couple of scrapers for info I'm interested in, but I'm a little reluctant to toggle the repo visibility switch. Partly, because I don't want the grief and selfishly because I don't want the source to disappear.

Given developers testing against shells that implement the spec, and a solid spec, and a variety of implementations that correctly implement that spec then I'm in full agreement with you. However, the moment you add caveats to that description you have, well… caveats to that description.

The situation - as I see it - is that we have a spec, and we have systems that ship a /bin/sh that implements something like it. If people are targetting their system's /bin/sh, then they're writing scripts for their /bin/sh implementation not posix compliant shells. For example, my install uses dash which has features beyond the posix spec which I have to eschew to produce portable scripts.

As a sibling comment points out shellcheck will point out a lot problems, but it requires people choosing to use it. You only have to dive around /usr/bin for a little while to see its usage isn't universal ;)

Of course, if the differences in implementation don't affect your usecase then it simply doesn't matter.

Not to discourage the Show HN on your IMO excellent project, but I want to point to the non-Show HN discussion from the other day¹. A bunch of interesting comments, plus the expected diversions ;)

¹ https://news.ycombinator.com/item?id=31163083

Ick, you're right. I was thinking solely about the change with their version of the "2>&1" vs "2>& 1" case.

Although making such an error in my example doesn't seem to invalidate my point. It takes an already odd syntax and makes it subtly different, instead of tightening it up.

I think chubot presents a pretty good reasoning in his documentation for oil¹. Basically I think it comes down to there being a lot of problems with bash scripts, but the currently alternatives to bash just introduce a different set of problems. With luck maybe one of the new ones will find the sweet spot, but we won't find out without people trying.

Still, if bash works for you keep using bash ;)

¹ https://www.oilshell.org/blog/2021/01/why-a-new-shell.html

I think part of the problem is that we still don't have a standard /bin/sh even though there is a written standard. It feels fair to me to suggest that you can call dash the working standard on Linux, but you can't trust that beyond Linux systems(and I'm ignoring installs that are busybox-based here too).

And that also feels like the problem with extending a script with a few bashisms too, as you're suddenly trying to remember when that feature appeared. Off the top of my head I'm wondering what things won't be available to Mac users because it ships with a pre-GPLv3 bash for example.

The language looks really quite interesting. I could see myself using it for quick scripts.

I think I'd prefer bash's noclobber behaviour to be the default redirection style. The explicitness of being forced to >| always feels like a nice safety feature to me, which would tie in nicely with their other defaults for safer scripting.

Also, not sure I'm keen on their minor change to the redirection syntax¹. It suggests that "2>1" and "2> 1" have very different results, which feels like an odd change to make when you're keeping the other aspects of that syntax. Probably says more about me though, I want 100% match or a complete break to force me to think.

I think it is interesting to compare the approach of oil², which has overlapping goals but is attacking the problem of improving shell scripting while attempting to keep the syntax.

¹ https://hush-shell.github.io/cmd/basic.html

² https://www.oilshell.org/

(note: if - like me - you're not seeing syntax highlighting for hush then enable JS)

The section on the try operator¹ includes an example showing the syntactic sugar to reduce the verbosity. It does feel like it might be better to introduce it earlier on, as I was feeling the same way as you until I saw that.

¹ https://hush-shell.github.io/error-handling.html#try-operato...

Looks good!

It would be nice if there wasn't an early exit when a matching directory is found in `def.config`. That way you could have multiple matches for a directory, and it would make simple stacking work for subdirectories too. The current behaviour makes subdirectory matches odd insofar as the behaviour is dependent on the order of entries in `def.config`.

A couple of minor notes in the spirit of helpful commentary:

• You're creating a global `line` variable while reading the config, using `setopt warn_create_global` is a great built-in feature to highlight these during development.

• You can perform tilde expansion with `${~var}` instead of needing to run sed(see GLOB_SUBST in the zsh docs). This would also make zsh's named directory support work in the config.

• There are shell constructs to remove the need for cut too: First word `${line%% *}`, other words `${line#* }`.

If you want a little background on Ted's answer, the keywords and their use are described in the RCS docs¹. TIL, RCS still gets releases² ;)

¹ https://www.gnu.org/software/rcs/manual/html_node/Concepts.h...

² https://lists.gnu.org/archive/html/info-gnu/2022-02/msg00001...

This site also had a sadly predictable example of the point raised in the history section - https://news.ycombinator.com/item?id=18273530

On a more general level, Christian Brabandt's re-imagining of emacs' region narrowing can be a great work to work files that contain complex embedded strings.

Much like the emacs feature it is useful outside this specific use case too, and it can be a great way to perform heavy edits without needing to care about boundaries and such.

¹ https://github.com/chrisbra/NrrwRgn

I've said this before on here and elsewhere, but I wonder if evil is actually a worse environment because of its utility.

Most attempts at vim modes in other applications seem to be insert or "move" mode, with practically no functionality in what they call normal mode. Whereas evil emulates largely most of vim(far behind normal and insert modes too), but when it does eventually fall down you're really not expecting it. My go-to example for this is using the expression register, the number of times I've typed a vim expression in to emacs when using the expression register is ridiculous.

When tools aren't so functional you're basically always expecting them to fail, so it isn't such a shock when you can't even ciw or whatever. My point -- or perhaps question -- is what is really the better solution; one which almost 100% seamless or one which is practically useless from the outset.

Useful message from the README:

"Note: The existence of unsnap is merely a tool to enable users to switch from snapped applications to flatpak applications. This is not intended as a commentary or slight against any software. It's just a utility."

If you also read that comment tyre fire then I suspect you'll snatch the thanks back ;) Hat tip for the thoughtful replies to the comments on your app, interesting to read as dispassionate observer.

Fair chunk of discussion earlier this week on a submission discussing the app¹.

¹ https://news.ycombinator.com/item?id=30906561

It has only just been released. You can compare the release dates¹ to the package dates² to see how long it tends to take to be packaged and migrate.

¹ https://www.emacswiki.org/emacs/EmacsReleaseDates

² https://tracker.debian.org/pkg/emacs

The piston effect Wikipedia page¹ is a good accompaniment for this, and has tonnes of links to rabbit hole yourself in.

I seem to recall there being some really intriguing TGV tunnel hoods with various suppressor designs to reduce the noise to surrounding villages, but I can't find them now. Anyone know of a good gallery or site for them?

¹ https://en.m.wikipedia.org/wiki/Piston_effect

There was a big discussion about that here too - https://news.ycombinator.com/item?id=30799567

From the GitHub repo¹:

"Maintenance status: The xi-editor project is not currently under active development. Although we will happily accept bug fixes, no new features are currently planned. We would like to revisit writing a text editor again at some point in the future, but for the time being our attention is elsewhere." — The Editors

¹ https://github.com/xi-editor/xi-editor

Loads of commentary on similar submission from the BBC earlier - https://news.ycombinator.com/item?id=30896125

Discussion from earlier - https://news.ycombinator.com/item?id=30896124

Not to take anything away from rich/textual which are awesome, but you can produce a SVG directly if you're using xterm¹. It doesn't produce the cleanest SVG output, but it is quite workable.

The dump-html function also exists in xterm, should you want to remember what XHTML looks like ;)

It would be amazing if either could be used to make quick animated and automated session logs for demos or to attach to bug reports.

¹ https://invisible-island.net/xterm/manpage/xterm.html#Main-O...

In the spirit of p10k speed, you can perform that task without forks:

    $ zmodload -F zsh/datetime p:EPOCHSECONDS
    $ printf "%'d" $EPOCHSECONDS
    1,648,943,504

The creator posted a Show HN with heaps of discussion yesterday¹.

¹ https://news.ycombinator.com/item?id=30879327

The superbase side of the announcement received some commentary earlier https://news.ycombinator.com/item?id=30868849

The HN discussion mentioned in the post is probably this¹, which has a number of useful comments on what other HN users think a README should be(fewer are contradictory than I expected).

¹ https://news.ycombinator.com/item?id=26842191

I've watched this video countless times, and it still genuinely amazes me. Reasonably confident I understand the mechanism, but it just leaves me astounded still.

Even watching it again now the World 1 section is like "what? okay", and then the World 7 part hits in me in the face again. It feels like there is magician about to pull a rabbit from a hat, but it turns out the rabbit is a actual esquilax and the hat was a rainbow unicorn nest and the magician was a ghost from the outset.