2 ms·

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

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.

porridgeraisin 2y ago
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.
- teo_zero 2y ago
  Everything you can do in inputrc can be done in bashrc if you prepend "bind". In this case: bind 'set enable-bracketed-paste on'
TacticalCoder 2y ago
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.
fargle 2y ago
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.
- gosub100 2y ago
  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 :)

porridgeraisin 2y ago

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.

teo_zero 2y ago
Everything you can do in inputrc can be done in bashrc if you prepend "bind". In this case: bind 'set enable-bracketed-paste on'

TacticalCoder 2y ago

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.

fargle 2y ago

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.

gosub100 2y ago
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 :)