Possibly #jobs or #remote-jobs for better eyeballs?

Pandoc

Thanks, I'll have a look into that

But the more specific document manipulation you're talking about would probably require scripting pandoc, which might be a pain in the neck

Might be able to put the existing markdown readme into the org doc

and then just convert the entire doc

Emacs batch mode is useful for scripts like this

emacs  --batch --quick --eval "(require 'ox-md)" --eval "(org-export-to-file 'md \"test.md\")"

I didn't suggest it because I assumed Stuart wanted a solution completely independent of Emacs 😅

Nah, I use emacs and like it. Especially org-mode, I wasn't aware you could script stuff like that though!

You totally can 🙂

Voted for “seck” even though I’m clearly wrong, and having been given an opportunity to think about it, I’m not sure if I support my own decision 😛

Something to be aware of - the option "2" comes first, at least on my screen. :)

The first couple people all voted for 2 😛

BTW same could be asked about char and assoc/`dissoc`.

@U03JPRPTSTX Yeah, that's probably why I usually encounter posts where OPs cast bogus initial votes. But then everyone has to be aware of that...

I pronounce char like what happens when you leave food in the oven too long, but I do pronounce assoc and dissoc “correctly”, like assosh and dissosh, not a-sock and dis-sock. And for the animated image format? That’s pronounced “yiff”, if only to end the debate.

@U03JPRPTSTX You might wanna google the meaning of that last word in quotes... :D

seq is the prefix of "sequence" so should be pronounced like that (imo). similarly "assoc" should be pronounced like the beginning of "associate" but beware! different people pronounce it differently :) Rich says "assosh", I say it more like "assose". "assock" is just wrong and I will fight you about it. :) "char" is interesting in that as a prefix, "care" would be closest but seems like "char" like "chargrilled" is also pretty common.

@U2FRKM4TW Oh I’m well aware. Like I said, it ends the debate about gif vs jif quickly!

Seems like I pronounce everything in all the wrong ways, heh. Good thing I won't be a speaker on any conference. :)

I happen to pronounce "seek-uence" but it looks like it should be pronounced "seck-uence" if I understand well?? My primary lang is French; I'm often surprised by syllable emphases, and sometimes observe how they're arbitrarily different based on "your" region. Looking into it a bit more now, it looks like "seek" should be good, no? https://easypronunciation.com/en/english/word/sequence

Ohhhhhhhh forget it, I didn't remark the inversed order of the reacjis, so I agree with the majority. 🙂

You’re correct Daniel, it’s definitely pronounced “seek-uence” in US English, never “seck-uence”.

I pronounce seq as seck but ISeq as iseek

When I first moved to London it was always a dead giveaway that I was new because none of the place names are pronounced anything like they're spelled, and you have to hear someone say it first. It was only when I took the bus to Holborn and the PA system said “Hoe-bun” that I realized I'd been saying it wrong. I definitely struggled with “assoc” until I heard Rich pronounce it “assosh” :) Maybe we need a pronunciation guide?

And what about GUI? I've always pronounced it "gooey" but I just heard my buddy spelling it out as "G" "U" "I".

Char has always just been 'car' to me. But now I realise that makes no sense at all

I say that one like charred. I've had this issue my whole life growing up because I was a huge reader and you just rarely encounter many words spoken out loud vs in books.

"Assosh" sounds just terrible to me. A sock for ever 🧦

@U9J50BY4C This quote stuck with me: “Never make fun of people for mispronouncing a word. It means they learned it by reading.” Unsure of the original author.

Mostly: seck in pt, seek in en sometimes mixed 😅

Fair point!

seek on the streets, seck s in the sheets

In my .sh script I run a command e.g. kubectl blah blah, which over time will emit lines to stdout. At some point, that output will look approximately like this:

...
line 1
line 2
line 3

So tldr I don't know how to grep for multiple lines from a stream, and to quit that stream when a match happens. Also, yes, I know that there are languages nicer than bash :)

kubectl blah blah | while read line; do case $line ... esac; done

does that also support matching

line 1
line 2
line 3

Have a separate monitoring process that does multi-line grep of log every x seconds, and kills kubectl if it finds it.

while true; do
	sleep 10
	grep -Pzo 'line 1\nline 2\nline 3\n' kubectl.log &> /dev/null && killall kubectl && exit 0
done

Untested ☝️

read line dends, you can look at each line, and set some other variable when it matches line 1, then some other when it matches line 2, then if the var for line 1 and line 2 are both set and you match line 3, then you are done

kubectl ... | grep -e line1 -e line2 -e line3 | head -n3 would this terminate kubectl ? (edit: misread the requirement that the lines must be consecutive)

@U45T93RA6 I'll second @U0NCTKEV8’s while + read, with pattern matching inside case. Here is how I am doing it in a project I'm currently hacking on (in Bash :) case-match patterns in an incoming stream of events... • to https://github.com/adityaathalye/shite/blob/master/bin/templating.sh#L159 based on what the event contains • to https://github.com/adityaathalye/shite/blob/master/bin/hotreload.sh#L74 based on events, to feed downstream The other alternative could be multiline sed. e.g. here are expressions that https://github.com/adityaathalye/shite/blob/master/bin/templating.sh#L34 demarcated between known begin/end patterns (which could be Line 1 and Line 3 in your case).

> I should see those three lines consecutively Oh, I just noticed this detail. Choose the while + read + case solution, in which you can maintain a counter and/or flag, and issue the sigquit when your criterion is satisfied. Basically, you need to maintain state through the stream, indefinitely. • You can't do this with grep alone, as far as I know • It could be done with sed, but with much manpage reading. • Also some awk one-liner with still more manpage / tutorial reading :) Edit: Of course one can with the right regex, as walterl wrote above. How silly of me

@U45T93RA6 also beware stdio buffering. I found out the hard way 😅 If you want to sigquit immediately, when the pattern occurs, then run the pipeline with no buffering. stdbuf is https://github.com/adityaathalye/shite/blob/master/bin/hotreload.sh#L37 it.

Thanks all for the suggestions! I will do something along the lines that Walter suggests. I'll invoke kubectl in such a way that it doesn't stream anything, i.e. no --watch flag passed. I'll repeat this invocation in a loop, until the desired match happens. This seems a great simplification of the problem - you turn a stateful, streamy problem into a simple grep of a single, discrete input :)

With this said probably a few good tricks have been suggested, I'll check out shite soon

@U051MHSEK is absolutely right about buffering. alternatively you can use unbuffer (part of expect)

expect could also be used for this but it's some learning

and really the issue with buffering is in the kernel. when something is run outside of a TTY the kernel things you don't need output as quickly since you're not interacting with it and so it buffers (4k at a time last I checked on a linux system years ago). so things like unbuffer/expect trick the kernel into thinking the program is being run within a TTY (using a pseudo-TTY or PTY) and so the kernel doesn't buffer the output between programs. if you're always running your program in a TTY then you don't have to worry as much

it's still a problem for some things, just less of one 🙂

If you go for the grep solution, make sure to add the --line-buffered option

Thanks for that explanation, @U02N27RK69K! I never dug into why.