Re: [PATCH] Add active mark, face support; activate mark on paste
> On 2020-04-11 at 18:04 +0200, gentoo_eshoes wrote:
>> $ echo ${PS1@A}
>> declare -x PS1=$'\\\n---\\n\\\n\\[\\a\\]\\\n\\[\\e[1;37m\
>> \e[42m\\]\\u@\\H\\[\\e[0m\\] \\\n\\[\\033[1;30m\\]$(date "+%Y/%m/%d %
>> H:%M:%S")\\[\\033[0m\\] \\\n\\[\\e[0;37m\\]\\s\\V t:\\l j:\\j \\\nd:
>> ${SHLVL} pp:${PPID} p:$$ ut`cat /proc/uptime | cut -f1 -d.`\\[\\e[0m\
>> \]\\n\\\n\\[\\e[0;37m\\]!\\!\\[\\e[0m\\] \\\n\\[\\033[0;36m\\]\\#\\[\
>> \033[0m\\] \\\n$(evalexitcode "${__earlyec[@]}" ) \\\n\\[\\e[0m\
>> \]$(uname -r) $(uname -v)\n$(ps_lepath "\\w")\\[ \\033];\\w\\a\\]\n\
>> \[\\e[1;32m\\]\\$\\[\\e[0m\\] \\\n'
>
>
> That was an⦠'interesting' prompt.
>
> Note that there are several subprocesses that you could easily avoid:
>
> $(date "+%Y/%m/%d %H:%M:%S") is equivalent to \D{%Y/%m/%d %H:%M:%S}
>
>
> `cat /proc/uptime | cut -f1 -d.` this could be simplified to `cut -f1 -d.
> /proc/uptime`
> it may be replaced with just builtins by `uptime=$( echo ${uptime/.*}`
>
> $(uname -r) $(uname -v) is equivalent to $(uname -r -v) I wonder why you
> need these fairly static values on every prompt line, though.
More generally, a loadable module command can do whatever you want, and
that's going to be more efficient than any subprocess fork and exec.
Re: [PATCH] Add active mark, face support; activate mark on paste
On 2020-04-11 at 18:04 +0200, gentoo_eshoes wrote:
> $ echo ${PS1@A}
> declare -x PS1=$'\\\n---\\n\\\n\\[\\a\\]\\\n\\[\\e[1;37m\
> \e[42m\\]\\u@\\H\\[\\e[0m\\] \\\n\\[\\033[1;30m\\]$(date "+%Y/%m/%d %
> H:%M:%S")\\[\\033[0m\\] \\\n\\[\\e[0;37m\\]\\s\\V t:\\l j:\\j \\\nd:
> ${SHLVL} pp:${PPID} p:$$ ut`cat /proc/uptime | cut -f1 -d.`\\[\\e[0m\
> \]\\n\\\n\\[\\e[0;37m\\]!\\!\\[\\e[0m\\] \\\n\\[\\033[0;36m\\]\\#\\[\
> \033[0m\\] \\\n$(evalexitcode "${__earlyec[@]}" ) \\\n\\[\\e[0m\
> \]$(uname -r) $(uname -v)\n$(ps_lepath "\\w")\\[ \\033];\\w\\a\\]\n\
> \[\\e[1;32m\\]\\$\\[\\e[0m\\] \\\n'
That was an… 'interesting' prompt.
Note that there are several subprocesses that you could easily avoid:
$(date "+%Y/%m/%d %H:%M:%S") is equivalent to \D{%Y/%m/%d %H:%M:%S}
`cat /proc/uptime | cut -f1 -d.` this could be simplified to `cut -f1 -d.
/proc/uptime`
it may be replaced with just builtins by `uptime=$(
Re: [bug] PROMPT_COMMAND is not executed as expected in some situations
On 4/15/20 2:59 PM, Franklin, Jason wrote: > Bash Version: 5.0 > Patch Level: 16 > Release Status: release > > Description: > > I have discovered that PROMPT_COMMAND is not executed before the > printing of PS1 in the following three situations: PROMPT_COMMAND is printed before PS1 when the shell goes to read a command. (When you're using readline, readline prints the prompt initially, but PROMPT_COMMAND works whether you're using editing or not.) That isn't true in any of these cases. > > (1) is used > (2) histverify is set > (3) completion suggestions are shown In cases 1 and 3, that all takes place within a single call to readline(), even before the shell receives and tries to parse any of the line. In the case of histverify, it's just about the same thing, technically after the readline() call returns but before the shell parser gets the line -- it's logically the same call. These all pretty much all fall into the category of the editor reprinting the prompt before it returns. -- ``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/
[bug] PROMPT_COMMAND is not executed as expected in some situations
Configuration Information [Automatically generated, do not change]: Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-orJ5jM/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux qipb7lnca 5.4.0-0.bpo.4-amd64 #1 SMP Debian 5.4.19-1~bpo10+1 (2020-03-09) x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 16 Release Status: release Description: I have discovered that PROMPT_COMMAND is not executed before the printing of PS1 in the following three situations: (1) is used (2) histverify is set (3) completion suggestions are shown Repeat-By: # (1) is used bash --norc PROMPT_COMMAND=echo # enter , type out command "true" and save and quit # note that PROMPT_COMMAND is not executed # (2) histverify is set bash --norc PROMPT_COMMAND=echo shopt -s histverify !! # note that PS1 is printed w/ last command, but PROMPT_COMMAND # is not run # (3) completion suggestions are shown bash --norc PROMPT_COMMAND=echo he # ... completions are listed # PS1 is printed after suggestions, but PROMPT_COMMAND is # not run Suggested Fix: I tried to add code to execute PROMPT_COMMAND directly inside of prompt_again(), but that didn't work as expected (the prompt would not even print when I tried this). It may be that PROMPT_COMMAND needs to be more tightly coupled to the code that prints PS1. I thought it would be as simple as that, but I guess not! In any case, I hope this helps improve Bash. Thanks a ton! -- Jason Franklin
Re: Follow-up on PROMPT_COMMAND bug report (submitted today)
On 4/15/20 2:44 PM, Chet Ramey wrote: > On 4/15/20 11:45 AM, Franklin, Jason wrote: >> Greetings: >> >> I realized that I didn't include my email when I used bashbug to report >> my issue, so I'm sending a follow-up email so that the maintainers can >> be in touch. > > I didn't see any bug report. Maybe resend it? > Interesting. The "bashbug" program must not be working for me, or (more likely) I'm not using it correctly. I will send an email here directly that describes the problem. Thanks for letting me know! -- Jason Franklin signature.asc Description: OpenPGP digital signature
Re: Follow-up on PROMPT_COMMAND bug report (submitted today)
On 4/15/20 11:45 AM, Franklin, Jason wrote: > Greetings: > > I realized that I didn't include my email when I used bashbug to report > my issue, so I'm sending a follow-up email so that the maintainers can > be in touch. I didn't see any bug report. Maybe resend it? -- ``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/
Follow-up on PROMPT_COMMAND bug report (submitted today)
Greetings: I realized that I didn't include my email when I used bashbug to report my issue, so I'm sending a follow-up email so that the maintainers can be in touch. I browsed the code and tried to fix the issue myself by modifying the "prompt_again()" function to execute PROMPT_COMMAND directly. This didn't work, and I'm still not sure why. Maybe the Chet, et al., can make sense of this. Thanks so much for your help and for maintaining my favorite shell! -- Jason Franklin
Re: [PATCH] Add active mark, face support; activate mark on paste
On 4/15/20 10:37 AM, gentoo_esh...@tutanota.com wrote: >> This is the expected behavior with bracketed-paste enabled. The pasted text >> is `bracketed' by a start and end sequence -- that's how the face code >> knows what's been pasted and to highlight it -- and any embedded editing >> characters, like newline, are simply added to the editing buffer. The >> face code enables bracketed paste by default, since it doesn't make much >> sense to test it without bracketed paste enabled. >> > Good to know. This is actually pretty good: it can act like a security > feature for when pasting copied text that could be dangerous, especially > since I've disabled xfce4-terminal's Preferences->General->[ ] Show unsafe > paste dialog > > This is actually a (nice)feature. Thank you! You can enable bracketed paste mode in bash-4.4 and later by putting set enable-bracketed-paste on into your inputrc. 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: [PATCH] Add active mark, face support; activate mark on paste
Apr 14, 2020, 22:53 by chet.ra...@case.edu: > On 4/14/20 4:46 PM, gentoo_esh...@tutanota.com wrote: > >> Another 'face' issue(the 3rd?) I just noticed now: >> if I paste something that has "\n" inside it, like these 3 lines(only the >> first 2 lines have \n, but doesn't matter): >> -bash: mk_add_options: command not found >> -bash: mk_add_options: command not found >> -bash: mk_add_options: command not found >> >> then they are all pasted on the same line, so I have to manually press Enter >> to execute the line. >> > > This is the expected behavior with bracketed-paste enabled. The pasted text > is `bracketed' by a start and end sequence -- that's how the face code > knows what's been pasted and to highlight it -- and any embedded editing > characters, like newline, are simply added to the editing buffer. The > face code enables bracketed paste by default, since it doesn't make much > sense to test it without bracketed paste enabled. > Good to know. This is actually pretty good: it can act like a security feature for when pasting copied text that could be dangerous, especially since I've disabled xfce4-terminal's Preferences->General->[ ] Show unsafe paste dialog This is actually a (nice)feature. Thank you! Now I have the choice of pressing C-c if I ever accidentally MMB paste multi-megabyte-line text onto the command line, rather than having each line executed (which I would previously prevent via unsafe paste dialog mentioned above) Quite nice.
