Re: Option to disable VSUSP at prompt (feature request with proof of concept)

[Chet Ramey]

On 12/21/16 9:41 PM, Eric Pruitt wrote:
> On Thu, Nov 24, 2016 at 12:05:20AM -0800, Eric Pruitt wrote:
>> In my Bash configuration, I have things setup so Ctrl+Z is no longer
>> translated into a signal at the Bash prompt so it can be remapped. Most
>> recently, I decided to modify the Bash source to implement this change
>> in the interpreter because the stty invocations introduced a perceptible
>> amount of lag on a virtualized OpenBSD host I use. I think this feature
>> would be a useful default since it usually does not make sense to send
>> SIGTSTP to a prompt. Here's an accompanying snippet from my inputrc:
>>
>> # Allows Ctrl+Z to be used to bring programs back into the
>> # foreground. The cursor is moved to the beginning of the line
>> # before typing so a specific job can be resumed by typing its
>> # identifier (e.g. a number) then hitting Ctrl+Z. This depends on
>> # Ctrl+Z being a literal sequence i.e. "stty susp undef".
>> "\C-z": "\C-afg \C-m"
>>
>> With my changes to Bash and this in my inputrc, Ctrl+Z becomes a toggle.
>> I have attached the patch I wrote for myself. Since I only use modern
>> POSIX / UNIX-like systems, it was not written with portability in mind
>> and cannot be disabled with with "set" or "shopt." Consider it a proof
>> of concept rather than a pull request. Please let me know what you
>> think.
> 
> Bump.

I haven't thought about it too much, but I'm initially reluctant to put
this into the mainline source, when it seems like it could be accomplished
without any source changes at all.

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

Re: Option to disable VSUSP at prompt (feature request with proof of concept)

[Eric Pruitt]

On Thu, Dec 22, 2016 at 09:32:37AM -0500, Chet Ramey wrote:
> I haven't thought about it too much, but I'm initially reluctant to put
> this into the mainline source, when it seems like it could be accomplished
> without any source changes at all.

A lot of "new" functionality added in each release could be implemented
in Bash itself using functions and / or external programs, so I don't
understand this sentiment as a rationale. Off the top of my head, I
think the "%T(...)" time formatting which can be achieved with many
implementations of date(1) is a great example of this.

That aside, implementing this without changes to Bash's C source code
requires the use of a DEBUG trap, PS0 or potentially PS1. Using stty in
a DEBUG trap the obvious way (simply "stty susp undef") would sometimes
result in "jobs" being non-empty when I otherwise had no other programs
in the background. I ultimately resolved this by running stty in a
subshell i.e. "stty susp undef" became "$(stty susp undef)", but I think
the fact that the obvious way of doing this is Bash doesn't work
perfectly suggests that it would be better implemented in C. Changing
VSUSP natively is also far faster than calling stty.

Eric