Try this (tested with zsh 5.9 on archlinux):

    foo='PWD[$(echo hahaha >&2)0]+42'
    [[ "$foo" -eq 5 ]]

I'm pretty sure zsh has an optimization where it skips the indexing if the variable doesn't exist, which happens to sometimes stop this. But since you can just reference variables like PWD, that you know exist, it's not really a security improvement.

Unfortunately it's pervasive throughout the entire codebase (which does a lot of string shuffling).

So it's a historical mistake, but not something to be fixed in the same step as switching the implementation language.

bstr was mentioned as a direction and is a possibility.

Well, yes and no. The moderation features might be the same, but:

1. It's a lot easier to make matrix accounts, especially if you run your own server.

2. The user interface for blocking an entire server is basically missing? The only thing I can find has you run a bot to do it?

So if someone with their own homeserver wants to troll you, you end up playing wack-a-mole unless you self-host a bot. At least that's the best I can find so far.

The last post before this was titled: "MVPy: Minimum Viable Python".

So, since python doesn't have goto, you can't replace while with an if with two gotos (without adding a goto to the language).

You can replace an `if` with a while tho, easily.

This isn't something Manjaro adds.

And xpg_echo is on by default for bash on macOS, so for users on macOS it looks like echo interprets escapes by default.

This is one of the reasons why echo is hopelessly unportable.

See https://unix.stackexchange.com/a/65819/55665

For my uses, I've not found `ninja` to be much faster than `make -j8` on an 8-core machine.

Not that the defaults don't matter, of course.

And yes, then bash starts ls, which is an external program. It might be /usr/bin/ls.

And then ls quits, and bash re-enables bracketed paste because the command might have not enabled it or enabled it and disabled it before quitting. So you get this weird bracketed paste sandwich.

So what's being sent from the terminal to bash here is "ls" (which is echoed back) and then the return/enter key, which bash interprets as "run the command".

So it sends "\r\n" to the terminal (this is "recv" in that notation), which moves the cursor to the beginning of the line and then to a new line to get the cursor off of the prompt line, and then "\x1b[?2004l", which is the sequence to turn off bracketed paste.

Then ls runs and prints "file\r\n", which is the filename "file" on its own line.

Then bash takes over again, reenables bracketed paste and prints the prompt. Notably it does not move the cursor to get the prompt on its own line, so when the command didn't end in a newline the prompt hangs in a weird spot - try `printf '%s' foobar`, it'll show your prompt like "foobarbork@kiwi:/play$". There are tricks to get around this.

Which just does read/write - so it's the same as the "cat-simple" example, which is the slowest listed.

GNU cat [0] does copy_file_range if it can and falls back to a read/write loop otherwise, so it's unlikely to be much slower (possibly some overhead from argument parsing, but that's just a constant).

So the performance claims are wrong.

[0]: https://git.savannah.gnu.org/cgit/coreutils.git/tree/src/cat...

But anyway, the case for `goto` here is that it jumps immediately to the cleanup that needs to happen always.

If you put something between the loop and that, `break` would jump before that and also execute that.

Yes, this is a workaround for C's lack of automatic cleanup (RAII, garbage collection, python's `with` or whatever).

It allows specifying a constraint - that you can't have two rows with the same values even if one of the values is a NULL. That's prohibiting duplicate NULLs. The change allows you to prohibit duplicate NULLs.

Say you have a table (EmployeeName, CarID). You could do a UNIQUE constraint on those two attributes, but that would still allow:

EmployeeName | CarID

Jeff | 2

Kim | NULL

Kim | NULL

Here, "Kim" is car-less (NULL in the CarID field) twice, which makes no sense.

Hence the new constraint.

That's what this change prohibits.

Unfortunately, it doesn't specify those known locations. It explicitly declines specifying that /bin/sh exists.

https://pubs.opengroup.org/onlinepubs/9699919799/utilities/s... says:

> Applications should note that the standard PATH to the shell cannot be assumed to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation of the PATH returned by getconf PATH, ensuring that the returned pathname is an absolute pathname and not a shell built-in.

and it doesn't specify the location of getconf either, so you have a chicken-and-egg problem where you need the standard $PATH to find getconf to get the standard $PATH.

Otherwise, adding tools to the standard library to read file formats required by the ecosystem is a good idea, regardless of whether you agree with the particular format.

You could maybe count the import, but you'd have to do that once and could do multiple bisections, so it's amortized.

Setting the variable doesn't count because you do, of course, need a variable to perform an operation on a variable. Sorting the array also wouldn't count because you can't use binary search if the array isn't sorted.

As a datapoint, CentOS Stream 9 [0], which was released in 2021, and which RHEL 9 (released in May 2022) is based on, is already ~60% out of date according to repology: https://repology.org/repository/centos_stream_9.

Also: In computer time, 8 years is "very old". That's longer than the "mainstream support" window for Windows 7 was (from 2009 to 2015), and about as long as the mainstream support window for Windows XP (from 2001 to 2009).

[0]: CentOS "Stream" has a different release model and appears to be a bit of a rolling release as I understand it? But that would cause it to be more up-to-date, not less.

(I'm a fish developer)