New behavior: PREEXEC_COMMAND If set, the value is executed as a command prior to executing entered commands in interactive mode Old behavior: PROMPT_COMMAND If set, the value is executed as a command prior to issuing each primary prompt. With this patch it is eg. possible to set the *term Title according to the currently used command (eg. vim). [PREEXEC_COMMAND='echo -en "\e]0;${CMD[*]}@madpc\a"'] Right now its only possible to set the Title _after_ the command is finished. This allows us to have nicer bash-titles. I dont think something is borked by this feature. Patch can be downloaded at http://rvb.dyndns.org/scripts.shtml ftp://rvb.dyndns.org/pub/patches/bash-2.05b-preexec-0.3.diff.gz (its not my patch) Greets Reproducible: Always Steps to Reproduce: 1. 2. 3.
Any idea how this might affect Portage's title settings effects?
I like this. I just installed the patch modifying the r9 ebuild locally and it works fine. Anything against including this?
is there an updated patch for bash-3 ?
*** Bug 50888 has been marked as a duplicate of this bug. ***
well the website is gone, the patch wasnt attached here, and no info about whether this even works with bash-3
*** Bug 90431 has been marked as a duplicate of this bug. ***
Reopening since the website is available now. Also I can confirm that the patch works against bash 3.0. (and sorry for the dupe).
thanks, we'll see about integrating it then
added to bash-3.0-r10
ok, bad news, this doesnt play well with bash-3.0 check this simple test case: $ alias blah='ls;ls' $ blah& Segmentation fault if someone feels like taking care of this i'll add it back in, but for now i've released 3.0-r11 with the preexec patch stripped
on a side note, it'd be best if we changed the new reserved 'CMD' array to something less generic some people use that in their scripts plus it'll break things like xterm (see Bug 90834)
I'll take a look at the patch and I'll try to spot the problem.
Created attachment 58049 [details, diff] fixed preexec patch Well I've attempted to fix the bug. I'm no C/bash expert so this should be considered a Very Ugly Hack (tm) unless someone more skilled reviews it properly. It Works For Me (tm) but it's just a workaround. I'm attaching the new patch just for the records. This is my addition to the code btw: + if(command->flags == CMD_FORCE_SUBSHELL) + command = command->value.Connection->first; + return;
there's still the issue that the array is named 'CMD' ... anyone have suggestions for less-generic but still intuitive names ?
Created attachment 58338 [details, diff] new preexec patch Here's the previous patch with s/CMD/PREEXEC_CMD/. That's a very specific name that shouldn't affect any other setup, this way it's also consistent with the other variables introduced by the patch.
can someone explain to me what PREEXEC_CMD is for/how it's used ? PROMPT_COMMAND is run just before displaying the prompt ... PREEXEC_COMMAND is run just after typing in something in the shell ... so what is PREEXEC_CMD for ?
From the patch: PREEXEC_CMD Is set before a command is run, each array field corresponds to one argument of the command line. It is intended to be used in PREEXEC_COMMAND scripts. In case of pipe-commands the command line of the last command in the pipe-chain is stored in PREEXEC_CMD.
yes, i read the docs, but i dont understand them :P
Heh ok :) That PREEXEC_CMD command can be used to set the prompt with the executed command. That's something that couldn't be done with PROMPT_COMMAND since that is executed *before* the command is parsed. So PREEXEC_COMMAND is ran after the command is typed on the prompt but before execution and its name is put in PREEXEC_CMD. That way we can use something like: export PREEXEC_COMMAND='echo -ne "\033k\033${PREEXEC_CMD[*]}\033\134"' export PROMPT_COMMAND='echo -ne "\033k\033\033\134"' for setting the window title (in screen and/or xterm) with the name of the running command.
I've been using the patch for a while without issues, can we bring this back in an unstable version for testing?
after 3.0-r11 goes stable i'll make a -r12 with this
Any chances of seeing that -r12 now? ;)
maybe ... i sent this to bash list a little while ago for review
i'll let this unfold upstream
