3 ms·
As someone who once inherited a static binary (without debug symbols, gotta save those few bytes) that should have been a shellscript: Please don't. If your log
by c0balt 2y ago
As someone who once inherited a static binary (without debug symbols, gotta save those few bytes) that should have been a shellscript: Please don't. If your logic reasonably fits into a shell script, then put it there.
Posix shell-compatible scripts will also likely work on all platforms where you go program would've been run.
- pstuart 2y agoOr just make sure the source is available.
- mst 2y agoIf a static binary's --help doesn't tell me where the repository lives then I hope the author steps on a lego.
- decasia 2y agoThis is a good idea, will add this to my cli tool :)
- solidsnack9000 2y agoIt is no help to you or your team if they step on the Lego, though.
- bqmjjx0kac 2y agoI mean this entirely depends on how things are done where you work. I wouldn't think the back-reference is necessary if all projects have their own repo in some central location (and it's trivial to match the binary's name to a repo).
- bqmjjx0kac 2y ago> Posix shell-compatible scripts will also likely work on all platforms where you go program would've been run. While I see your point, writing a Posix compatible shell script is not trivial. Little errors creep in that "work on my machine" because /bin/sh is a symlink to /bin/bash, but break the script when someone runs it on macOS. In my experience, you get a lot of cross-platform compatibility when writing Go for zero effort.