Do not use redirection characters in your shell prompt

This seems to be more of "don't paste garbage into a terminal, especially as root." With a sidenote that it might be safer if your custom application command interpreter didn't use > as the prompt character. I note that Bourne shell defaults to the safer % and # characters for the prompt. The # character for root is especially safe.

Yeah. About the only relevant bit is that root prompts tend to use # as part of their prompt precisely to inject a comment character in case of mis-quotes/pastes.

Wow I never heard that! I always thought it was just some arbitrary convention I guess.

Yep (author here), not pasting garbage into a terminal is the main point of this article. Partially, it's a rant against the way-too-trigger-happy "paste clipboard on right mouse click" terminals too.

I decided to finally write this article, after seeing a yet another "mysterious" case of a missing binary in some Oracle database server. Linux/Bash defaults are ok, but historically (coming from traditional Unix background?), people who engineer environments at least in the Oracle database server world, configure their prompts to some "corporate standard". And sometimes they end up suffixing prompts by a nice-looking ">" character, leading to this problem.

I've also seen someone set their root prompt to `root#>`. Since there's no space between the username and #, the "comment start" is not recognized and the redirection clobbering problem is still there.

Well, how about making it hard to do accidental input in the first place? If pasting is a problem the maybe make the actions necessary less possible to be triggered randomly?

I _think_ it started becoming commonplace around the early days of X11, although to be fair # and $ are neighbors on pretty much any keyboard layout.

What about eliminating root usage? Could sudo be used here? Or perhaps every root command should need a confirmation prompt before execution.

Yeah this feels like more of a cautionary tale about proper privilege and directory management.

Was there really a reason for OP to be inside the binary directory for the application in order to use it?

Why was the binary writeable in the first place?

If the binary was not normally writeable but the user was privileged, was it necessary to use a privileged user for this operation?

You could probably create a pretty extensive list of failures that led to this issue. I think the author honed in on the one that made the most sense to himself and missed the forest for the tree.

This is why I hang out here!

Obligatory XKCD: https://xkcd.com/1053/

> # and $ are neighbors on pretty much any keyboard layout

Aside from ISO QWERTY, AZERTY and at least 3 different QWERTZ variants, among others.

I've heard this story before, but I don't think it's true.

I think the bourne shell copied # comments from csh, which had them first. When sh first implemented them, # comments only worked in scripts, not if you typed them at the shell (i.e. if isatty(0), then # wasn't special). The fact that the prompt came before comments, and that comments didn't work interactively really makes the story sound suspect!

I don't know the origin of # in csh, but I would guess it was chosen because it looks like a CPP directive.

Not UK layout; shift-3 is £ and # is next to enter.

\ @ and " are in their proper positions on a UK layout as well. :|

https://external-content.duckduckgo.com/iu/?u=https%3A%2F%2F...

That's a fair point. But in the 90s as a System V and SunOS user, I saw some discussions happen on Usenet, and by the time X was commonplace, the myth/rationale was commonplace.

This is getting to be a tired meme.

While it doesn't apply to shell prompts, there are such things as cultural memory and institutional memory. As a member of a group or society, you are expected to have a certain baseline amount of knowledge of that culture and history.

When I was young, it was considered shameful not to know things. Now the people I work with seem to wear ignorance as a badge of pride. They think that not knowing something means that thing is not worth knowing. As if somehow not knowing something is a good thing.

Because of this problem, good terminals require confirmation before pasting any strings that contain suspicious characters, e.g. carriage returns.

> Now the people I work with seem to wear ignorance as a badge of pride. They think that not knowing something means that thing is not worth knowing. As if somehow not knowing something is a good thing.

That may be the case, due to attitudes encouraged by pop culture, etc. but it's a disastrously incorrect understanding of the comic (and parent comment). They're celebrating learning, which is the exact opposite of 'wearing ignorance as a badge of pride'.

> When I was young, it was considered shameful not to know things.

Shaming something discourages people from admitting it. A child who's ashamed to ask questions will not learn as effectively. They may learn to avoid admitting their ignorance, but that may cause problems later (struggling alone rather than asking for help, possibly leading to damage or injury, etc.).

> there are such things as cultural memory and institutional memory. As a member of a group or society, you are expected to have a certain baseline amount of knowledge of that culture and history.

How do you think the members of those groups have that knowledge? We have not (yet) evolved a genetic predisposition to grow, in utero, neuronal bundles encoding Unix shell prompt escape sequences. That's the point; everyone has all need to learn!

Still, it's better to air and discuss such takeaways!

Even if # isn't / wasn't special, it's still exceedingly unlikely to be a valid program name, nor is it likely for a valid program name to begin with #. The practical effect should be the same as it having been special.

Right, but the story sounds plausible because accidentally pasting '# foo > bar' would safely neuter everything else on the line.

If # isn't special, then the rest of the line is still parsed, so pasting '# foo || bar' or '# foo > baz' does do something.

I don't have reference for that but I always though that CPP directives are preceded by # because the character was previously used as comment delimiter by something (probably csh). In the grand scheme of things cpp is somewhat modern invention. IIRC the first book on Unix programming I had read mentioned in passing that cpp exists but the C code examples in there did not #include anything and if some declaration was required it was just written verbatim in the example code.

There’s a huge gulf between admitting you don’t know something, and being proud of it.

Suggesting it was ever, or should be, somehow “shameful” to admit not knowing something, is an enemy of change and growth, and in everyday life becomes a recipe for perpetuating structural in-groups and all the systemic pathologies that go along with them.

I am also grumpy old fart but I was raised in an engineering culture that was not afraid to ask “what’s a spline?”, and I don’t regret it.

That implies you should put a space before the # in the root prompt, because it's not recognized as a comment delimiter if it's in the middle of a "word".

