Hacker News Reader

Comment by wpietri | Hacker News Reader

The author's theory there about user behavior seems dangerously wrong.

I'm quite careful writing command lines because the whole experience of the shell is that of working with sharp knives: you get a lot of power but if you screw up, you'll feel the pain. The point of this tool is to take away a lot of the pain that teaches people caution. Its whole theory is "just try a lot stuff as you explore what you want".

In their shoes I'd look at using some of the container/security magic as a way of nerfing commands. If the on-a-keypress runs work in a way where they can't make changes to a filesystem, that seems way better to me. Even better if the tool then reports, "Would have deleted 532 files in a warning color at the top of the output."

View on HN

> I'm quite careful writing command lines

A safety measure I picked up from a sysadmin while watching over their shoulder: start writing nifty command lines by prefixing them with # first, to prevent havoc when fat fingering the [enter].

Yes, though I prefer: echo ...

The reason is that you'll see expanded variables and wildcards before commiting to them.

But prefixing with echo only disables the first command in a pipeline, while commenting it disables the whole thing.

It also executes command and process substitutions, opens files etc. But granted, it's a useful trick in some cases, after passing the fat-fingering stage.

You can move the echo to the part you are currently working on.

It's a pity you can't do something similar to SQL: when writing UPDATE/DELETE always write the WHERE clause first

Something I learned early on when writing possible dangerous SQL selects:

  CREATE TABLE mytable_backup AS SELECT * FROM mytable;
  SELECT * FROM mytable WHERE condition;
  DELETE FROM mytable WHERE condition;

Or just let the DB work for you with BEGIN; + (select/update/delete) + COMMIT; or ROLLBACK;

What I like about SQL is that it's got the double safety of ";". To accidentally run a SQL statement before it's ready in a command line, you'd have to both add the ";" AND hit Enter, or have the bad practice of adding ";" before the statement is ready, or use a bad SQL command line that sees the ";" as optional.

I always start a session with BEGIN, write UPDATEs/DELETEs as SELECTs first and (if possible) use a staging database until I'm fine with the result.

In SQL, you can at least wrap the whole thing in a transaction. Then, just roll the whole thing back if anything came out wrong.

I usually SELECT COUNT(*) WHERE ..., and only subsequently overwrite with DELETE.

Thanks for the tip, I'll definitely be using this. Fear of accidental rm -rf * keeps me up sometimes.

Looks like you need to know about the 'sleep' command...

unzip; strip; touch; finger; grep; mount; fsck; more; yes; fsck; fsck; umount; sleep

`fc` helps. Setting `FCEDIT=ed` helps a lot.

This command can be dangerous itself.

For those who don't know... "The fc utility lists or edits and reexecutes, commands previously entered to an interactive sh."

Reply on news.ycombinator.com