| Summary: | emerge produces error if $PROMPT_COMMAND ends with a newline | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Tom Schumm <gentoo> |
| Component: | Core | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | Keywords: | InVCS |
| Priority: | High | ||
| Version: | 2.1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 181949, 187293 | ||
| Attachments: | use os.system() instead of commands.getoutput() | ||
|
Description
Tom Schumm
2006-07-05 19:01:09 UTC
Python people, can you take a look at this? The commands.getoutput() behavior seems to behave like one might expect according to the docs where it says cmd is actually run as { cmd ; } 2>&1:
http://docs.python.org/lib/module-commands.html
Why would $PROMPT_COMMAND to end with a newline anyway? I suppose we can simply strip whitespace from it before we pass it to commands.getoutput().
OK, I guess since I'm the original reporter, I should elaborate.
PROMPT_COMMAND is typically used to set the xterm title, and that's how it's used in a default Gentoo installation (i.e. a single echo command with some escape sequences in it.) But it is actually allowed to contain an arbitrary bash script, which can be used for fancier behavior (I've seen little scripts that do things like put a clock in the upper right hand corner of the screen, or some such). I have mine set up to set up some variables to add fancier coloring to my prompt based on things like load average in addition to setting the xterm title. So in my .bashrc, I have something like:
PROMPT_COMMAND="
command1
command2
command3
"
So command.getoutput() might not actually be the right thing to be calling here, since it isn't necessarily a single command, but could be anything. The reason PROMPT_COMMAND is being run this way is just to set the xterm title, but that's based on the assumption that the user is actually using it for that purpose, when in fact, it could be used for anything.
I'll admit that I'm likely the only person in the whole world who would be affected by this bug, and there is a simple workaround (for me to remove the newline at the end of my PROMPT_COMMAND), and the bug is purely cosmetic, and it might really be considered a bug in the implementation of Python's command.getoutput()... So, it's probably not really an important bug. But the aforementioned assumption about PROMPT_COMMAND might bear revisiting.
Also, xtermTitle just uses an arbitrary list of terminals and a hard-coded escape sequence when setting the terminal title instead of using terminfo, which might be considered a separate bug, but also probably not an important one.
(In reply to comment #3) > So command.getoutput() might not actually be the right thing to be calling > here, since it isn't necessarily a single command, but could be anything. Yeah, it seems like the current code assumes too much about PROMPT_COMMAND. Perhaps we should simply execute it using whatever shell is currently stored in the SHELL environment variable. > Also, xtermTitle just uses an arbitrary list of terminals and a hard-coded > escape sequence when setting the terminal title instead of using terminfo, > which might be considered a separate bug, but also probably not an important > one. I'd like to remove the hard-coded stuff. Perhaps we can try to use python's ncurses module and fall back to hard-coded escape sequences if it's not available. Created attachment 121532 [details, diff]
use os.system() instead of commands.getoutput()
This patch seems to correct the problem.
This has been released in 2.1.2.10. |
