Hacker News Reader

Comment by monkellipse | Hacker News Reader

Great idea! Also terrifying :) Given how often I accidentally commit the wrong text in vscode, I shudder to think of the damage I could do with this on my shell, hah! What safety measures are there/could there be?

View on HN

I don't know how painful it would be, but I think I could adapt to a short delay of maybe 50-100ms where the shell won't respond to Return presses, only after accepting a completion. Just long enough ideally to make me re-read what I entered.

A simple approach might be that if the resulting exit code is not 0 it won't be used to complete in the future.

That'd have the problem of tools like grep returning nothing, having an exit code of 1, but being a perfectly valid thing to suggest in the future.

When you're writing, building, and executing code, I would not expect a 0 exit code every time.

The fish approach

Generally, a destructive shell command prompts for approval. But I suppose overfumbly fingers could still cause grief.

Type/command aware tooling is a night and day difference.

Generally? Do you have examples in mind? The ones I think of are destroy first and ask questions only if told to do so: mv cp rm redirection tee

Yeah, you’re right. I was thinking of overly destructive commands eg. reformat etc.

I feel like I've trashed millions of files I shouldn't have with `rm` and trying to be clever with regular expressions.

I've done this enough times I use `ls` first, then `rm`

Yeah, I generally will use `find . -name "<my pattern"` nowadays, just so I can see all the potentially recursive files as well, and then when I'm 100% sure that what I'm doing is good, I will pipe that into xargs or parallel.

My point was that I don't feel like Unix really stops you from doing destructive scary stuff. It seems like it's perfectly happy to let you break your machine.

Exactly, which is why we check for ourselves instead of expecting it to hold our hand.

Unixy tools tend do what you tell them, nothing more and nothing less. No confirmations, no output if successful, no progress bars, etc.

That's a feature in my mind, but I can see how it is easy to have your day ruined if you're expecting it to ask you again.

I mostly agree, but sometimes I wish that `rm` would have default to "confirm before destroying", and add a flag like `-y` to not prompt, more or less like how `apt` works on Ubuntu.

That's actually a way better experience than no confirmation and confirming each item individually.

rm can do that... set an alias to ask to confirm every time.

That's fine on my computer, but if I'm logging into a server I'm not going to do that every time.

As much as we all wish it wouldn't be so, TANSTAAFL. What is your suggestion and how does it maintain compatibility with the existing body of code?

rm doesn’t provide an action summary, does it?

Last time I used the interactive option, it needed me to press Y once for every file.

If you have a list of 200 files you’re probably not even reading by the end.

I wholeheartedly agree that rm -i is a terrible UI. However: what presentation of 200 paths would you not glaze over?

Microsoft gets lots of praise for maintaining Backwards Compatibility even if it's Bug Compatibility, yet POSIX gets shit for the same.

The presentation suggested in this very thread would work better for me. I generally pay pretty close attention to package apt/pacman/dnf output because it is all right there in front of me.

Perhaps ironically, if those programs asked me for each change I would just hold Y until it went away. Needing confirmation of each item is why I glaze over.

This seems worse then remembering, because you still have to remember that your safe-by-default command is unsafe-by-default everywhere you're not usually.

alias rm="rm -i" alias mv="mv -i"

This was in the default when running in interactive shell for Mandrake Linux (way too many) years ago.

Or just add ‘echo’ in front: echo rm ... . Especially when the command is in a loop of some sort.

As much as I can, I do a 'mv ... /tmp' instead of 'rm -rf'. It gets the files out of the way, and provides a way out if that's not what I wanted.

'/tmp' will eventually be cleaned by the OS so no (prolonged) space worries.

To add to this, I've been a happy user of the trash-cli for forever. Can recommend.

/tmp is a RAM disk on many systems so be careful with very large files

kind of the same deal with spooky SQL queries and verifying your where clause with a select first

At least with SQL you can just consistently wrap stuff in transactions, so if you break something you can always revert.

alias rm='rm -i'

I set up hourly borg backups instead. That resulted in me aliasing rm='rm -rf' without a worry in the world. So far, I made about ten recoveries and have never lost important data.

If you never rm’ed work you just did not captured by hourly backups, well, lucky you.

Note: Normal shells use glob(7) expressions, not regular expressions.

You know I googled this immediately after I posted it, and you're absolutely right, but a good chunk of the syntax still kind of looks like regular expressions so I don't think I was too far off!

Regular expressions and glob(7) expressions look superficially similar, but it is mostly an illusion; they both use * and ? as common metacharacters, but both of those characters mean different things in the two systems. Only the [ and ] characters are used more similarly, but even those have their differences. The two syntaxes only have one common function which functions identically in the two systems, but it is invoked by different characters; specifically the ? (question mark) character in glob(7) exactly corresponds to the . (full stop) character in regular expressions.

To be pedantic: You're conflating the syntax of regular exprssions, with the (computer science) concept. Glob patterns are a kind of very resticted regular pexressions. Ksh extended the glob syntax so it has the full power of regular expressions in the computer science sense - though without all the extensions of modern regular expressions.

No, globs are not regular expressions.

“Globs do not include syntax for the Kleene star which allows multiple repetitions of the preceding part of the expression; thus they are not considered regular expressions, which can describe the full set of regular languages over any given finite alphabet.”

— <https://en.wikipedia.org/w/index.php?title=Glob_(programming...>

You're right, normal globs are not regular expressions regardless of syntax. Parent is correct too, ksh globs are regular expressions. See shopt -s extglob in bash, setopt kshglob in zsh (extendedglob for zsh's native, IMO inferior, quantifier syntax).

Reply on news.ycombinator.com