3 ms·
>it will be written so that it first defines everything as functions and then at the very end makes a single function call. This ensures that the script will on
by Arnavion 4y ago
>it will be written so that it first defines everything as functions and then at the very end makes a single function call. This ensures that the script will only do anything if it has been completely downloaded.
This is not sufficient. More care is required.
lsp_init() {
...
}
lsp_init
If the last line gets truncated between the `s` and the `p`, then `ls` gets executed. Of course `ls` is harmless, but I'm sure you can imagine how it could be worse.
In other words, not only do you have to wrap your script in functions, but you have to ensure that any top-level function / command invocations are named such that they do not become different commands if truncated.
This is unsolvable in general, because the user can have any arbitrary names in their $PATH , such as custom personal utils in ~/.local/bin which can have any unforeseeable name.
It's much easier to just wrap the script in `()` to make it run in a subshell. bash will not run anything until it sees the closing `)` so truncated scripts are not a problem, and it also doesn't have the name collision problem.
- rascul 4y agoHow would it become truncated?
- bqmjjx0kac 4y agoA cat unplugs the router?
- layer8 4y agoWhen a dog does it, would it be trundoged instead?
- deleted 4y ago[deleted]
- fathyb 4y agoIn the case of curl it can happen if the server did not use Content-Length and the connection gets closed.
- Arnavion 4y agoAll the presence of the content-length header would do is change curl's exit code when the connection breaks. The part where curl output the truncated script and bash executed it would be unchanged.
- Arnavion 4y agoThe whole context of this conversation is >If the connection fails for any reason, the script will stop, potentially breaking or corrupting things.
- Analemma_ 4y agoI've heard this theory before-- that a command could get cut off halfway and execute something really bad-- and tbh I'm skeptical that this has happened even one time in all the billions of invocations of curl|bash. It's just not worth worrying about, in the same way that a cosmic ray bitflip could cause a kernel bug that erases my entire drive but in reality I don't spend any time worrying about this.
- Arnavion 4y ago>It's just not worth worrying about For you, apparently. Other people do worry about it, which is why they do take care to wrap their script in functions. And my point is there's an even easier and more foolproof way than that. >in the same way that a cosmic ray bitflip could cause a kernel bug that erases my entire drive but in reality I don't spend any time worrying about this. Other people use ECC memory because they worry about this, and because it does measurably happen.
- a1369209993 4y ago> If the last line gets truncated between the `s` and the `p`, then `ls` gets executed. My shell[0] dies with a error "source file did not end with a newline". This is easily solvable in general, regardless of what's in PATH, as long as the shell works correctly. Valid text files do not end with bytes other than 0x0A. Being truncated at the end of a line, on the other hand, is not manifestly obviously a error. 0: That I wrote, because of bugs other than this one in bash et al, such as $FILE_WITH_SPACES; not just "my shell that I use".