Fixed
Status Update
No update yet.
Comments
cl...@google.com
Thanks for the report! I've copied my favorite sources for such information. Folks, please note this is a public bug report. In going through the source GitHub issue. It sounds legitimate. Please let me know if I should move this into another public component and reassign the owner. Thanks again.
en...@google.com
like any sane human i set STAY_OFF_MY_LAWN to disable all this nonsense. (but maybe we should document STAY_OFF_MY_LAWN?)
i really wish STAY_OFF_MY_LAWN was the default and you had to say DO_STUPID_SHIT to opt in to this, but it was there long before i joined.
i really wish STAY_OFF_MY_LAWN was the default and you had to say DO_STUPID_SHIT to opt in to this, but it was there long before i joined.
cl...@google.com
ander.dy@gmail.com
Hi Andy,
Can you tell me where these best practices are you reference? I will endeavor to get us synced. Thanks.
Hi Andy,
Can you tell me where these best practices are you reference? I will endeavor to get us synced. Thanks.
an...@gmail.com
Hi there, I can't see your name there though.
I could and already do as what #3 said in my environment, but it's still a bad code to do like this:
build/envsetup.sh
function settitle()
{
if [ "$STAY_OFF_MY_LAWN" = "" ]; then
local arch=$(gettargetarch)
local product=$TARGET_PRODUCT
local variant=$TARGET_BUILD_VARIANT
local apps=$TARGET_BUILD_APPS
if [ -z "$apps" ]; then
export PROMPT_COMMAND="echo -ne \"\033]0;[${arch}-${product}-${variant}] ${USER}@${HOSTNAME}: ${PWD}\007\""
else
export PROMPT_COMMAND="echo -ne \"\033]0;[$arch $apps $variant] ${USER}@${HOSTNAME}: ${PWD}\007\""
fi
fi
}
Regarding another one I mentioned in the bug report:
If you are going to report that note that I am bothering with local last_exit_code=$? … return $last_exit_code when prepending for a reason and they should also be doing this if they choose to prepend their command and not append: it allows things which care about what was the last exit code (like powerline which displays it) receive it even if they happened to be setup before lunch was run.
It's also quite clear regarding what to do.
I could and already do as what #3 said in my environment, but it's still a bad code to do like this:
build/envsetup.sh
function settitle()
{
if [ "$STAY_OFF_MY_LAWN" = "" ]; then
local arch=$(gettargetarch)
local product=$TARGET_PRODUCT
local variant=$TARGET_BUILD_VARIANT
local apps=$TARGET_BUILD_APPS
if [ -z "$apps" ]; then
export PROMPT_COMMAND="echo -ne \"\033]0;[${arch}-${product}-${variant}] ${USER}@${HOSTNAME}: ${PWD}\007\""
else
export PROMPT_COMMAND="echo -ne \"\033]0;[$arch $apps $variant] ${USER}@${HOSTNAME}: ${PWD}\007\""
fi
fi
}
Regarding another one I mentioned in the bug report:
If you are going to report that note that I am bothering with local last_exit_code=$? … return $last_exit_code when prepending for a reason and they should also be doing this if they choose to prepend their command and not append: it allows things which care about what was the last exit code (like powerline which displays it) receive it even if they happened to be setup before lunch was run.
It's also quite clear regarding what to do.
cl...@google.com
Hi Elliott,
It sounds like the one takeaway here might be to document and recommend us of STAY_OFF_MY_LAWN. If so, can you help with that? Otherwise, I'm closing this. Thanks!
It sounds like the one takeaway here might be to document and recommend us of STAY_OFF_MY_LAWN. If so, can you help with that? Otherwise, I'm closing this. Thanks!
en...@google.com
actually, it looks like the default window manager we're all using just ignores this attempt to set the window title. (if i hold down enter i can see it flicker by, but otherwise it's invisible to me.) so i suspect we could remove this from envsetup without anyone noticing. unless +ccross/dwillemsen think otherwise, i'll upload the change to remove this since it's effectively dead for the default configuration anyway...
dw...@google.com
This at least used to work in my tmux setup, but I broke that last week, so I wouldn't notice it disappear. It's probably best to be opt-in at this point.
en...@google.com
(if anyone knows how to write the PROMPT_COMMAND correctly, i'm happy to check in a better implementation too, for those who do want to opt in, but i'll need a diff...)
en...@google.com
ch...@xiaomi.com
I think this is the correct implementation. You just need to add '\n' after original PROMPT_COMMAND.
It' tested when i'm using Powerline, a tool also uses "PROMPT_COMMAND"
Here is the issue of Powerline:
https://github.com/powerline/powerline/issues/1774
Here is the patch.
https://android-review.googlesource.com/#/c/platform/build/+/568363/
It' tested when i'm using Powerline, a tool also uses "PROMPT_COMMAND"
Here is the issue of Powerline:
Here is the patch.
cl...@google.com
I see movement on the patch with an exchange between Yang, Elliott, and Dan. If there are changes to docs needed to reflect the opt-in vs. opt-out state, let me know. Thanks.
ch...@xiaomi.com
I've already changed it from opt-out to opt-in again. And make some changes to prevent PROMPT_COMMAND from increasing by lunching multiple times.
Please help me CR&VERIFY. Thanks
Please help me CR&VERIFY. Thanks
Description
Source materials (docs, changelists) if available:
Description of issue (what needs changing):
lunch is running set_stuff_for_environment, which runs, which incorrectly sets PROMPT_COMMAND while best practices tell doing something like this: appending or prepending to PROMPT_COMMAND in place of strictly setting it. Though it allows omitting the set, still it is a bug which could easily be fixed.
If you are going to report that note that I am bothering with local last_exit_code=$? … return $last_exit_code when prepending for a reason and they should also be doing this if they choose to prepend their command and not append: it allows things which care about what was the last exit code (like powerline which displays it) receive it even if they happened to be setup before lunch was run.