Hi, I'd like to second this feature request.
As Daniel mentioned, the biggest problem with the current single variable approach that it's hardly usable due to lack of coordination between distributions as well as apps that wish to modify PROMPT_COMMAND. Let's look at it at more details. There isn't a single entity somewhere who decides what should go into this variable. Instead, various utilities all want to append their stuff. My two open source hobby projects happen to be GNOME Terminal (VTE) and Midnight Commander, both of them tamper with this variable. VTE (from /etc/profile.d/vte-2.91.sh) adds the emission of OSC 7 to notify the terminal emulator about the current working directory (and also emits OSC 0 to set the window title which it probably shouldn't do), see [1] and [2] for some pending (stalled) refactorings/bugfixes around this area. Midnight Commander uses it for some subshell magic, see [3] for a recent change. So the use case is: Someone wants to _add_ something to PROMPT_COMMAND. How to do that? The obvious approach is to append to this, using semicolon as the separator. Now, I don't think this can work. Is a non-empty PROMPT_COMMAND supposed to contain a trailing semicolon or not? If you expect parties to append to this variable without any coordination, you cannot know which one others go for. If it doesn't contain a trailing semicolon, you obviously MUST add one in order to append. It if contains one, you MUST NOT add it, since two semicolons next to each other (even with whitespaces between) is a syntax error. So shall we figure out if there's already one?? Strip trailing whitespaces, then see if there's a semicolon, then see if it's backslash-escaped, then see if that backslash is backslash-escaped...?? Practically impossible. So what can you do instead? You can append using newline as the separator, works reliably, the slight drawback is that the output of a simple, unquoted «echo $PROMPT_COMMAND» is pretty confusing. And, of course, this is not a solution that suddenly occurs to everyone as trivially as appending to an array. (Mind you, the previous problem is probably not a problem that occurs to everyone, either.) Or you can reliably prepend. As a consequence, if let's say you do it from /etc/profile.d/*.sh, in the rare case when the order of files there does matter (and hence the filenames are properly prefixed by numbers), the order will be the exact opposite of the desired one. Now, let's say a distribution sets up PROMPT_COMMAND to do a couple of things, and as a user you don't like one of them. For example, you don't like gnome-terminal setting up the window title for you (hell I don't like that), or there are a few folks who don't like new windows opening in the previous one's directory. So they'd want to _remove_ an entry from PROMPT_COMMAND, ideally without having to manually duplicate (and maintain through the years, through installation/removal of packages etc.) the rest. If whoever adds something to PROMPT_COMMAND thinks about it, and solely invokes a function whose only purpose is to be invoked from PROMPT_COMMAND and isn't used anywhere else, the user can redefine this function to be empty. Without any lack of coordination, I don't think many providers would think about it. So then you'd need to remove an exact entire entry, between two unescaped separators (semicolons or newlines) or the beginning/end of the string, hell no. Or, just remove an entry from an array, which is much simpler. Looking at an entire ecosystem, like a distribution with its shell initialization files, and various apps shipping extensions to it, maintaining a single scalar is just a total nightmare, maintaining an array would be the clean way to solve this. Let alone the case when someone adds something with syntax error, then the rest (further additions) won't work either. I don't think it's an important issue to worry about, but still. (Sorry for not cc'ing those earlier on the thread, and for this email not showing up nicely in the thread index, I have no clue how to properly reply to an email just by seeing it in the web archives.) Thanks, egmont [1] https://bugzilla.gnome.org/show_bug.cgi?id=704960 [2] https://bugzilla.gnome.org/show_bug.cgi?id=743073 [3] http://midnight-commander.org/ticket/3534
