Make Warning more prominent
colbygk opened this issue · comments
At the risk of ignoring tongue in cheekiness; this warning seems too buried. Also there is a world of difference between "being careful using rm or dd" vs having a simple typo immediately be run as a command vs having to type something fully before hitting enter. I understand the impulse of closing this loop of iterate and see results; doing it this way though seems beyond dangerous.
WARNING: Please be careful when using it! It could be dangerous. In particular, writing "rm" or "dd"
into it could be like running around with a chainsaw. But you'd be careful writing "rm" anywhere in
Linux anyway, no? Also, why would you want to pipe something into "rm"? Other than that, I don't
really have good ideas how to protect against cases like this. And in the other, non-dangerous
cases, I find the tool immensely useful. If you have some ideas how to try to protect, please share!
That said, a tool wouldn't be really Unixy if you couldn't hurt yourself with it, right? ;P
Hm; but what would you like me to say? And where?
I cannot for now think of a way that this could be still useful as it is, while at the same time not being potentially dangerous.
That on the technical side. If you feel just changing the message would be enough: where and how would you suggest to put it? If I put it before I even explain what it is, I feel I could scare virtually everybody away from even trying it, by projecting an ominous first impression. I tried to put it quite early, just after explaining how to enter the command into the app...
Or should I put it straight by the title of the app? How to make it prominent enough? "up - a pipe building app, DANGEROUS, DON'T USE IT"?
One thing I'm starting to think of, is that maybe it's not a good idea to use up with commands that could change any permanent state of something (such as writing to files, modifying/deleting them, accessing external web services, etc...). That might be the main message I'd like to try to publish... but not 100% sure about it yet; I'm just starting to think about it; still in an early stage of trying to collect initial thoughts after the public release, and still getting new feedback.
What I'm trying to also say, is that I actually don't think it's that much more dangerous than xargs or bash. In particular, I haven't yet imagined a command one could easily type accidentally, that could be really disastrous. Even after typing "rm", you still need to type something that you want to remove. I can't yet see how this could be done really accidentally. And again, you usually don't pipe anything into "rm". One may want to try doing "xargs rm"; but then again, I don't see how it'd be easy to do accidentally as of now? And if I were to do this purposefully, I'd be careful even when writing this in regular bash; I wouldn't want to try doing it in up at any cost... like I wouldn't try driving a ferrari through a minefield...
With all that said, I'm totally into trying to invent ways to make it safer. I'm super open to ideas, already collecting some in a notebook, will try to think what to do with them further down the road. (E.g. a shortcut key for pausing/unpausing the "immediate execution" mode.) None of them seem 100% bullet-proof however, unfortunately. But neither bash/xargs are... Hm; actually the pausing/unpausing seems a reasonable cop-out, maybe... then one can choose the preferred mode... maybe even "require enter to execute" would be good enough for typical usage? Even if somewhat slower...
See also: #8
rm could be used with another command that would lead to bad things: find . -exec rm ... and so on. One way to consider this would be for only commands/environments that are idempotent pure, and having that be a whitelist would probably be key and/or combining this with something like linux contexts names, in the form of either docker or whatever container makes sense to share a read-only view of a file system (this could work with OS X as well).
I think it would be fine to merge with #8
Ok, cool, thanks!