In bash, this would also print "hahaha" with "a" (or any other possible variable name) instead of "PWD", that's why many think it doesn't work at all in zsh.
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.
>Matrix's moderation should be at least as good as Gitter
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 idea behind this series of posts is to see how much of python, concretely, is syntactic sugar and how much is necessary. How much could you do with e.g. doing macro transformation on top of a minimal core?
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).
Tbf python isn't exactly a language that's high in sugar to start with, it doesn't even have switch statements. Not sure why you'd want to take away even more until there's nothing usable left. People have the weirdest hobbies hah
I wouldn't exactly call something only available in 3.10 as something python "has". Most of us haven't moved past like 3.8 at best, some still using 2.7 for legacy stuff even.
Waiting for the solution that involves transforming Python code into an encoded Turing machine and implements a minimal UTM in some tiny subset of Python.
And I wish we had a stronger word than unportable for echo. You see that word tossed around on shell scripting resources where the only system it applies to is a 30 year old version of ksh and it only blows up on a full moon when passed a filename with a literal form feed \f, but echo is a practical portability problem.
One issue is that make will default to only using one job (i.e. one cpu), and you need to pass `-j NUMBER` to make it use more, while Ninja is parallel by default.
For my uses, I've not found `ninja` to be much faster than `make -j8` on an 8-core machine.
I'm surely also in that range. It took us years to write this project, but 57 C files is a small project. Others find themselves in the range where the build decision-making itself can take seconds, with tools other than ninja. Ninja is pared down for speed; having to declare keywords before I used them made me feel young again.
I had to write these build files over again, and I just couldn't stomach the idea of writing another makefile.
"\r", "carriage return", is what the return/enter key sends (either that or "\n", it's configurable).
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.
I think bash actually sends just "\n", the LF-to-CRLF translation is handled in the tty driver (it used to be part of the kernel, but no longer. Funny how Linux still has to translate text to use the so-called "Microsoft line endings" when it comes to terminals).
This is correct, but they're only "Microsoft" line endings (CR+LF) when you're encoding a text file. When output to a terminal, they're literal instructions:
CR - carriage return - escaped as \r - move the carriage to the beginning of the line (the "carriage" is the print head of a line printer, think an old dot-matrix or a typewriter)
LF - line feed - escaped as \n - advance the paper one line.
Since all on-screen terminals are "virtual", these are translated to cursor movements. But their origin is in paper output.
If you've ever
seen text that
gets printed like this
...it's because the \n LF line separators in the output aren't being translated to terminal instructions, just dumped raw.
MS decided that both should be kept in text files; Unix-ish dropped the carriage return to use \n; MacOS before OSX used only \r.
There are also (text-based) network protocols; almost all of them use CRLF as line breaks since time immemorial because "text is something that can be sent straight to the teletype and should be shown all right". UNIX decided to break with this tradition, others like DEC, and CP/M, and then Microsoft, decided not to which is why I put "Microsoft line-endings" in quotes: reasonably, they are just "line-endings", have always been, and then there is the "UNIX line-ending convention".
After we press the return/enter key to tell bash to "run the command", is bash doing everything from here (ls is not part of this bash part right?) including switching off the bracketed paste and re-enabling it?
Bash also turns off the bracketed paste, because it can't know if the command it is about to launch supports it. So that command would have to re-enable it itself. Something like emacs or vim might do so (or another bash, you can nest shells).
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.
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).
> Your code is missing braces around the `if` blocks
Sure. It's obviously a sketch.
> If you put something between the loop and that, `break` would jump before that and also execute that.
Sure. But I rarely can see a need to make it so complicated (not in this case anyway). If you need multiple distinct cleanup sections that can't be inlined, then label them all (or put them in separate procedures) and jump to them explicitly. In my example, there is no need for any labels at all.
> this is a workaround for C's lack of automatic cleanup (RAII, garbage collection, python's `with` or whatever).
Try this (tested with zsh 5.9 on archlinux):
In bash, this would also print "hahaha" with "a" (or any other possible variable name) instead of "PWD", that's why many think it doesn't work at all in zsh.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.