Re: winch trap delayed until keypress
Linda Walsh writes: > I think you have that backwards... pselect allows blocking > the signal. The default behavior is 'undefined'. What do you mean with 'undefined'? pselect installs the exact signal mask specified, which allows you to atomically *unblock* a signal while waiting for input. You don't need pselect if your goal is to block a signal around select. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: winch trap delayed until keypress
Andreas Schwab wrote:
Linda Walsh writes:
I think you have that backwards... pselect allows blocking
the signal. The default behavior is 'undefined'.
What do you mean with 'undefined'? pselect installs the exact signal
mask specified, which allows you to atomically *unblock* a signal while
waiting for input. You don't need pselect if your goal is to block a
signal around select.
Whether or not a signal is generated that will interrupt a system call
isn't something that is guaranteed. I.e. - yes you can certainly unblock
WINCH, but its not guaranteed to interrupt system calls on all platforms --
I'm pretty sure it doesn't on some, but I don't know which ones. Certainly
Windows is a likely candidate.
The man page emphasizes that it pselect can be used to BLOCK signals:
...is equivalent to atomically executing the following calls:
sigset_t origmask;
pthread_sigmask(SIG_SETMASK, &sigmask, &origmask);
ready = select(nfds, &readfds, &writefds, &exceptfds, timeout);
pthread_sigmask(SIG_SETMASK, &origmask, NULL);
The reason that pselect() is needed is that if one wants to wait for
either a signal or for a file descriptor to become ready, then an
atomic test is needed to prevent race conditions. (Suppose the signal
handler sets a global flag and returns.
Then a test of this global
flag followed by a call of select() could hang indefinitely if the sig-
nal arrived just after the test but just before the call. By contrast,
pselect() allows one to first **block** signals, handle the signals
that
have come in, then call pselect() with the desired sigmask, avoiding
the race.)
---
Chet said it earlier:
Further complicating things is the fact that there is not any portable
way to specify that SIGWINCH should interrupt system calls. There is
the SA_RESTART flag that says *not* to fail with EINTR, but there is no
portable flag that has the opposite effect.
And later:
SA_RESTART will
force system call restart. Not specifying it will result in system-default
behavior, which in most -- but not all -- cases will interrupt some -- but
not all -- system calls. You'd like to have consistent behavior across
all systems.)
I.e. not specifying SA_RESTART will result in default -- but unspecified
(in a cross-platform sense) way. In this case not having consistent behavior
is what I was calling "undefined".
Re: $HOME does not get abbreviated in prompt \w output when there is a trailing slash
On Fri 16-05-14 09:13:34, Chet Ramey wrote:
> On 5/16/14, 5:22 AM, Libor Pechacek wrote:
>
> > Bash Version: 4.2
> > Patch Level: 46
> > Release Status: release
> >
> > Description:
> > Bash prompt always shows full path in prompt instead of tilde
> > abbreviation when $HOME ends with slash.
>
> This came up in March, 2012:
>
> http://lists.gnu.org/archive/html/bug-bash/2012-03/msg00055.html
>
> My opinion that this is not a bug in bash hasn't changed. There are a
> number of easy ways to remove this trailing slash.
Proposed patch:
>From da53c262cb7c356a09e5786f01e6c8c8d7301940 Mon Sep 17 00:00:00 2001
From: Libor Pechacek
Date: Fri, 23 May 2014 09:30:49 +0200
Subject: [PATCH] Make \w and \W tolerate trailing slash in $HOME
Currently \w and \W abbreviate $HOME into tilde only when it ends with a
character different from slash. This patch makes them tolerate trailing
slashes.
---
general.c | 5 -
parse.y | 8 ++--
y.tab.c | 6 +-
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/general.c b/general.c
index 087689eb74cc..de6093b57995 100644
--- a/general.c
+++ b/general.c
@@ -699,7 +699,10 @@ polite_directory_format (name)
int l;
home = get_string_value ("HOME");
- l = home ? strlen (home) : 0;
+
+ /* remove trailing slashes from $HOME before comparisons */
+ for (l = home ? strlen (home) : 0; l > 1 && home[l-1] == '/'; l--);
+
if (l > 1 && strncmp (home, name, l) == 0 && (!name[l] || name[l] == '/'))
{
strncpy (tdir + 1, name + l, sizeof(tdir) - 2);
diff --git a/parse.y b/parse.y
index 91bf3bf649bd..2abfceb1b6ee 100644
--- a/parse.y
+++ b/parse.y
@@ -5384,7 +5384,7 @@ decode_prompt_string (string)
{
/* Use the value of PWD because it is much more efficient. */
char t_string[PATH_MAX];
- int tlen;
+ int tlen, l;
temp = get_string_value ("PWD");
@@ -5415,7 +5415,11 @@ decode_prompt_string (string)
#define ROOT_PATH(x) ((x)[0] == '/' && (x)[1] == 0)
#define DOUBLE_SLASH_ROOT(x) ((x)[0] == '/' && (x)[1] == '/' && (x)[2] == 0)
/* Abbreviate \W as ~ if $PWD == $HOME */
- if (c == 'W' && (((t = get_string_value ("HOME")) == 0) ||
STREQ (t, t_string) == 0))
+ /* remove trailing slashes from $HOME before comparisons */
+ t = get_string_value ("HOME");
+ for (l = t ? strlen (t) : 0; l > 1 && t[l-1] == '/'; l--);
+
+ if (c == 'W' && ((t == 0) || STREQN (t, t_string, l) == 0))
{
if (ROOT_PATH (t_string) == 0 && DOUBLE_SLASH_ROOT
(t_string) == 0)
{
diff --git a/y.tab.c b/y.tab.c
index 80fe9308398e..d107e5b8dec5 100644
--- a/y.tab.c
+++ b/y.tab.c
@@ -7727,7 +7727,11 @@ decode_prompt_string (string)
#define ROOT_PATH(x) ((x)[0] == '/' && (x)[1] == 0)
#define DOUBLE_SLASH_ROOT(x) ((x)[0] == '/' && (x)[1] == '/' && (x)[2] == 0)
/* Abbreviate \W as ~ if $PWD == $HOME */
- if (c == 'W' && (((t = get_string_value ("HOME")) == 0) ||
STREQ (t, t_string) == 0))
+ /* remove trailing slashes from $HOME before comparisons */
+ t = get_string_value ("HOME");
+ for (l = t ? strlen (t) : 0; l > 1 && t[l-1] == '/'; l--);
+
+ if (c == 'W' && ((t == 0) || STREQN (t, t_string, l) == 0))
{
if (ROOT_PATH (t_string) == 0 && DOUBLE_SLASH_ROOT
(t_string) == 0)
{
--
1.7.12.4
Re: $HOME does not get abbreviated in prompt \w output when there is a trailing slash
On 05/23/2014 02:32 AM, Libor Pechacek wrote:
> +++ b/general.c
> @@ -699,7 +699,10 @@ polite_directory_format (name)
>int l;
>
>home = get_string_value ("HOME");
> - l = home ? strlen (home) : 0;
> +
> + /* remove trailing slashes from $HOME before comparisons */
> + for (l = home ? strlen (home) : 0; l > 1 && home[l-1] == '/'; l--);
> +
Does this still work correctly on systems where / and // are distinct
(as allowed by POSIX) and someone has set $HOME to //?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: terminal emulators and size displays used when running bash (OB-tie-in) ; -)
On 5/22/14, 10:32 PM, Linda Walsh wrote: > The "beauty" of the bash-WINCH handler was that it worked > with ANY window manager or NO window manager. Sure. It just abused the idea of running safe code in a signal handler context. Chet -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
funcnest and recursion
Hi, there've recently been a few bug reports against bash on RH BZ,
saying that bash can't handle infinite recursion the way zsh or ksh can.
Looking at execute_cmd.c, there are the funcnest{,_max} variables
and a piece of code using them in execute_function().
Will funcnest_max be set to non-0 in upstream code in the future?
Or is it just there for the downstream maintainers to set it if they
see it fit?
Thanks,
Ondrej
Re: winch trap delayed until keypress
On 5/22/14, 10:19 PM, Linda Walsh wrote:
>> We're mostly talking about the
>> interaction between readline and the applications that use it.
>
> I'm not sure I see the problem there -- since the application
> runs "after bash" (i.e. bash forks&execs it, then waits for it to return
> in the normal foreground case), wouldn't the application be able to
> install whatever signal handling it wants and possibly interfere w/bash
> getting the signal, vs. bash causing app interferences?
I think you misunderstand. Applications, in this context, are those
programs that link with readline and use it for command line editing.
Bash is an application from readline's perspective. Readline has to
manage its signal handling in a way that doesn't preclude an application
that links with it from doing what it needs.
>> While
>> you can use readline in a script -- and there is a pending bug with
>> readline and timeouts in scripts when called by the read builtin -- it's
>> not the primary use case. And SIGWINCH is the only signal subject to
>> this problem.
> ---
>
> Wait.. there is a pending bug w/readline and timeouts, (i.e. SIGALARM?) and
> SIGWINCH is the only one -- is the bug w/readline & timeouts, or only
> in the presence of SIGWINCH?
It has to do with the read builtin not setting the right hook for readline
and readline not doing what it needs to with SIGALRM. It's not anything
related to the framework or approach, and unconnected to any SIGWINCH
issues except that they are both signals.
I've attached the sample patch so you can see what I'm talking about.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
*** ../bash-4.3-patched/lib/readline/input.c 2014-01-10 15:07:08.0 -0500
--- lib/readline/input.c 2014-05-22 18:40:59.0 -0400
***
*** 535,540
--- 538,551
else if (_rl_caught_signal == SIGHUP || _rl_caught_signal == SIGTERM)
return (RL_ISSTATE (RL_STATE_READCMD) ? READERR : EOF);
+ /* keyboard-generated signals of interest */
else if (_rl_caught_signal == SIGINT || _rl_caught_signal == SIGQUIT)
RL_CHECK_SIGNALS ();
+ /* non-keyboard-generated signals of interest */
+ else if (_rl_caught_signal == SIGALRM
+ #if defined (SIGVTALRM)
+ || _rl_caught_signal == SIGVTALRM
+ #endif
+ )
+ RL_CHECK_SIGNALS ();
if (rl_signal_event_hook)
*** ../bash-4.3-patched/builtins/read.def 2013-09-02 11:54:00.0 -0400
--- builtins/read.def 2014-05-08 11:43:35.0 -0400
***
*** 443,447
#if defined (READLINE)
if (edit)
! add_unwind_protect (reset_attempted_completion_function, (char *)NULL);
#endif
falarm (tmsec, tmusec);
--- 443,450
#if defined (READLINE)
if (edit)
! {
! add_unwind_protect (reset_attempted_completion_function, (char *)NULL);
! add_unwind_protect (bashline_reset_event_hook, (char *)NULL);
! }
#endif
falarm (tmsec, tmusec);
***
*** 1022,1025
--- 1025,1029
old_attempted_completion_function = rl_attempted_completion_function;
rl_attempted_completion_function = (rl_completion_func_t *)NULL;
+ bashline_set_event_hook ();
if (itext)
{
***
*** 1033,1036
--- 1037,1041
rl_attempted_completion_function = old_attempted_completion_function;
old_attempted_completion_function = (rl_completion_func_t *)NULL;
+ bashline_reset_event_hook ();
if (ret == 0)
Re: funcnest and recursion
On Friday, May 23, 2014 04:17:12 PM Ondrej Oprala wrote: > Hi, there've recently been a few bug reports against bash on RH BZ, > saying that bash can't handle infinite recursion the way zsh or ksh can. They come up here at least a few times a year. E.g. https://lists.gnu.org/archive/html/bug-bash/2012-09/msg00072.html > Will funcnest_max be set to non-0 in upstream code in the future? > Or is it just there for the downstream maintainers to set it if they > see it fit? It should be an end-user setting. It can be useful to have the ability to set a limit when testing certain things. I'm sure you're familiar with the age-old controversy surrounding recursion limits in Python. Guido has long argued that the limit makes sense when implementations are not required to support TCO, thus making tail-recursive iteration a "language feature" that programmers can't not depend on. I disagree with Guido, as do many others. Though all the same arguments apply in this case. I see no good reason for an arbitrary limit but I understand the opposing view. -- Dan Douglas
Re: funcnest and recursion
On 5/23/14, 10:17 AM, Ondrej Oprala wrote:
> Hi, there've recently been a few bug reports against bash on RH BZ,
> saying that bash can't handle infinite recursion the way zsh or ksh can.
>
> Looking at execute_cmd.c, there are the funcnest{,_max} variables
> and a piece of code using them in execute_function().
>
> Will funcnest_max be set to non-0 in upstream code in the future?
> Or is it just there for the downstream maintainers to set it if they
> see it fit?
Neither. The funcnest_max variable reflects the value of the FUNCNEST
shell variable. Users can set the maximum recursion level they want,
without changing the bash code at all, but the default is still as much as
the stack will give you (as it has been all along).
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRUc...@case.eduhttp://cnswww.cns.cwru.edu/~chet/
Re: funcnest and recursion
On 05/23/2014 04:48 PM, Chet Ramey wrote:
On 5/23/14, 10:17 AM, Ondrej Oprala wrote:
Hi, there've recently been a few bug reports against bash on RH BZ,
saying that bash can't handle infinite recursion the way zsh or ksh can.
Looking at execute_cmd.c, there are the funcnest{,_max} variables
and a piece of code using them in execute_function().
Will funcnest_max be set to non-0 in upstream code in the future?
Or is it just there for the downstream maintainers to set it if they
see it fit?
Neither. The funcnest_max variable reflects the value of the FUNCNEST
shell variable.
Ah. I should have poked around the code (or the man page) more then, my bad.
Users can set the maximum recursion level they want,
without changing the bash code at all, but the default is still as much as
the stack will give you (as it has been all along).
Of course.
Chet
Thanks for the clarification.
Ondrej
Re: funcnest and recursion
On Friday, May 23, 2014 10:48:11 AM Chet Ramey wrote:
> On 5/23/14, 10:17 AM, Ondrej Oprala wrote:
> > Hi, there've recently been a few bug reports against bash on RH BZ,
> > saying that bash can't handle infinite recursion the way zsh or ksh can.
> >
> > Looking at execute_cmd.c, there are the funcnest{,_max} variables
> > and a piece of code using them in execute_function().
> >
> > Will funcnest_max be set to non-0 in upstream code in the future?
> > Or is it just there for the downstream maintainers to set it if they
> > see it fit?
>
> Neither. The funcnest_max variable reflects the value of the FUNCNEST
> shell variable.
Oops Chet read your message right... I presumed you were aware of FUNCNEST,
and were talking about setting a non-zero default at compile-time. Can't
remember if that's ever been discussed.
> Users can set the maximum recursion level they want,
> without changing the bash code at all, but the default is still as much as
> the stack will give you (as it has been all along).
Yup, it's a good feature. Zsh and ksh don't "support infinite recursion", they
have hardcoded limits (1024 ksh93, 1000 zsh).
As a random aside... dash somehow has extremely lightweight function calls.
Glad it's not arbitrarily capped at 1k.
$ time dash -c 'f() { echo "$1"; f $(($1 + 1)); }; f 0' | tail -n 1
13776
real0m0.035s
user0m0.020s
sys 0m0.033s
$ time bash -c 'f() { echo "$1"; f $(($1 + 1)); }; f 0' | tail -n 1
8308
real0m3.993s
user0m4.032s
sys 0m0.165s
--
Dan Douglas
Re: funcnest and recursion
On 05/23/2014 05:05 PM, Dan Douglas wrote:
On Friday, May 23, 2014 10:48:11 AM Chet Ramey wrote:
On 5/23/14, 10:17 AM, Ondrej Oprala wrote:
Hi, there've recently been a few bug reports against bash on RH BZ,
saying that bash can't handle infinite recursion the way zsh or ksh can.
Looking at execute_cmd.c, there are the funcnest{,_max} variables
and a piece of code using them in execute_function().
Will funcnest_max be set to non-0 in upstream code in the future?
Or is it just there for the downstream maintainers to set it if they
see it fit?
Neither. The funcnest_max variable reflects the value of the FUNCNEST
shell variable.
Oops Chet read your message right... I presumed you were aware of FUNCNEST,
and were talking about setting a non-zero default at compile-time. Can't
remember if that's ever been discussed.
IMHO that's also a possibility. Having a default of e.g. 1024, still of
course
being overriden by FUNCNEST might be more user-friendly than not
controlling it at all.
Users can set the maximum recursion level they want,
without changing the bash code at all, but the default is still as much as
the stack will give you (as it has been all along).
Yup, it's a good feature. Zsh and ksh don't "support infinite recursion", they
have hardcoded limits (1024 ksh93, 1000 zsh).
Yes, I should have written "support" in my first mail :) .
As a random aside... dash somehow has extremely lightweight function calls.
Glad it's not arbitrarily capped at 1k.
$ time dash -c 'f() { echo "$1"; f $(($1 + 1)); }; f 0' | tail -n 1
13776
real0m0.035s
user0m0.020s
sys 0m0.033s
$ time bash -c 'f() { echo "$1"; f $(($1 + 1)); }; f 0' | tail -n 1
8308
real0m3.993s
user0m4.032s
sys 0m0.165s
Thanks,
Ondrej
Re: winch trap delayed until keypress
Chet Ramey wrote: I think you misunderstand. Applications, in this context, are those programs that link with readline ... Ah... of course, wasn't thinking of apps in that sense. Was trying to figure out interactions between programs launched by bash and signal handling in bash. Completely different. Wait.. there is a pending bug w/readline and timeouts It has to do with the read builtin not setting the right hook for readline and readline not doing what it needs to with SIGALRM. It's not anything related to the framework or approach, and unconnected to any SIGWINCH issues except that they are both signals. Indeed... my questions were not coming from the "readline as library" perspective -- primarily "apps" written in "bash", and secondarily "apps" run (launched) by bash. Given that, regarding the bug in readline & timeouts. I kept having problems with the timeouts getting 'lost' if I got interrupted by a signal like WINCH. After I'd set a flag in the int-handler (which was all I did), the read didn't restart correctly such that the timeout was still in effect. I.e. it would require a keypress to force return from readkey. I did think about using SIGALRM instead of a timed read, but I thought there was a good chance that the timed-red used SIGALRM, itself, and my using it would, at best, be "unproductive". I wasn't excited (one might say "not enthusiastic"), about using a separate process for input from the console, but I eventually got over it when I realized that was the best solution for most GUI's having non-responsiveness issues -- putting user I/O handling in it's own process so it never is blocked by work or events in the main app. Too often in GUI's people put the handling of user-IO and the implementation of effects/features caused by that I/O in the same global event loop, so user I/O gets unresponsive when the program is off in some cpu-bound call or some other I/O-op that is taking longer than desired (or expected). Since that applied to my program (waiting for a timed read wasn't timing out as it should have), I decided that my general belief about GUI's needing more threads of execution (in regards to UI (user- interface) handling), could be just as valid a need in a complex CLUI as in a GUI. Generally the more things the main event loops need to handle, the more likely it is those events will interfere w/basic UI functionality. I could elaborate more, but don't want to any _more_ people to sleep. ;-)
Re: terminal emulators and size displays used when running bash (OB-tie-in) ; -)
Chet Ramey wrote: On 5/22/14, 10:32 PM, Linda Walsh wrote: The "beauty" of the bash-WINCH handler was that it worked with ANY window manager or NO window manager. Sure. It just abused the idea of running safe code in a signal handler context. It doesn't have to. Perl used to call user SIG handlers in dangerous context, but fixed it to only call it from the top-side. So a user client doesn't have to worry about such details. If it is a compiled program,the program writer has to deal with such, but if it is an interpreted or managed environment, then only the interpreter or managing service can receive such things -- the clients are totally dependent on the scripting host. Only passing on WINCH on a keyboard input makes WINCH rather pointless since it's an output function (no keys need to be pressed to have a window resized). So a requirement to wait until a key is pressed sorta defeats the purpose of the signal, no?
