3 ms·

A common response here is to bash Adobe for its lax approach to software quality. I think it would be better for us to look in the mirror and ask ourselves what

A common response here is to bash Adobe for its lax approach to software quality. I think it would be better for us to look in the mirror and ask ourselves what we can do to improve the robustness of our own software. A few ideas: - For production code, categorically reject any language that will happily treat an unset variable as an empty string. Or, if possible, configure the language implementation to run in a stricter mode that fails fast instead. Question: Is that possible with shell or PHP? - Favor manipulation of data structures over concatenation of strings. See Glyph Lefkowitz's blog post "Data In, Garbage Out" [1]. When manipulation of strings is practically unavoidable, as with filesystem paths, use a well-tested library such as Python's os.path module or .NET's System.IO.Path class. - Embrace the principle of least authority at every level. For example, when developing for the Mac, work within the Mac app sandbox as much as possible. Any other ideas on how to prevent this kind of catastrophic bug? [1]: https://glyph.twistedmatrix.com/2008/06/data-in-garbage-out.html https://glyph.twistedmatrix.com/2008/06/data-in-garbage-out....

emilburzo 11y ago
> Is that possible with shell [...] #!/bin/bash set -eu <actual work> Explained: -e Exit immediately if a simple command exits with a non-zero status, unless the command that fails is part of an until or while loop, part of an if statement, part of a && or || list, or if the command's return status is being inverted using !. -o errexit -u Treat unset variables as an error when performing parameter expansion. An error message will be written to the standard error, and a non-interactive shell will exit. -o nounset Worth a read: http://ss64.com/bash/set.html http://ss64.com/bash/set.html
- mioelnir 11y ago
  There is also the variable-expansion abort, even with optional custom error message: "${VAR:?Error message goes here}" Will exit2 if VAR is unset or the empty string. Or, which I often use, build the path you want to delete, call realpath on it - then check if your base directory you never ever have any business leaving is a prefix string of the realpath resolved path. This still allows to symlink stuff into subdirectories but will catch if something resolves suddenly all over the place.

emilburzo 11y ago

> Is that possible with shell [...] #!/bin/bash set -eu <actual work> Explained: -e Exit immediately if a simple command exits with a non-zero status, unless the command that fails is part of an until or while loop, part of an if statement, part of a && or || list, or if the command's return status is being inverted using !. -o errexit -u Treat unset variables as an error when performing parameter expansion. An error message will be written to the standard error, and a non-interactive shell will exit. -o nounset Worth a read: http://ss64.com/bash/set.html http://ss64.com/bash/set.html

mioelnir 11y ago
There is also the variable-expansion abort, even with optional custom error message: "${VAR:?Error message goes here}" Will exit2 if VAR is unset or the empty string. Or, which I often use, build the path you want to delete, call realpath on it - then check if your base directory you never ever have any business leaving is a prefix string of the realpath resolved path. This still allows to symlink stuff into subdirectories but will catch if something resolves suddenly all over the place.