Ideally, scripts that are in any danger of being truncated are supposed to be wrapped in immediately invoked functions exactly because of this gotcha, and most (but not all) of those that I inspect before running often are.
that's a very interesting point and example. TCP is normally lossless and byte-for-byte before data is forwarded to the application. I think your example may illustrate a loophole - truncation.
It'd only work if, like your example, it was the truncation that caused the flub. You can't have random corruption.
Does curl in a pipeline really behave that way - if the connection is interrupted (TCP RESET), does it just end the pipe? It probably actually does, from what I see.
It's an interesting edge case.
Personally I use, which would seem more immune:
curl -o /tmp/a
vi /tmp/a
{get bored easily, fuckit}
sh /tmp/a
Could be confirmation bias/rage on my part of course, but I never took...
> Some people took the “don’t curl | sh” advice as “you have to inspect every line of a shell script installer you download”, which is of course absurd.
... to ever mean anything BUT "inspect every line". Which is, as you say, completely absurd.
Some people took the “don’t curl | sh” advice as “you have to inspect every line of a shell script installer you download”, which is of course absurd.