Hacker News Reader

Comment by gosub100 | Hacker News Reader

Since the topic is shell, can I shamelessly ask a question?

I'm an SRE for a service everyone has heard of. I have inadvertently pasted into my terminal prompt multiple times now, which has attempted to run each line as a command. I see there is a way to disable this at the shell for each client, but what about at the server level? This way I could enforce it as a policy, and not have to protect every single user (including myself) individually. Said differently, I want to keep everyone who ssh into a prod machine from being able to paste and execute multiple lines. But not forbid paste entirely.

The only thing I could think of would be to recompile bash and detect if the input was from a tty. If so, require at least 200ms between commands, and error out if the threshold exceeded. This would still allow the first pasted command to run, however.

View on HN

Bracketed paste might help you. It's an option for readline so it goes in ~/.inputrc. There's a way to set these options in bashrc as well which I don't remember.

It inserts a control sequence before and after the pasted contents that makes bash not execute all the lines. Instead it will keep them in the command line, post which you can choose to execute all of them in one go with enter or cancel with ctrl C.

Everything you can do in inputrc can be done in bashrc if you prepend "bind". In this case:

  bind 'set enable-bracketed-paste on'

Not an answer to your question but here's a "fun" thing I used to do... If you want to run a program from the CLI, which blocks you terminal (say an xterm), you can use that terminal as a temporary paste buffer. But with a trick.

Imagine you want to run, say, Firefox like that (say because you'd like to see stdin/stderr output of what's going on without having to find to which log file it's outputting stuff: it's really just a silly example):

    xterm>  firefox
    <-- the xterm is now "stuck here" (until Firefox exists)

if you now write, into that "blocked" xterm, the things you write shall execute when you exit/kill Firefox:

    Hello, world!

But one thing I used to do all the time and still occasionally do, first do this:

    xterm> firefox
    <-- the xterm is now "stuck" here (until Firefox exits)
    cat > /dev/null

You can now use that xterm as a temp paste buffer.

So, yup, a good old cat > /dev/null works wonder.

everybody works differently. what seems like a sensible guardrail for you would be extremely annoying for others.

so whatever you do, it should be a feature, even defaulted on. but never a policy that you enforce to "everyone who ssh into a prod machine"

if you find something that works well for you, add it as a suggestion to your developer docs.

all good points, and it's not a great way to "make friends and influence people" by screwing with their workflow. After making this mistake at least twice myself (mainly due to fumbling with MacOS mouse/keyboard differences on my machine), I just wanted to prevent a disaster in the future from me or anyone else. But alas, I just need to be more careful and encourage others to learn from my mistakes :)

Reply on news.ycombinator.com