I don't mind at all when someone admits they don't know something important at work.

I'm frustrated when they admit it 6 months too late.

Ignorance is the norm, but fix it when it's necessary, don't try to hide it.

Even then, though, that was over a decade after the fact, and people were inventing explanations for things retroactively. Doug McIlroy has put the kibosh on this myth.

* https://minnie.tuhs.org/pipermail/tuhs/2017-April/011286.htm...

I have seen a ‘good terminal’, apparently. Can you name one?

Welcome to the world of the Cult of Abstraction. I've never understood the fascination with not knowing what lurks beneath... I've just kind of grown used to it though, and have gotten used to solving the problems everyone else throws their hands in the air over for not knowing how to get deeper.

I mean, I get it in some cases; you don't need to know how things work to use them, but when things go wrong, and they always do, that's when knowing how it works (and not just how to use it) pays off.

Plus, you can articulate questions about things you don't know more effectively.

Two examples: PuTTY and Windows Terminal both present confirmation dialogue boxes before pasting multiline content.

Potentially, but I can pretty much guarantee that someone working on any shell has run into this problem before, and then decided not to change the # because it was so damned convenient for preventing mispastes.

So if someone grabs your hair during a fight, are you going to go bald the rest of your life? Just paste it somewhere besides a terminal. I swear, security people have run away with everyone's good sense.

There's a point of diminishing returns where running with something that can cause a problem is completely practicable and justifiable. We don't need the nteenth "Shell that protects you from malicious paste" functionality. Just use root judiciously. If you can't be comfortable running as root and keeping yourself out of trouble, then you really don't know enough to use the machine safely.

You must be 10% smarter than the piece of equipment. No amount of good natured or well-intentioned "protect you from yourself" coding will obviate you of the need to know what you are doing, the limitations of the machine, and the limitations of the program you're using. In fact, all it does is increase the bar for how many things worth of minutiae you have to account for.

iTerm seems to do this also at least with multi line pastes - and then zsh seems to wait for you to hit enter AGAIN before executing anything.

AFAIK Bourne shell (and Bash) defaults to $ for regular users. C shell (and tcsh) use %.

Also don’t shell script on the fly in a production server that has data of any sort you can’t restore from a backup. It’s one giant game of Russian roulette and eventually the human is going to screw up

In iTerm, Edit -> Paste Special -> Warn Before Multi-Line Paste will disable it if you don't like it. It's probably better to disable it in zsh, but I don't know how to do that. iTerm also provides the "only pop up this warning when I'm at a shell prompt", which is ironically exactly when I don't want it to pop up (since zsh/fish detect it themselves).

I was musing over IPython's behavior right before reading your comment... it's not a terminal, per se, but if you paste in multiple lines, the input switches into a multiline mode. This suggests that bash could handle it in the same manner without relying on a terminal application.

In my experience, the advice "don't paste garbage into your terminal" is about as useful as "don't make mistakes." Sometimes it happens when I forget to hit shift on copying from a terminal, or accidentally holding it while copying from another window. Humans make mistakes. I like seatbelts even though they've never saved my life.

>As a member of a group or society, you are expected to have a certain baseline amount of knowledge of that culture and history.

How is it possible to become a member of the group or society except by hanging out with existing members and learning from them?

>Now the people I work with seem to wear ignorance as a badge of pride. They think that not knowing something means that thing is not worth knowing. As if somehow not knowing something is a good thing.

That comic is saying almost the opposite of that. The comic says that gaining knowledge is a good thing and should be celebrated.

I want to curmudgeonly respond that you’re selling people short. But honestly I’m gonna repeat the theme of the comic.

You’re today’s lucky one, you get to learn something new! People shelter themselves with the familiar all the time. You have too! You started your explanation of your perspective with “when I was young”, and that’s obviously something you’ve held onto.

I’m gonna make your day. Did you know that people, in your life or waiting in the wings, are gonna be grateful for the things you can show them? The only thing you need to do is be just thrilled to introduce it, whatever it is, even if they don’t have the thrill yet.

You just gotta get enough in tune emotionally to know what they’re gonna want to know and how to tell them. That’s a fun new exploration all for you.

Using "unset zle_bracketed_paste" should do what you want, but I've only tried it in rxvt-unicode and the vte-based term I have. It stops zsh reacting to the escape sequences used by multi-line paste, see the docs for a full explanation¹.

If you were to use I'd recommend sticking it behind a "if $TERM" guard so that it you don't end up surprised if you switch to a term that doesn't warn at some point ;)

¹ http://zsh.sourceforge.net/Doc/Release/Parameters.html#index...

PuTTY accepts multiline pastes for me just fine, I use it with nano.

I feel a better takeaway is "people are sometimes going to mess up, if you can do something easy to make those mess-ups less serious, it's probably worthwhile."

Xfce4-terminal prompts for confirmation when there's newline in the pasted contents.

Hmm, wasn't # the default erase character for teletype-era Unix? And @ the "kill" character (like modern ^U)? That would have made them a little annoying to type—not annoying enough to keep them from being used for cpp, though, and https://github.com/memnoth/unix-v6/blob/master/sys/dmr/tty.c... suggests that you could type \#. (There was no "lnext" yet; it was just hardcoded to backslash.)

The actual input erase handling is on https://github.com/memnoth/unix-v6/blob/master/sys/dmr/tty.c.... The relevant struct member is declared in https://github.com/memnoth/unix-v6/blob/master/sys/tty.h#L35 and initialized to CERASE in each tty driver, for example, https://github.com/memnoth/unix-v6/blob/master/sys/dmr/kl.c#..., using the macro defined in https://github.com/memnoth/unix-v6/blob/master/sys/tty.h#L48.

So by default # was special, just to the kernel tty driver, not the shell.