Re: Feature request: PROMPT_COMMANDS array variable

[Chet Ramey]

On 1/23/18 1:23 PM, Daniel Colascione wrote:
> Right now, PROMPT_COMMAND gives a shell command to run before displaying
> the prompt. It's common these days to include in one's bash configuration
> numerous packages from different sources that *all* want to run code at
> PROMPT_COMMAND time. Can we add a new PROMPT_COMMANDS array variable that
> stores a list of shell commands to execute? With a PROMPT_COMMANDS
> variable, different packages can independently add their hooks without
> stepping on each other.

I think the way to go forward on this is to make PROMPT_COMMAND an array
variable in a future version of bash. This is completely backwards-
compatible with current usage.

In the meantime, appending using $'\n' as a separator is the best way to
add commands to $PROMPT_COMMAND.

Chet

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: Feature request: PROMPT_COMMANDS array variable

[Chet Ramey]

On 2/5/18 9:05 AM, Greg Wooledge wrote:
> On Sat, Feb 03, 2018 at 02:57:33PM +0100, Egmont Koblinger wrote:
>> So the use case is: Someone wants to _add_ something to
>> PROMPT_COMMAND. How to do that?
> 
> PROMPT_COMMAND+=$'\n''my new stuff'
> 
> Or, test whether PROMPT_COMMAND is currently empty, and only
> append the newline (or semicolon) if it's non-empty.  But the newline
> should work in either case.

This is one of the options Egmont proposed in the message you quoted.

The downside is slight: "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."

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/

Re: Feature request: PROMPT_COMMANDS array variable

[Greg Wooledge]

On Sat, Feb 03, 2018 at 02:57:33PM +0100, Egmont Koblinger wrote:
> So the use case is: Someone wants to _add_ something to
> PROMPT_COMMAND. How to do that?

PROMPT_COMMAND+=$'\n''my new stuff'

Or, test whether PROMPT_COMMAND is currently empty, and only
append the newline (or semicolon) if it's non-empty.  But the newline
should work in either case.

Re: Feature request: PROMPT_COMMANDS array variable

[Egmont Koblinger]

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

Re: Feature request: PROMPT_COMMANDS array variable

[Daniel Colascione]

Sure, but you have a coordination problem. Everyone is going to use a
different array name, and since scripts have no way of knowing in advance
to what array they need to add their function, we end up the same spot.
Putting the array in the core would solve the coordination problem.

On Jan 23, 2018 7:05 PM, "Clark Wang"  wrote:

> On Wed, Jan 24, 2018 at 2:23 AM, Daniel Colascione 
> wrote:
>
>> Right now, PROMPT_COMMAND gives a shell command to run before displaying
>> the prompt. It's common these days to include in one's bash configuration
>> numerous packages from different sources that *all* want to run code at
>> PROMPT_COMMAND time. Can we add a new PROMPT_COMMANDS array variable that
>> stores a list of shell commands to execute? With a PROMPT_COMMANDS
>> variable, different packages can independently add their hooks without
>> stepping on each other.
>>
>
> I would define my own array var and go through it in PROMPT_COMMAND. (My
> PROMPT_COMMAND is just a function name.)
>

Re: Feature request: PROMPT_COMMANDS array variable

[Clark Wang]

On Wed, Jan 24, 2018 at 2:23 AM, Daniel Colascione 
wrote:

> Right now, PROMPT_COMMAND gives a shell command to run before displaying
> the prompt. It's common these days to include in one's bash configuration
> numerous packages from different sources that *all* want to run code at
> PROMPT_COMMAND time. Can we add a new PROMPT_COMMANDS array variable that
> stores a list of shell commands to execute? With a PROMPT_COMMANDS
> variable, different packages can independently add their hooks without
> stepping on each other.
>

I would define my own array var and go through it in PROMPT_COMMAND. (My
PROMPT_COMMAND is just a function name.)

Re: Feature request: PROMPT_COMMANDS array variable

[tetsujin]

Well, PROMPT_COMMAND does take shell syntax, so if this is just a
question of getting multiple commands in there, you can separate them
with semicolons.

That said, I do think using an array would be nicer (mainly, it's
easier to manipulate the list of commands programmatically) but then
you can't export the variable any more, for instance.

- Original Message -
From: "Daniel Colascione" 
To:
Cc:
Sent:Tue, 23 Jan 2018 10:23:38 -0800
Subject:Feature request: PROMPT_COMMANDS array variable

 Right now, PROMPT_COMMAND gives a shell command to run before
displaying
 the prompt. It's common these days to include in one's bash
configuration
 numerous packages from different sources that *all* want to run code
at
 PROMPT_COMMAND time. Can we add a new PROMPT_COMMANDS array variable
that
 stores a list of shell commands to execute? With a PROMPT_COMMANDS
 variable, different packages can independently add their hooks
without
 stepping on each other.