Careful with rm:
r
rm
rm -
rm -rf
rm -rf ~
rm -rf ~/
rm -rf ~/tmp
# where did my files go? r
rm
rm -
rm -rf
rm -rf ~
rm -rf ~/
rm -rf ~/tmp
# where did my files go?That said, I'm starting to think — should I include a note about the potential dangers in the readme?... they seemed glaringly obvious to me (at least in case of rm-like commands), but can there be readers/users, to whom they'd not be obvious?...
edit: Ok, I tried to add a warning in the Readme, that's something I can do easily, and if it helps someone, worth it...
Even rm has a -f flag to override some safety measures, though the defaults aren't very safe.
(Though it would complicate installation which is effectively non-existent since there is a single binary; and tightly couple the application with the environment. It's a trade-off anyway.)
(Edit: Somebody mentioned the user "nobody" which seems to be a better alternative.)
In any case I think that the whitelist approach would work better as it would be nice if the tool knew in advance which commands work properly and which ones don't. That way it could inform its users about the allowed & unallowed commands.
Commands with side effects (or "impure" in the FP terminology) don't make much sense anyway to be used within this. The main value is fast iteration, in order to verify the expected output of the pipeline. For me it doesn't make much sense to use it with commands whose main purpose is to modify the filesystem instead of generating / transforming data and writing it to stdout.
So the criteria for the commands that would make it into the whitelist may be "not having side effects", "writing to stdout", and optionally "reading from stdin".
Fastly iterating side effects is unsafe as well, as has already been pointed out.
This can be a fine data analysis tool actually, unfortunately only for command line geeks. The experience is actually not so far from analyzing data with VIM interactively by piping it to an external UNIX command and getting the result dataset back into the editor. VIM hackers will know :)
In a world in which shell commands respected the UNIX philosophy, "find" wouldn't have a silly option like "exec", and other commands wouldn't mix read / write / pure data transform operations in a single command.
But it is what it is. So yeah, protection probably needs to be implemented in the user level, for maximum safety.
Maybe an alternative and/or complementary solution would be to profile each inputted command to detect if they are attempting write operations (maybe with "strace" or something like that), and cancel the evaluation of the command in the next iterations and/or show a warning.
A single-purpose user with its own group would have this problem only to a lesser degree (you'd be able to mess with other users' "up" invocations, but not any system processes).
Do you mean something like this?
:r! lshw | grep network -A2 | grep : | cut -d: -f2- | paste - -
:r! lshw | grep network -A2 | grep : | cut -d: -f2- | paste - -
- Open vim with the output of `lshw` as content:
lshw | vim -
- Send the whole content of the buffer as standard input to the given command and rewrite the buffer with the data read from the standard output of it:
:%! grep network -A2
:%! grep :
:%! cut -d: -f2-
:%! paste - -
Since the dataset returned by the last command will be visible in the current buffer, you will be able to examine & play with it full screen. You will be able to clean or transform some parts manually (this is frequently needed in data science).
You can always return to the previous/next dataset by pressing u/Ctrl+R (for undo and redo), and examine your command history by pressing ":" and then Ctrl+P/Ctrl+N. (Or you can open the command history quickfix menu by pressing "q:" to view/copy the last several commands at once.)
And since you are in a full blown text editor, you can take advantage of other helpful features such as folding, saving the current dataset to a temporary file, etc.
If you are comfortable with more than a few UNIX filters, VIM can be a very convenient and fun tool to play with data.
Could you have this command run as user “nobody” by default, and have a flag to run as a real user? Or as others have mentioned, use capabilities on the spawned processes to prevent anything other than standard input/output?
But if there is a way for you to drop the capability to modify the filesystem before running the first pipeline, you should definitely do it by default (and provide a switch to override it if somebody knows what they are doing.)
Strukt doesn't do 'rm' yet (and nobody has ever requested it), but it does have other operations that do writeback. Once you add one, automatic updates are disabled, and you have to explicitly run the pipeline each time you want it run.
We really need a new cross-platform low-level framework for lego-like operations, like shell commands but updated for the 21st century.
WhatIf instructs the command not to make any changes, but merely to log what it would do. You can "Remove-Item C:\Windows -Force -WhatIf" and it will output "What if: Performing the operation "Remove Directory" on target "C:\windows"" but not delete anything.
(implementing support for "whatif" is optional, so you can't casually use it on any given cmdlet without first checking that cmdlet supports it and makes sensible use of the parameter instead of ignoring it, but the idea is there).
(That's the common Unix shell name for it, though it's not entirely consistent -- which is another problem with using Unix built-ins!)
One thing I've noticed is that it's really frustrating (and not at all helpful) to require perfect validity from a shell-like tool. There's just too many times where you want to edit something into something else, without needing to find a perfect path of valid and meaningful syntax at every intermediate step. So if you have a flag on an operation that doesn't understand that flag, the flag will have a (?) badge to indicate that it won't be understood or used, but the pipeline will still run.
Meant to type:
rm -rf node_modules && npm install
Answer: *
Actually typed
rm -rf node_modules ** npm install
Theory is: rm is dangerous and should not be used day to day.
It's always been surprising to me that their isn't a built in "undo" to `rm`
e.g. why doesn't `rm` just move files to /tmp?
And do what when tmp gets full and services & applications start crashing?
When someone implements that undo, someone's going to need to write a tool that really does remove files, really. Will the next guy wonder why really-rm doesn't have undo built in?
Same question as parent: "And do what when tmp gets full and services & applications start crashing?"
It's not rocket surgery.
We could all just work with WORM drives instead.
The default rm doesn't do this because shell users are supposed to be able to figure out how not to delete things they want to keep.
Kind of like not pointing a gun at people who you don't want to kill.
The undo for rm is regular backups.
On my system I have snapshots of my home directory created every 15 minutes. Not quite the same thing, but it also helps me when I have incorrectly modified a file.
I don't do this because my idiocy must be punished disproportionately. Also, you end up automatically pressing y enter.
Aliases can be way more dangerous; think about what you're doing. This is what backups are for.
Have a look at either the `trash-cli` package by Andrea Francia.
I don't think I'd ever want to use this tool. Every keystroke could be an arbitrary command, and I wonder about the performance of commands with a lot of I/O or processing.
Conceptually it's really neat and I get it, but practically I find things like parameter completion in Fish much more useful.