The point is that the order in which that is processed is not left to right.
First the | pipe is established as fd [1]. And then 2>&1 duplicates that pipe into [2]. I.e. right to left: opposite to left-to-right processing of redirections.
When you need to capture both standard error and standard output to a file, you must have them in this order:
bob > file 2>&1
It cannot be:
bob 2>&1 > file
Because then the 2>&1 redirection is performed first (and usually does nothing because stderr and stdout are already the same, pointing to your terminal). Then > file redirects only stdout.
But if you change > file to | process, then it's fine! process gets the combined error and regular output.
TBD - its pretty great... aligned also with continuous deployment:
It allows you to get feedback from customers very fast.
It allows you to improve the software very fast.
It allows you to react to the feedback you just got very fast.
Yes, its tricky! You need fast builds, that give you actionable feedback on whether you did a whoopsie.
Yes, it works for all sorts of things: regulated industries, incl finance, embedded systems, apps, websites, ...
Yes, you do need to rethink how changes happen, to look for ways to make that big change into multiple or even many smaller changes, this often has lots of unanticipated benefits.
Yes, it scales to very large deployments and quite large teams.
The diff tells the 'what' - no point in writing 'added method bob()'
The message tells the why.
You can bet that over time, the jiras, the issues and the confluence, slack, o365, will all have been deleted, "upgraded" or whatever, and all you have is what's in the repo.
Using in-repo ADR, and in-repo 'what's missing, what's next' files are also useful, because they co-evolve with the code.
A lot of "regular expressions" are just text searches, or can be, and then you can use aho-corasick - which is implemented in many languages, and check a few regular expressions for the ones that really are.
Many many things that are imposed like this will fail.
Its not willful non-compliance even, its just that its hard for people to do things differently, while still being the same people in the same teams, making the same products, with the same timelines...
Context is key here, lots of people see a thing that works well and think they can copy the activities of the successful team, without realising they need to align the mindset.. and the activities will follow. The activities might be different, and thats OK! In a different context, you'd expect that.
I'd argue that in most contexts you don't need a QA team at all, and if you do have one, then it will look a lot different to what you might think. For example, it would be put after a release, not before it.. QA teams are too slow to deal with 2000+ releases a year - not their fault, they are human.. need to reframe the value statement.
Regardless of the refrigerant used today the law generally requires you to use a pump and to recover the charge from installed equipment and store it into a cylinder for recycling or reuse.
Prior to the clean air act the advice was to just open the system and vent the old charge into the atmosphere.
Industry was always going to require us to learn _a lot_ of lessons.
But also | isnt a redirection, it takes stdout and pipes it to another program.
So, if you want stderr to go to stdout, so you can pipe it, you need to do it in order.
bob 2>&1 | prog
You usually dont want to do this though.
reply