2021-07-10
Why Bash and GNU Readline's "bracketed paste" mode is not for us
Last month, we discovered that recent versions of Bash and GNU Readline now default to special handling of pasting into them. This is called "bracketed paste" mode; it requires you to explicitly hit Return in order to have the pasted text accepted and allows you to edit the paste before then. Locally, we have decided to turn this off for the root account, and I've also turned it off for my own account. We have pragmatic reasons for our collective decision, and I also have a broad general reason for my own account.
Our pragmatic reason is that we are almost always pasting from our own instructions, which we obviously trust. In addition, we do this sort of pasting quite a bit. Since our own source text is trusted, an extra step to accept them is both annoying and almost certainly ineffective at avoiding mistakes. Since we know the source is trusted, we're extremely unlikely to pause, look at what we're about to hit Return on, and realize we've pasted the wrong thing, especially since we do this all the time.
(People are extremely bad at spotting the one in a thousand exception to routine processes.)
My broader personal reason is that bracketed paste quietly clashes with the xterm model of fast cut and paste. Xterm and things that imitate it are specifically set up so that you can cut and paste entirely from the mouse; you use the left and perhaps right mouse buttons to make your selection and then the middle mouse button to paste it. Bracketed paste doesn't just require an extra step, it requires you to use the keyboard. On top of that, right-handed mouse users with normal keyboards either have to move their right hand from the mouse to the Return key or reach over with their left hand to hit Return.
Bracketed paste probably looks better to laptop users (where the 'mouse' is below the keyboard) and to people who use Copy and Paste through the keyboard with Ctrl-C and Ctrl-V. But for xterm users who trust the source they're pasting from, I suspect that the inconveniences outweigh the occasional advantage of being able to edit what you're pasting to alter it a bit before it takes effect.
(The traditional way to be able to edit what you're pasting in xterm is to not select and paste the trailing newline. However, this usually requires you to use a slower selection method than just triple-clicking the source line.)
PS: What I would actually like is a way to invoke bracketed paste in xterm when pasting, for example with shift plus the middle mouse button. This would improve the convenience of pasting things that I want to edit after pasting, because I could freely select things with newlines but still modify them before they act.
University computer accounts are often surprisingly complicated
In many organizations, the life cycle of computer accounts is theoretically relatively straightforward. Your employees have an official HR start date, at which point their account comes into being, and eventually they will have a departure date, at which point their account goes away. There are wrinkles, but you can mostly get away with driving your account system from HR data. Often it's explicitly a good idea to do this, to make sure that people who are no longer employed also no longer have computer accounts (or at least access to them).
This is not how it goes in a university, at least on the research side of a university department (the teaching side is more straightforward). To start with, people have all sorts of relationships with the department that creates computer accounts; there are professors, graduate students, staff, postdocs, research assistants and research staff hired by professors, undergraduates doing research work with a professor or a group, research collaborators from inside or outside the university, visiting researchers, and more. Many of these relationships are not recorded in the university-wide HR and student information systems, and the university doesn't necessarily want them to be (especially for things like who is collaborating with who for research). Some of these people don't have any formal association with the university that would be reflected in university-wide HR systems, as they aren't being paid by the university, attending as a student, or otherwise officially recorded as being eg a 'visiting professor (status only)'.
When people have relationships that are officially recorded, such as being professors or graduate students, the start date of their official relationship may be well after we want to give them a computer account. For example, when new faculty are hired into the department, they have an official start date that may be some time in the future, but the department usually wants to start integrating them right away, so they can both feel welcomed and hit the ground running. The same is true for end dates in many cases. For example, just because a student has graduated doesn't mean that they've stopped interacting with people in the department and should be cut off by having their computer account closed. Some sorts of official relationships can go on hold for a while, such as a graduate student taking a leave of absence, and when this happens we definitely don't want to remove their computer account.
(In addition, the end dates of even the formal associations like graduate students graduating can be uncertain and changeable. People usually don't finish their thesis and thesis defense on an exact schedule that's known well in advance and never changes or slips.)
Complicating the life cycle is that people frequently move back and forth between different relationships with the department. In an extreme example, an undergraduate doing work with a professor can become a graduate student, then a postdoc, then a remote collaborator, and then come back to be faculty themselves. Graduate students can be hired as (part-time) staff, and then sometimes they become full time staff and no longer graduate students.
Visitors are their own collection of complications. Visiting researchers may be here for an extended period or just a flying visit where they're around for a week. They aren't necessarily from another university, since plenty of research is done in industry. They may have already collaborated with professors here and been given computer accounts, or they may not. Currently, they're often not entitled (by the university's standards) to have a university-wide identifier. Even if they are entitled to one, they may not be here long enough to go through the process for getting it (or be able to wait that long). And once they leave, we generally don't want to just delete their computer accounts, because they might either come back later or at least become collaborators.
A general theme of all of this is that the research side of an academic department runs on a broad network of relationships with all sorts of people that are developed and cultivated over time. Generally one of the last things the department wants to do is reduce those relationships through things like denying computer accounts or removing them. When graduate students or postdocs go off into the world, when visitors go home, and so on, the department wants them all to feel still connected to the department as much as is reasonably possible.