Closed TheFantasticWarrior closed 1 month ago
[1]notify the users what were changed that's not default settings (if possible), or [2]some customizations and document
It is technically possible to implement either one literally, but I doubt if that helps. Although you haven't explained the problem (how you originally set up TTY and what you expected with that setup), I suspect you misunderstand something about ble.sh's manipulation of TTY because those requests don't seem to make sense to me.
I'd rather add an option to restore the original TTY state on the command execution. Does that work for you? If not, could you explain your setup and what you expect?
Another one small issue is when running make install after
cd ble.sh
it doesn't work example for [1]
What does it mean? Could you explain it in more detail?
Sorry, I'm very new to Linux.
Does that work for you? If not, could you explain your setup and what you expect?
I'm not entirely sure, I tried to use stty intr ^X in .bashrc because I set ^C to copy in urxvt, but stty -a restores to intr ^C right after the execution no matter where I put it in bashrc. There might be other settings that I will change, day by day, and maybe it will be conflicted with the script, so I'm asking if doing this for every setting will be possible, might be a stretch
Another one small issue is when running make install after
cd ble.sh
it doesn't work example for [1]What does it mean? Could you explain it in more detail?
When I already have ble.sh directory(I think it was created when following the steps to install), and I cd into it to change the util.sh, the make fails trying to cd ble.sh
again, and because I am already in the ble.sh directory and I have to cd ..
then run the command again
I'm not entirely sure, I tried to use stty intr ^X in .bashrc because I set ^C to copy in urxvt, but stty -a restores to intr ^C right after the execution no matter where I put it in bashrc.
What is the purpose of changing intr
? If you change intr
for canceling the execution of the currently running commands, I think "the option to save and restore the TTY state for the user command execution" would cleanly solve the problem. If you also intend to change the behavior of the line editor on pressing ^X by intr
, you need a separate setting using ble-bind
.
I'll later add the option and ask you to try it. It might take a few or several days because I'm currently testing another big change in ble.sh
in a limited time.
There might be other settings that I will change, day by day, and maybe it will be conflicted with the script, so I'm asking if doing this for every setting will be possible, might be a stretch
I'd say it's not possible. I was reluctant to explain all those details, but I'll probably have to explain it after all.
First of all, ble.sh
maintains two TTY states: one is for the line editor (let me call it the internal TTY state hereafter), and the other is for the command execution (let me call this the external TTY state). The internal TTY state needs to be properly configured for the line editor to work, while the external TTY state can be arbitrary in principle. I'm not sure whether you only want to change the external TTY state or both the internal and external TTY states, but let me assume you are specifically talking about the external TTY state. In principle, ble.sh
might specify all the options in the internal TTY state to the proper ones. However, the problem is that the set of available options by stty
and the ways to specify them depends on the system, and it is hard to perfectly specify the whole TTY state. So, ble.sh copies the external TTY state to the internal TTY state and then adjusts the known options needing modifications. If you configure the external TTY state to an unusual one, the internal TTY state is also affected, and it may break the line editor or cause some unpredictable behaviors.
When I already have ble.sh directory(I think it was created when following the steps to install), and I cd into it to change the util.sh, the make fails trying to
cd ble.sh
again, and because I am already in the ble.sh directory and I have tocd ..
then run the command again
Thanks for the explanation. In that case, you can simply drop -C ble.sh
from the arguments of the make
command. make -C dir xxx
is essentially the same as (cd dir && make xxx)
. There is technically a difference, but ble.sh
's make
configuration doesn't rely on the feature utilizing the difference between cd
and -C
.
What is the purpose of changing
intr
? If you changeintr
for canceling the execution of the currently running commands, I think "the option to save and restore the TTY state for the user command execution" would cleanly solve the problem.
Yes that is probably the case, and yes I'm changing the external state to interrupt programs
There might be other settings that I will change, day by day, and maybe it will be conflicted with the script, so I'm asking if doing this for every setting will be possible, might be a stretch
I'd say it's not possible. I was reluctant to explain all those details, but I'll probably have to explain it after all.
I mean that I would change other settings and it would be nice to know what other things might conflict with the script, not just stty. I haven't read all the documentation yet, but a short list of what might conflict would help. I suggested notifying everything that was changed but I guess that's impossible
Thanks for the explanation. In that case, you can simply drop
-C ble.sh
from the arguments of themake
command.make -C dir xxx
is essentially the same as(cd dir && make xxx)
. There is technically a difference, butble.sh
'smake
configuration doesn't rely on the feature utilizing the difference betweencd
and-C
.
Oh thanks for the explanation, I guess that's on me for not knowing make commands
What is the purpose of changing
intr
? If you changeintr
for canceling the execution of the currently running commands, I think "the option to save and restore the TTY state for the user command execution" would cleanly solve the problem.Yes that is probably the case, and yes I'm changing the external state to interrupt programs
I added the option bleopt term_stty_restore
in commit e64b02b7a1558efab0bced51b0e3dac4f3021f86.
I mean that I would change other settings and it would be nice to know what other things might conflict with the script, not just stty. I haven't read all the documentation yet, but a short list of what might conflict would help. I suggested notifying everything that was changed but I guess that's impossible
The range of the settings that you are going to change is unclear. Since the line editor works by changing the state of the shell and the terminal (changing shell settings, shell variables, shell functions, characters on the terminal, colors, and all the other interactions with the terminal), if you require listing up everything, I have to explain everything about the implementation of the line editor. Or if everything is notified, the terminal display will be flooded with the notifications. It's technically possible, but it's hardly usable. If you want to experience it, maybe you can try typing the command and see what happens:
$ ble/function#push ble/base/xtrace/adjust : ; set -x
I added a section on a wiki page about the internal and external states, but it doesn't cover everything. Also, the list requires a large maintenance cost even though I don't think it's useful. We assume the users have sane settings and don't want to support the case where the user does something wrong in every aspect. When the user really wants to do it, I don't think a simple list would help. The user will finally have to read and understand the actual codebase to do that.
My intention was to suggest a way for users to understand how their customizations may be affected by the script. My suggestion was specifically aimed at listing the changes that both the user and the script make, not all changes. This could help users understand how their customizations may be affected. I understand there's a lot of complexity to list all changes, especially for a script that modifies numerous settings.
I think I'll just modify the util.sh
for now. Can I just change the line
ble/array#push _ble_term_stty_flags_leave
...
Will that break anything? Sorry for the issue and confusion I caused. Additionally, I understand if it's not feasible or necessary to incorporate the change I proposed. Do you think it's appropriate to close this issue now? Apologies once again for any inconvenience caused.
If you decide to keep the option, I don't think it is working as intended, it changes the keys to undef instead. I haven't changed stty settings yet, and I didn't do anything else between the commands. $ stty -a
speed 38400 baud; rows 36; columns 47;
line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U;
eof = ^D; eol = <undef>; eol2 = <undef>;
swtch = <undef>; start = ^Q; stop = ^S;
susp = ^Z; rprnt = ^R; werase = ^W;
lnext = <undef>; discard = <undef>;
min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb
cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip
-inlcr -igncr icrnl -ixon -ixoff -iuclc -ixany
imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill
-ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl
-noflsh -xcase -tostop -echoprt echoctl echoke
-flusho -extproc
$ . ble-nightly/ble.sh [ble: reload] $ stty -a
speed 38400 baud; rows 36; columns 47;
line = 0;
intr = <undef>; quit = <undef>; erase = ^?;
kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = ^Q;
stop = ^S; susp = <undef>; rprnt = ^R;
werase = ^W; lnext = <undef>;
discard = <undef>; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb
cread -clocal -crtscts
-ignbrk brkint ignpar -parmrk -inpck -istrip
-inlcr -igncr -icrnl -ixon -ixoff -iuclc -ixany
imaxbel iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill
-ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig -icanon iexten -echo echoe echok -echonl
-noflsh -xcase -tostop -echoprt echoctl echoke
-flusho -extproc
My suggestion was specifically aimed at listing the changes that both the user and the script make, not all changes.
Ah, OK. I misunderstood that you were going to change everything that shouldn't be usually changed. At the point of this reply https://github.com/akinomyoga/ble.sh/issues/412#issuecomment-1953401143, I thought you were talking about stty
, so I thought
I'm asking if doing this for every setting will be possible
meant to change every setting in stty
, which contains many settings that shouldn't be changed usually.
I think I'll just modify the
util.sh
for now. Can I just change the lineble/array#push _ble_term_stty_flags_leave
...
Actually, I initially thought to tell you about that way in the first reply, but I didn't do so because you need to be careful changing the content of the array _ble_term_stty_flags_leave
: When you add something to the array _ble_term_stty_flags_leave
, you also need to add a corresponding setting for the line editor in _ble_term_stty_flags_enter
.
However, the proper setting for the line editor depends, so it would be difficult to explain briefly what to add in _ble_term_stty_flags_enter
. For the c_cc
settings, probably undef
would be the ones to be added in _ble_term_stty_flags_enter
. For the other settings, the default setting would be usually the one to add in _ble_term_stty_flags_enter
, but there are some exceptions including ixon
.
To summarize, you can add something to _ble_term_stty_flags_leave
if you know what should be added to _ble_term_stty_flags_enter
for the line editor.
If you decide to keep the option, I don't think it is working as intended, it changes the keys to undef instead. I haven't changed stty settings yet, and I didn't do anything else between the commands.
OK. I could reproduce the problem. I added a fix for bleopt term_stty_restore
in commit ef8272a4. There were two problems:
stty
(which is only enabled in Bash 5.2). That workaround is interfering with bleopt term_stty_restore
. The problem happens when you load ble.sh twice in the session. I adjusted the workaround in commit ef8272a4.ble-attach
in ~/.bashrc
). When the prompt attach is used, ble.sh captures Readline's internal TTY state as an ble.sh's external state, which causes the problem. One needs to capture an external state in ~/.bashrc
. I decided to capture the external state at the point where bleopt term_stty_restore=1
is specified (yet there is limitation in this implementation; I mentioned it in bleopt term_stty_restore
).Could you update ble.sh
by running ble-update
and see if the problem is fixed?
New to using linux and was taking a long time to figure out stty was reset by this script, and another long time figuring out where it is located Would be cool to either [1]notify the users what were changed that's not default settings (if possible), or [2]some customizations and document Another one small issue is when running make install after
cd ble.sh
it doesn't work example for [1]no change from user -> no notify
stty intr ...
in .bashrc -> notify user option is overwrittenAlso I hope changing that doesn't break anything in the script, still figuring things out, amazing script!