[PATCH] bracketed paste support
This patch adds support for bracketed paste mode to readline. In
this mode, readline instructs the terminal to wrap pasted strings in
special control sequences so that programs can distinguish them from
typed input. This patch makes readline insert each pasted string as
one big literal into the edit buffer; as there is no termcap
capability for bracketed paste support, the patch detects capable
terminals automatically by looking for support for similar escape
sequences.
diff --git a/lib/readline/bind.c b/lib/readline/bind.c
index 8acf4ac..7173552 100644
--- a/lib/readline/bind.c
+++ b/lib/readline/bind.c
@@ -1486,6 +1486,7 @@ static const struct {
{ convert-meta,_rl_convert_meta_chars_to_ascii, 0 },
{ disable-completion, rl_inhibit_completion, 0 },
{ echo-control-characters, _rl_echo_control_chars,0 },
+ { enable-bracketed-paste, _rl_enable_bracketed_paste,0 },
{ enable-keypad, _rl_enable_keypad, 0 },
{ enable-meta-key, _rl_enable_meta, 0 },
{ expand-tilde,rl_complete_with_tilde_expansion, 0 },
diff --git a/lib/readline/doc/readline.3 b/lib/readline/doc/readline.3
index ca0a81a..808b4b7 100644
--- a/lib/readline/doc/readline.3
+++ b/lib/readline/doc/readline.3
@@ -578,6 +578,13 @@ following the cursor are not duplicated.
If set to \fBOn\fP, a character denoting a file's type as reported
by \fIstat\fP(2) is appended to the filename when listing possible
completions.
+.TP
+.B enable\-bracketed\-paste (On)
+If set to \fBOn\fP and the terminal supports bracketed
+paste mode, configure it to insert each paste into the
+editing buffer as a string instead of treating
+the characters pasted as normal input, preventing inadvertent
+execution of pasted commands.
.PD
.SS Conditional Constructs
.PP
diff --git a/lib/readline/doc/rluser.texi b/lib/readline/doc/rluser.texi
index 577..0a26444 100644
--- a/lib/readline/doc/rluser.texi
+++ b/lib/readline/doc/rluser.texi
@@ -703,6 +703,13 @@ If set to @samp{on}, a character denoting a file's type
is appended to the filename when listing possible
completions. The default is @samp{off}.
+@item enable-bracketed-paste
+@vindex enable-bracketed-paste
+If set to @samp{on} and the terminal supports bracketed paste mode,
+configure it to insert each paste into the editing buffer as a string
+instead of treating the characters pasted as normal input, preventing
+inadvertent execution of pasted commands. The default is @samp{on}.
+
@end table
@item Key Bindings
diff --git a/lib/readline/funmap.c b/lib/readline/funmap.c
index 363507b..29f089b 100644
--- a/lib/readline/funmap.c
+++ b/lib/readline/funmap.c
@@ -101,6 +101,7 @@ static const FUNMAP default_funmap[] = {
{ history-substring-search-backward, rl_history_substr_search_backward },
{ history-substring-search-forward, rl_history_substr_search_forward },
{ insert-comment, rl_insert_comment },
+ { bracketed-paste-begin, rl_bracketed_paste_begin },
{ insert-completions, rl_insert_completions },
{ kill-whole-line, rl_kill_full_line },
{ kill-line, rl_kill_line },
diff --git a/lib/readline/kill.c b/lib/readline/kill.c
index 3d23745..79de79f 100644
--- a/lib/readline/kill.c
+++ b/lib/readline/kill.c
@@ -656,6 +656,61 @@ rl_yank_last_arg (count, key)
return retval;
}
+/* We've recognized a terminal control sequence telling us to expected
+ * pasted content. Read characters from the terminal until we read a
+ * bracketed paste end sequence, treating the characters read as
+ * literal text to insert. */
+int
+rl_bracketed_paste_begin (count, key)
+ int count, key;
+{
+ static const char endseq[] = \033[201~;
+ static const int endseqlen = sizeof (endseq) - 1;
+
+ int rv = -1;
+ int c;
+ size_t len = 0;
+ size_t cap = 16;
+ char *buf = xmalloc (cap);
+
+ RL_SETSTATE(RL_STATE_MOREINPUT);
+ while (0 = (c = rl_read_key ()))
+{
+ if (RL_ISSTATE (RL_STATE_MACRODEF))
+_rl_add_macro_char (c);
+
+ if (c == '\r')
+c = '\n';
+
+ if (len == cap)
+buf = xrealloc (buf, (cap *= 2));
+
+ buf[len++] = c;
+ if (len = endseqlen
+ !strncmp (buf[len - endseqlen],
+endseq,
+endseqlen))
+{
+ len -= endseqlen;
+ break;
+}
+}
+ RL_UNSETSTATE(RL_STATE_MOREINPUT);
+
+ if (c = 0)
+{
+ if (len == cap)
+buf = xrealloc (buf, (cap += 1));
+
+ buf[len++] = '\0';
+ rl_insert_text (buf);
+ rv = 0;
+}
+
+ xfree (buf);
+ return rv;
+}
+
/* A special paste command for users of Cygnus's cygwin32. */
#if defined (__CYGWIN__)
#include windows.h
diff --git a/lib/readline/readline.c b/lib/readline/readline.c
index f8211e7..d6e9775 100644
--- a/lib/readline/readline.c
+++ b/lib/readline/readline.c
@@ -302,6 +302,11 @@ int _rl_revert_all_at_newline = 0;
characters corresponding to keyboard-generated signals. */
int
Re: [PATCH] bracketed paste support
On 10/29/2014 09:35 PM, Pádraig Brady wrote:
On 10/27/2014 10:35 PM, Daniel Colascione wrote:
+@item enable-bracketed-paste
+@vindex enable-bracketed-paste
+If set to @samp{on} and the terminal supports bracketed paste mode,
+configure it to insert each paste into the editing buffer as a string
+instead of treating the characters pasted as normal input, preventing
+inadvertent execution of pasted commands. The default is @samp{on}.
I see this defaults on.
Does this mean one can't paste command sequences to readline now?
Well, I don't know whether Chet left the feature enabled by default. I hope he
did, though, since preventing execution of pasted commands is one of the
feature's key benefits. In bash, you should be able to execute a pasted command
sequence by typing RET after the paste, but a paste by itself should never
begin execution.
For better or worse, people copy and paste commands from websites all the time.
Even if a bit of shell looks innocuous, a malicious bit of JavaScript could
change the pasted text at the last second without the user being aware of the
switch. (Tynt uses this technique to slightly less malicious ends.) If pasting
in a terminal immediately begins execution, there's no opportunity to review
pasted code. With bracketed paste support, the shell requires additional user
interaction after a paste to begin execution, making this attack much less
effective.
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] bracketed paste support
On 10/30/2014 06:05 AM, Bob Proulx wrote: Daniel Colascione wrote: Well, I don't know whether Chet left the feature enabled by default. I hope he did, though, since preventing execution of pasted commands is one of the feature's key benefits. In bash, you should be able to execute a pasted command sequence by typing RET after the paste, but a paste by itself should never begin execution. I use paste into the shell with an embedded newline in order to immediately execute a command *a lot*. If that were removed I would be very unhappy. I strongly doubt that your use case is typical. I've asked several of my colleagues; all have complained about accidentally pasting a large amount of text into the shell at one time or another. Nobody has complained about losing automatic execution of code after paste. Speaking from personal experience, I've been using terminal emulators of various sorts for almost 20 years, and in that time, I've accidentally pasted documents into my terminal orders of magnitude more often than I've deliberately pasted multi-command sequences. As far as I'm concerned, automatic execution of code on paste isn't a feature: it's a bug and security hole. Users should have to opt into security holes. We've only lived with the existing behavior so long because it's only recently become possible to distinguish pastes from other input. However I read from Chet's replies that this is not the case. So I am not worried. Just voicing a counter opinion that this shouldn't be removed. Nobody is talking about removing the ability to select the present behavior. We're talking about the default setting. If you want it then you should enable it. This is like many other options available in the shell. They are optional. This feature significantly decreases the likelihood of user error, but if it's not on by default, most users won't enable it and won't see any benefits. I'd rather slightly power users like you with very specific use cases than continue to see accidental code execution. For better or worse, people copy and paste commands from websites all the time. Even if a bit of shell looks innocuous, a malicious bit of JavaScript could change the pasted text at the last second without the user being aware of the switch. Then the browser shouldn't copy it. The place to fix the problem is in the browser. Browser behavior is unlikely to change; even if it did, sequences of text that look safe can contain control characters like TAB that invoke various shell commands. Visually inspection is not a reliable way to inspect a piece of code pasted from an otherwise-untrusted source. Sure, you might argue that users should paste into a trusted intermediate location --- say a text editor --- inspect the code, and then paste into the shell. That would be the prudent thing to do, but users don't actually *do* that and never will. A problem with a browser should not break cutting and pasting in general. This change doesn't break pasting. It changes its behavior to one that's safer, more natural, and more consistent with that of other programs. (Tynt uses this technique to slightly less malicious ends.) If pasting in a terminal immediately begins execution, there's no opportunity to review pasted code. With bracketed paste support, the shell requires additional user interaction after a paste to begin execution, making this attack much less effective. I am very happy this is a feature you like. However I would hate that feature. It should definitely not default to on or it will make people like me very unhappy. You can disable the setting yourself. If you don't want to do that, all you need to do is type RET after pasting. That's a very small tradeoff for an increase in safety and predictability. signature.asc Description: OpenPGP digital signature
Re: [PATCH] bracketed paste support
On 10/29/2014 08:49 PM, Chet Ramey wrote: On 10/27/14, 6:35 PM, Daniel Colascione wrote: This patch adds support for bracketed paste mode to readline. In this mode, readline instructs the terminal to wrap pasted strings in special control sequences so that programs can distinguish them from typed input. Thanks for the contribution. I'll look at the code; the approach seems sound. It went in very easily, though I changed some things around. This will be in the next release of bash and readline. The code appeared in the snapshot, so I was able to look at how you changed some things around. You removed the code that tries to determine whether a terminal actually supports the feature; instead, you blindly send the enable sequence to *any* terminal when enable-bracketed-paste is enabled, with potentially unknown consequences on those terminals. There's a comment in the code that indicates you expect users to enable the feature only on terminals where it's supported. I don't think it's reasonable to expect people to maintain a terminal database in their inputrc files. You also know very well that people are going to just set the feature to enabled in their configurations, test it, and see it work, all without considering whether they should enable this feature in a terminal-type-dependent conditional. Then they'll wonder why parts of their system silently break. Please restore the part of my patch, rl_bracketed_paste_probably_supported, that detects terminal support for this feature. signature.asc Description: OpenPGP digital signature
Re: [PATCH] bracketed paste support
On 11/06/2014 02:38 AM, Chet Ramey wrote: On 11/5/14 9:02 PM, Daniel Colascione wrote: On 10/29/2014 08:49 PM, Chet Ramey wrote: On 10/27/14, 6:35 PM, Daniel Colascione wrote: This patch adds support for bracketed paste mode to readline. In this mode, readline instructs the terminal to wrap pasted strings in special control sequences so that programs can distinguish them from typed input. Thanks for the contribution. I'll look at the code; the approach seems sound. It went in very easily, though I changed some things around. This will be in the next release of bash and readline. The code appeared in the snapshot, so I was able to look at how you changed some things around. You removed the code that tries to determine whether a terminal actually supports the feature; instead, you blindly send the enable sequence to *any* terminal when enable-bracketed-paste is enabled, with potentially unknown consequences on those terminals. There's a comment in the code that indicates you expect users to enable the feature only on terminals where it's supported. I don't think it's reasonable to expect people to maintain a terminal database in their inputrc files. People rarely use more than one, maybe two, different terminals or terminal emulators. I don't doubt that people who enable this feature know enough to figure out whether or not it's going to work. You're assuming users are experts. In reality, users are going to just paste set enable-bracketed-paste on into their inputrc files; they'll then see an inscrutable control sequence appear in places they didn't expect and have no idea what's wrong with their system. Please optimize for what real users actually do, not what perfectly intelligent users with perfect understanding of their systems would ideally do. I'm already going to have to contact every readline and bash distributor on earth and ask them to enable this feature by default. I don't want to have to ask them to apply a code patch too. Please restore the part of my patch, rl_bracketed_paste_probably_supported, that detects terminal support for this feature. It doesn't `detect terminal support' as such. It uses a heuristic to guess whether or not a terminal supports bracketed paste by checking for the presence of a string in another termcap sequence. Those kinds of heuristics always end up having an exception. I don't think they will in this case, and at least it's a *conservative* heuristic. All terminals I've tested (urxvt, xterm, linux, and vte) either fail the heuristic, pass the heuristic and ignore the control sequence (which is harmless), or pass the heuristic and enable bracketed paste mode. Terminal emulation at this point is very mature. I don't expect significant development of new terminal types and new kinds of terminal emulators. The heuristic should work well for a long time. signature.asc Description: OpenPGP digital signature
Re: pipefail with SIGPIPE/EPIPE
On 02/15/2015 01:48 PM, Chet Ramey wrote: On 2/13/15 12:19 PM, Pádraig Brady wrote: I was expecting bash to handle SIGPIPE specially here, as in this context it's informational rather than an indication of error. I don't agree. It's a fatal signal whose default disposition is to terminate a process, which is exactly what happens in your example. The purpose of pipefail is to make the shell indicate when something has gone wrong anywhere in a pipeline. For most programs, SIGPIPE does not indicate that something went wrong. Instead, SIGPIPE is expected behavior. When pipefail spuriously reports expected behavior as an error, Bash comes less useful. You might consider trapping or ignoring SIGPIPE in situations where it might be an issue. If I were emperor of the world, I would make SIGPIPE's SIG_DFL action terminate the process with exit status 0. But POSIX says we can't do that. Even locally, I make my system do that without kernel surgery. It's also not reasonable to modify every program that might be part of a pipeline so that it exits successfully on EPIPE. Making Bash treat SIGPIPE death as success is the next best option. signature.asc Description: OpenPGP digital signature
readline and bash disagree on $'' quoting
Consider this command: foo $'foo \' bar' As far as the bash core is concerned, this command has one argument word. But readline, for completion, splits it up into three words: 0: foo 1: $'abc \' 2: bar' Shouldn't we be splitting the command line into the same number of words? signature.asc Description: OpenPGP digital signature
Re: forked before bash subshell
On 10/13/2016 08:05 PM, Bob Proulx wrote: XiaoBing Jiang wrote: Greg Wooledge wrote: If you want to ENSURE that the child shell process is replaced by the external sleep 20, use an explicit exec. yes, I want to know why bash not optimize this. or any strategy ? Because it wouldn't save anything significant. Since the parent shell is bash the extra bash in memory is already in memory. A forked process uses almost the same OS memory as the original. The OS will share the code pages between the two processes at the OS memory page level. Data pages will split when they are individually modified. Even if you use 'exec' to replace the forked and backgrounded copy another one is still in memory as the script runs. Only unique data pages will go through the copy-on-write process as the two bash processes diverge. Therefore even if you *think* you are saving something by optimizing it out the actual savings is insignificantly small. Plus this is really only a problem if the main part of the script exits leaving the forked subshell running in the background. However that is not a good thing to do. If you want to leave the process running that is a daemon process. Launching a daemon process needs more setup than this to avoid other problems. Since leaving processes behind like that is a bad thing to do it again doesn't make much sense to try to optimize the doing of it. It is possible to contrive some examples where it makes sense to do this optimization. But mostly they are very unusual cases. Not typical cases. One such case is Cygwin --- I'm not sure how "contrived" it is. Cygwin has an old-fashioned non-COW fork, and to add insult to injury, process creation generally is very slow (~100ms). It pays to eliminate subshells in that environment.
Re: [PATCH] Add active mark, face support; activate mark on paste
Hey. I'd appreciate a quick peek at this patch. The lack of visual feedback on paste is leading people to turn off bracketed paste mode, which is unfortunate. On Mon, Mar 19, 2018 at 11:06 AM, Chet Ramey wrote: > On 3/19/18 1:25 PM, Daniel Colascione wrote: > > Ping > > I haven't looked at it closely yet; trying to get bugs and tests done > before starting the 5.0-alpha release cycle. > > 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: Feature request: PROMPT_COMMANDS array variable
Sure, but you have a coordination problem. Everyone is going to use a different array name, and since scripts have no way of knowing in advance to what array they need to add their function, we end up the same spot. Putting the array in the core would solve the coordination problem. On Jan 23, 2018 7:05 PM, "Clark Wang" <dearv...@gmail.com> wrote: > On Wed, Jan 24, 2018 at 2:23 AM, Daniel Colascione <dan...@google.com> > wrote: > >> Right now, PROMPT_COMMAND gives a shell command to run before displaying >> the prompt. It's common these days to include in one's bash configuration >> numerous packages from different sources that *all* want to run code at >> PROMPT_COMMAND time. Can we add a new PROMPT_COMMANDS array variable that >> stores a list of shell commands to execute? With a PROMPT_COMMANDS >> variable, different packages can independently add their hooks without >> stepping on each other. >> > > I would define my own array var and go through it in PROMPT_COMMAND. (My > PROMPT_COMMAND is just a function name.) >
Feature request: PROMPT_COMMANDS array variable
Right now, PROMPT_COMMAND gives a shell command to run before displaying the prompt. It's common these days to include in one's bash configuration numerous packages from different sources that *all* want to run code at PROMPT_COMMAND time. Can we add a new PROMPT_COMMANDS array variable that stores a list of shell commands to execute? With a PROMPT_COMMANDS variable, different packages can independently add their hooks without stepping on each other.
[PATCH] Add active mark, face support; activate mark on paste
This patch teaches readline about two concepts from Emacs: 1) faces,
and 2) the mark being "active". Both exist in rudimentary form: we
support exactly two faces, normal and "standout", and use standout to
highlight the contents of the region when the mark is active. Readline
redisplay is now smart enough to consider not only text content, but
also face differences when computing how to refresh the screen.
The immediate motivation for this patch is to provide visual feedback
to users after a bracketed paste operation, but an active region
concept could be useful for all kinds of things, including shift-arrow
selection or integration with xterm mouse facilities.
The mark automatically deactivates after most commands, including C-g
and cursor motion. We do keep any active mark active across screen
refresh operations, however.
exchange-point-and-mark activates the mark just like in Emacs.
---
lib/readline/display.c | 478 +++
lib/readline/kill.c | 6 +-
lib/readline/readline.c | 19 ++
lib/readline/readline.h | 4 +
lib/readline/rlprivate.h | 5 +-
lib/readline/terminal.c | 43
lib/readline/text.c | 55 +++--
lib/readline/util.c | 1 +
8 files changed, 398 insertions(+), 213 deletions(-)
diff --git a/lib/readline/display.c b/lib/readline/display.c
index 2d2e768a..f228a39e 100644
--- a/lib/readline/display.c
+++ b/lib/readline/display.c
@@ -63,13 +63,13 @@
extern char *strchr (), *strrchr ();
#endif /* !strchr && !__STDC__ */
-static void update_line PARAMS((char *, char *, int, int, int, int));
+static void update_line PARAMS((char *, char *, char *, char *, int, int, int,
int));
static void space_to_eol PARAMS((int));
static void delete_chars PARAMS((int));
-static void insert_some_chars PARAMS((char *, int, int));
static void open_some_spaces PARAMS((int));
static void cr PARAMS((void));
static void redraw_prompt PARAMS((char *));
+static void _rl_move_cursor_relative PARAMS((int, const char *, const char *));
/* Values for FLAGS */
#define PMT_MULTILINE 0x01
@@ -80,6 +80,7 @@ static char *expand_prompt PARAMS((char *, int, int *, int *,
int *, int *));
struct line_state
{
char *line;
+char *line_face;
int *lbreaks;
int lbsize;
#if defined (HANDLE_MULTIBYTE)
@@ -102,7 +103,9 @@ static int line_structures_initialized = 0;
#define vis_lbsize (line_state_visible->lbsize)
#define visible_line (line_state_visible->line)
+#define visible_face (line_state_visible->line_face)
#define invisible_line (line_state_invisible->line)
+#define invisible_face (line_state_invisible->line_face)
#if defined (HANDLE_MULTIBYTE)
static int _rl_col_width PARAMS((const char *, int, int, int));
@@ -123,7 +126,10 @@ static int _rl_col_width PARAMS((const char *, int, int,
int));
to use prompt_last_invisible directly. */
#define PROMPT_ENDING_INDEX \
((MB_CUR_MAX > 1 && rl_byte_oriented == 0) ? prompt_physical_chars :
prompt_last_invisible+1)
-
+
+#define FACE_NORMAL '0'
+#define FACE_STANDOUT '1'
+#define FACE_INVALID ((char)1)
/* */
/* */
@@ -208,8 +214,8 @@ static int msg_bufsiz = 0;
/* Non-zero forces the redisplay even if we thought it was unnecessary. */
static int forced_display;
-/* Default and initial buffer size. Can grow. */
-static int line_size = 1024;
+/* Line buffer size. */
+static int line_size;
/* Variables to keep track of the expanded prompt string, which may
include invisible characters. */
@@ -521,6 +527,64 @@ rl_expand_prompt (prompt)
}
}
+static void
+ensure_line_size (minsize)
+ int minsize;
+{
+ int minimum_size = 1024;
+ int new_line_size, delta;
+ if (minsize < minimum_size)
+minsize = minimum_size;
+ if (line_size >= minsize)
+return;
+ if (!new_line_size)
+new_line_size = minimum_size;
+ while (new_line_size < minsize)
+new_line_size *= 2;
+ visible_line = (char *)xrealloc (visible_line, new_line_size);
+ visible_face = (char *)xrealloc (visible_face, new_line_size);
+ invisible_line = (char *)xrealloc (invisible_line, new_line_size);
+ invisible_face = (char *)xrealloc (invisible_face, new_line_size);
+ delta = new_line_size - line_size;
+ memset (visible_line + line_size, 0, delta);
+ memset (visible_face + line_size, FACE_NORMAL, delta);
+ memset (invisible_line + line_size, 1, delta);
+ memset (invisible_face + line_size, FACE_INVALID, delta);
+ line_size = new_line_size;
+}
+
+static void
+invis_add (outp, c, face)
+ int *outp;
+ char c;
+ char face;
+{
+ ensure_line_size (*outp + 1);
+ invisible_line[*outp] = c;
+ invisible_face[*outp] = face;
+ *outp += 1;
+}
+
+static void
+invis_add_n (outp, str, n, face)
+ int *outp;
+ const char *str;
+ int n;
+ char face;
+{
+ int i;
+ for (i = 0; i < n; ++i)
+invis_add (outp, str[i], face);
+}
Re: [PATCH] Add active mark, face support; activate mark on paste
Ping
On Fri, Mar 9, 2018 at 11:50 PM, Daniel Colascione <dan...@google.com>
wrote:
> This patch teaches readline about two concepts from Emacs: 1) faces,
> and 2) the mark being "active". Both exist in rudimentary form: we
> support exactly two faces, normal and "standout", and use standout to
> highlight the contents of the region when the mark is active. Readline
> redisplay is now smart enough to consider not only text content, but
> also face differences when computing how to refresh the screen.
>
> The immediate motivation for this patch is to provide visual feedback
> to users after a bracketed paste operation, but an active region
> concept could be useful for all kinds of things, including shift-arrow
> selection or integration with xterm mouse facilities.
>
> The mark automatically deactivates after most commands, including C-g
> and cursor motion. We do keep any active mark active across screen
> refresh operations, however.
>
> exchange-point-and-mark activates the mark just like in Emacs.
> ---
> lib/readline/display.c | 478 +++
> lib/readline/kill.c | 6 +-
> lib/readline/readline.c | 19 ++
> lib/readline/readline.h | 4 +
> lib/readline/rlprivate.h | 5 +-
> lib/readline/terminal.c | 43
> lib/readline/text.c | 55 +++--
> lib/readline/util.c | 1 +
> 8 files changed, 398 insertions(+), 213 deletions(-)
>
> diff --git a/lib/readline/display.c b/lib/readline/display.c
> index 2d2e768a..f228a39e 100644
> --- a/lib/readline/display.c
> +++ b/lib/readline/display.c
> @@ -63,13 +63,13 @@
> extern char *strchr (), *strrchr ();
> #endif /* !strchr && !__STDC__ */
>
> -static void update_line PARAMS((char *, char *, int, int, int, int));
> +static void update_line PARAMS((char *, char *, char *, char *, int, int,
> int, int));
> static void space_to_eol PARAMS((int));
> static void delete_chars PARAMS((int));
> -static void insert_some_chars PARAMS((char *, int, int));
> static void open_some_spaces PARAMS((int));
> static void cr PARAMS((void));
> static void redraw_prompt PARAMS((char *));
> +static void _rl_move_cursor_relative PARAMS((int, const char *, const
> char *));
>
> /* Values for FLAGS */
> #define PMT_MULTILINE 0x01
> @@ -80,6 +80,7 @@ static char *expand_prompt PARAMS((char *, int, int *,
> int *, int *, int *));
> struct line_state
>{
> char *line;
> +char *line_face;
> int *lbreaks;
> int lbsize;
> #if defined (HANDLE_MULTIBYTE)
> @@ -102,7 +103,9 @@ static int line_structures_initialized = 0;
> #define vis_lbsize (line_state_visible->lbsize)
>
> #define visible_line (line_state_visible->line)
> +#define visible_face (line_state_visible->line_face)
> #define invisible_line (line_state_invisible->line)
> +#define invisible_face (line_state_invisible->line_face)
>
> #if defined (HANDLE_MULTIBYTE)
> static int _rl_col_width PARAMS((const char *, int, int, int));
> @@ -123,7 +126,10 @@ static int _rl_col_width PARAMS((const char *, int,
> int, int));
> to use prompt_last_invisible directly. */
> #define PROMPT_ENDING_INDEX \
>((MB_CUR_MAX > 1 && rl_byte_oriented == 0) ? prompt_physical_chars :
> prompt_last_invisible+1)
> -
> +
> +#define FACE_NORMAL '0'
> +#define FACE_STANDOUT '1'
> +#define FACE_INVALID ((char)1)
>
> /* */
> /* */
> @@ -208,8 +214,8 @@ static int msg_bufsiz = 0;
> /* Non-zero forces the redisplay even if we thought it was unnecessary. */
> static int forced_display;
>
> -/* Default and initial buffer size. Can grow. */
> -static int line_size = 1024;
> +/* Line buffer size. */
> +static int line_size;
>
> /* Variables to keep track of the expanded prompt string, which may
> include invisible characters. */
> @@ -521,6 +527,64 @@ rl_expand_prompt (prompt)
> }
> }
>
> +static void
> +ensure_line_size (minsize)
> + int minsize;
> +{
> + int minimum_size = 1024;
> + int new_line_size, delta;
> + if (minsize < minimum_size)
> +minsize = minimum_size;
> + if (line_size >= minsize)
> +return;
> + if (!new_line_size)
> +new_line_size = minimum_size;
> + while (new_line_size < minsize)
> +new_line_size *= 2;
> + visible_line = (char *)xrealloc (visible_line, new_line_size);
> + visible_face = (char *)xrealloc (visible_face, new_line_size);
> + invisible_line = (char *)xrealloc (invisible_line, new_line_size);
> + invisible_face = (char *)xrealloc (invisible_face, n
Re: [PATCH] Add active mark, face support; activate mark on paste
Any chance we can revive this patch now that Bash 5 is out? (The patch itself, of course, would need to be rebased.) On Fri, Jun 8, 2018 at 9:27 AM Chet Ramey wrote: > > On 6/7/18 10:45 PM, Daniel Colascione wrote: > > Hey. I'd appreciate a quick peek at this patch. The lack of visual feedback > > on paste is leading people to turn off bracketed paste mode, which is > > unfortunate. > > I've looked at it briefly. I have not had time to put it into the devel > branch yet; probably after bash-5.0 is released. > > -- > ``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/
[FR] save command times and exit status in history automatically
Right now, bash history saves only the command line actually executed. Why not also, optionally, save command execution times and exit statuses? This information is practically free to collect.
Re: [FR] save command times and exit status in history automatically
On Thu, Nov 7, 2019 at 12:09 PM Chet Ramey wrote: > > On 11/5/19 12:49 PM, Daniel Colascione wrote: > > Right now, bash history saves only the command line actually executed. > > This isn't quite the case. What it saves is the line returned from > readline, before it's expanded or executed. Fair enough. > > Why not also, optionally, save command execution times and exit > > statuses? This information is practically free to collect. > > Because by the time you gather this information, the command has already > been saved completely. > > There have been various proposals to extend the timestamp with additional > information, but it's all data you can gather when the timestamp is saved > before the command is executed. That's how history works today, yes. I'm wondering whether it'd be possible to maintain an auxiliary history that included not only the command lines read, but also their execution time and outcome. Doing something in PROMPT_COMMAND doesn't seem quite accurate. Maybe what I really want is something like $?, but instead of containing exit status, it would contain information from a struct rusage (derived from wait4) for the last command. Or something like that anyway. The larger point is that the shell could gather this information proactively almost for free and I don't think user code running in existing shell extension points can do the same job.
Re: [PATCH] Add active mark, face support; activate mark on paste
On Mon, Sep 23, 2019 at 6:36 AM Chet Ramey wrote: > > On 9/23/19 7:32 AM, Daniel Colascione wrote: > > On Wed, Jan 9, 2019 at 12:37 PM Chet Ramey wrote: > >> > >> On 1/9/19 2:39 PM, Daniel Colascione wrote: > >>> Any chance we can revive this patch now that Bash 5 is out? (The patch > >>> itself, of course, would need to be rebased.) > >> > >> Yes, I plan to. > > > > Have you had a chance to look at the patch? > > Sorry, I have not. I need a bigger chunk of time than I've had available > to figure out the intent of the patches, and whether they're a good idea > to include in readline, before looking closely at the code. I've had a people tell me that this patch is very useful for helping them understand editing operations and pasting. I sent this patch over a year and a half ago. Should I expect another year and a half of pinging this thread? :-)
Re: [PATCH] Add active mark, face support; activate mark on paste
On Wed, Jan 9, 2019 at 12:37 PM Chet Ramey wrote: > > On 1/9/19 2:39 PM, Daniel Colascione wrote: > > Any chance we can revive this patch now that Bash 5 is out? (The patch > > itself, of course, would need to be rebased.) > > Yes, I plan to. Have you had a chance to look at the patch?
Re: "wait" loses signals
> Date:Mon, 24 Feb 2020 06:44:12 -0800 > From: "Daniel Colascione" > Message-ID: > > | That executing traps except in case you lose one rare race is > painfully > | obvious. > > Maybe you misunderstand the issue, no traps are lost, if they were > that would indeed be a bug, the trap will always be executed in the > cases in question, the only issue is when that happens. They're not executed before the wait as is supposed to happen though, so we can hang when we shouldn't. > | This opposition to doing more than the bare minimum that the standard > | requires makes this task all the much harder. > > I am not at all opposed to doing more than the standard requires, the > shell I maintain does more (not nearly as many addons as bash, but > considerably more than bash - and in some areas we're ahead, we already > have a wait command where it is possible to wait for any one of a set > of processes (or jobs) and be told which one completed, for example). > > I'm also not opposed to doing less when the standard is nonsense, which > it is in a couple of places. > > But "I want x" or "I think it should be y" aren't good enough reasons to > change something, and making the shell useful for (very primitive) IPC > isn't a good reason for making updates. Yes, it is, because people find this style of IPC useful today, and it's worthwhile to make this use reliable. > | Making people go elsewhere *on purpose* by refusing to fix bugs is not > | good software engineering. > > Of course. I don't see a bug. You can interpret any random bit of brokenness as a feature. Whether the behavior is a "bug" or not is irrelevant: bash _should_ be handling these traps as early as possible, because that simplifies the programming model without hurting anything else. > | We're talking about fixing an existing shell feature, not adding a new > one. > > OK, here's an alternative, I want the shell to be able to do arithmetic on > arbitrarily large (and small) numbers. All that is needed to fix it is > to link in the bignum library and use it (and extend the parser a little > to > handle real numbers). This situation is more like bash supporting arbitrary-precision addition and giving the wrong answer when the number is prime. "Oh, we never promised support for _prime_ sums. It's not a bug. It's just a thing the shell doesn't do." > | This moralistic outlook is not helpful. It doesn't *matter* whether a > | program is right or wrong or making unjustified assumptions or not. > > That is unbelievable. That is all that matters. If the program is > wrong, the program needs to be fixed, not the world altered so that the > program suddely works. You want to increase the number of correct programs in the world. Sometimes the fix is to declare incorrect programs broken and have people fix them. Other times, in situations like this one, it's better to just change the infrastructure so that the program is correct. > > | Punishing programs does not make the world does not make the world > better. > > It does. The bad ones fail, and are replaced by better ones. Computer security was even more of a horrible nightmare than it is today back when people had this attitude. "Why should we use stack hardening? If a program writes beyond the end of an array, that's a bug in the program." Nice sentiment. Doesn't work.
Re: "wait" loses signals
> There are lots of programming languages around, they each have their > particular > niche - the reason their inventors created them in the first place. Use > an > appropriate one, rather than attempting to shoehorn some feature that is > needed > into a language that was never intended for it - just because you happen > to > be a big fan of that language. Spread your wings, learn a new one That is a poor excuse for not fixing bugs. Maybe you can torture the standards into confessing that this behavior isn't a bug. This behavior nevertheless surprises people and nevertheless precludes various things people want to do with a shell. Don't you think it's better that programs work reliably than that they don't? Of course something working intuitively 99.9% of the time and hanging 0.1% of the time is a bug. It's not appropriate to treat that 0.1% hang as some kind of cosmic punishment for using shell in a manner you find inappropriate: remember when we believed in mechanism, not policy? Nor is the presence of the bug in other shells adequate justification for leaving this one in a bad state. I've never understood the philosophy of people who want to leave bugs unfixed. No, it's not that much trouble to fix the bug. The techniques for fixing this kind of signal race are well-known. In particular, instead of waitpid, you use a self-pipe and signal the pipe in the signal handler, and you have a signal handler for SIGCHLD. If we had a pwaitpid (like pselect) we could use that too. If I could get Chet to look at my patches, I'd fix it myself.
Re: "wait" loses signals
> Date:Mon, 24 Feb 2020 04:58:31 -0800 > From: "Daniel Colascione" > Message-ID: <07d1441d41280e6f9535048d6485.squir...@dancol.org> > > | That is a poor excuse for not fixing bugs. > > Only if they are bugs. That executing traps except in case you lose one rare race is painfully obvious. > > | Maybe you can torture the standards into confessing that this > | behavior isn't a bug. > > No torture required. Once again, the standard documents the way users > can expect shells to behave. I refuse to let the standard cap the quality of a shell's implementation. Missing signals this way is pure negative. It doesn't add to any capability or help any user. It can only make computing unreliable and hurt real users trying to automate things with shell. > That is what a standard is - a common set > of agreed operations A standard is a bare minimum. > attempt to get shells to change this way of > working, and if you can get a suitable set to agree, and implement > something > new, that more meets your needs, then perhaps that might one day become > the > standard, This opposition to doing more than the bare minimum that the standard requires makes this task all the much harder. > | This behavior nevertheless surprises people > > Lots of things surprise people. Sometimes people deserve to be surprised. This isn't one of those times. > | and nevertheless precludes various things > | people want to do with a shell. > > That was my point, that you just labelled a poor excuse. Not everything > is suitable for implementation in sh. Sometimes you simply have to go > elsewhere. Making people go elsewhere *on purpose* by refusing to fix bugs is not good software engineering. > Wanting to do it in shell doesn't make it reasonable or > possible. It is reasonable and possible. All that's needed is to make an existing operation that's almost perfectly reliable in fact perfectly reliable, and as I've mentioned, it's not that hard. > I want the shell to feed my dog, where is the dogfood option? We're talking about fixing an existing shell feature, not adding a new one. > | Don't you think it's better that programs > | work reliably than that they don't? > > Yes, when they are written correctly. By fixing this bug, we make a class of programs correct automatically. > > | Of course something working intuitively 99.9% of the time and > | hanging 0.1% of the time is a bug. > > Nonsense. An alternative explanation is that your intuition is wrong, > and that it often works that way is just by chance. We're talking about a documented feature that users expect to work a certain way and that almost always *does* work that way and that diverges from this behavior only under rare circumstances. Not the same as spacebar heating. > The program is > broken because it is making unjustified assumptions about how things are > specified to work. This moralistic outlook is not helpful. It doesn't *matter* whether a program is right or wrong or making unjustified assumptions or not. Punishing programs does not make the world does not make the world better. When a piece of infrastructure can transform these programs from incorrect to correct at next to zero cost, it behooves that infrastructure component to do that. > This is the kind of common error that people who > program (in any language) by guesswork often make "I saw Fred did this, > and I tried it, and it worked for me like I thought it would, so it > must do this similar thing like I think it will too". Rubbish. Ever hear of the "pit of success"? It's the idea that software gets better when you make the intuitive thing happen to be the correct thing. Why should we require a degree of cleverness greater than what a domain requires? Why *not* make it so that, to the greatest extent possible, shouldn't we let "I saw Fred do this" lead people to good patterns? Like I said before, making things difficult on purpose doesn't actually achieve anything. [1] https://docs.microsoft.com/en-us/archive/blogs/brada/the-pit-of-success > > | I've never understood the philosophy of people who want to leave > | bugs unfixed. > > Nor have I, except sometimes perhaps when it comes to costs. But the > issue here is whether this is a bug. Your belief that it is does not make > it so. Your belief that this behavior is acceptable doesn't make it so --- except under a pointlessly literal interpretation of the standards. > | No, it's not that much trouble to fix the bug. > > It isn't, if it needs fixing - but any fix for this will slow the shell > (for what that matters, but some people care). Further there are simpler > cheaper techniques than the one described. The fix for this issue will not
Re: [PATCH] Add active mark, face support; activate mark on paste
On Tue, Sep 24, 2019 at 10:20 PM Daniel Colascione wrote: > > On Mon, Sep 23, 2019 at 6:36 AM Chet Ramey wrote: > > > > On 9/23/19 7:32 AM, Daniel Colascione wrote: > > > On Wed, Jan 9, 2019 at 12:37 PM Chet Ramey wrote: > > >> > > >> On 1/9/19 2:39 PM, Daniel Colascione wrote: > > >>> Any chance we can revive this patch now that Bash 5 is out? (The patch > > >>> itself, of course, would need to be rebased.) > > >> > > >> Yes, I plan to. > > > > > > Have you had a chance to look at the patch? > > > > Sorry, I have not. I need a bigger chunk of time than I've had available > > to figure out the intent of the patches, and whether they're a good idea > > to include in readline, before looking closely at the code. > > I've had a people tell me that this patch is very useful for helping > them understand editing operations and pasting. I sent this patch over > a year and a half ago. Should I expect another year and a half of > pinging this thread? :-) Is there anything I can do to get this patch looked at?
Re: Request For Enhancement - TID variable
On 12/26/19 7:37 AM, Eric S. Raymond wrote: In attempting to use GNU parallel, with some bash scripts, I discovered I had a problem with tempfile collisions due to all of the thread having the same PID. I was able to come up with a workaround, but... RFE: bash should have a TID varuable that returns the vakue of gettid(2). If the bash devs are too busy for this like the idea, I could write the patch. Are you sure that'd help? Parallel runs bash in a bunch of subprocesses, so looking at PID would suffice to distinguish jobs. Are you sure you weren't seeing an invariant PID because you were letting the PID variable expansion happen too early?
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 4/12/20 6:23 PM, Chet Ramey wrote: On 4/12/20 2:15 PM, gentoo_esh...@tutanota.com wrote: There is one more/different 'face' issue: if I paste a line and then press Enter (as opposed to any alphanumeric key or arrow keys) then the highlight remains(highlighted), possibly because the ^M is echoed and thus moves the cursor one line up(?) before the highlight is attempted to be removed. But I'm just guessing. Unsurprising. The highlights are added and removed in readline's redisplay. Once you enter newline (or any key bound to accept-line), readline returns the line immediately without any redisplay, so the line remains as is. Is that a regression relative to my original patch? I could have sworn I made command submission deactivate the mark and redisplay, but maybe I'm recalling incorrectly. In any case, isn't that the right thing to do? FWIW, for debugging the kinds of issues we're discussing here, rr(1) is _incredibly_ helpful.
Re: [PATCH] Add active mark, face support; activate mark on paste
On Fri, Jan 10, 2020 at 5:34 AM Chet Ramey wrote: > > On 1/8/20 2:38 PM, Daniel Colascione wrote: > > On Tue, Sep 24, 2019 at 10:20 PM Daniel Colascione > > wrote: > >> > >> On Mon, Sep 23, 2019 at 6:36 AM Chet Ramey wrote: > >>> > >>> On 9/23/19 7:32 AM, Daniel Colascione wrote: > >>>> On Wed, Jan 9, 2019 at 12:37 PM Chet Ramey wrote: > >>>>> > >>>>> On 1/9/19 2:39 PM, Daniel Colascione wrote: > >>>>>> Any chance we can revive this patch now that Bash 5 is out? (The patch > >>>>>> itself, of course, would need to be rebased.) > >>>>> > >>>>> Yes, I plan to. > >>>> > >>>> Have you had a chance to look at the patch? > >>> > >>> Sorry, I have not. I need a bigger chunk of time than I've had available > >>> to figure out the intent of the patches, and whether they're a good idea > >>> to include in readline, before looking closely at the code. > >> > >> I've had a people tell me that this patch is very useful for helping > >> them understand editing operations and pasting. I sent this patch over > >> a year and a half ago. Should I expect another year and a half of > >> pinging this thread? :-) > > > > Is there anything I can do to get this patch looked at? > > I haven't taken the time to sit down and look at it. That's my bad. Ping? Anything I can do to help?
Re: Are there any plans for more readable, modern syntaxes for If statements?
> I keep on wondering why these shells can't come up with something better > than improving previous shell syntax by little by only providing poor > better alternatives. > I somehow think there is a need to rethink shells from scratch to make > them > less mentally demanding and readable in the command prompt and scripts > themselves. > I really haven't seen anything that I would like to use so far. Neither > zsh, tcsh or any other of the more popular ones as far as I remember from > the last weeks "personal research". > fish shell and powershell are two reasonable attempts. I think current shell syntax is fine though.
Re: [PATCH] Add active mark, face support; activate mark on paste
> On 3/25/20 1:14 PM, Daniel Colascione wrote: > >> Ping? Anything I can do to help? > > OK, I sat down and looked at this code, since I'm homebound. I added the > active mark/region features (rl_activate_mark/rl_deactivate_mark/etc.) > and a couple of the smaller pieces (_rl_cr, the so/se sequences). Thanks! > Can you > tell me why you decided to make the region management functions public? > Did you anticipate external application functions wanting to manage the > region? I was imagining applications wanting to highlight certain regions, e.g., a shell showing which command in a pipeline failed. You can also imagine a readline user supporting something like xterm-mouse-mode. Making the region functions public isn't essential right now though. > I haven't touched the face code in display.c. I'd like to find a simpler > way to do it: the patch seems to have a lot of overhead and adds more > complexity than I'd like at a time when I'm trying to make the redisplay > code simpler. I don't know of a better way to do that yet. The redisplay code needs to track the intended attribute state of each character in the buffer. I'm not sure what simpler approach might be viable. Fat characters? You'd still have to support the old char* interface, and you'd still need something like puts_face to "propertize" any strings we add to the buffer. A face system preserves the existing format of the buffer at least, and the redisplay update code is a logical extension of the current diffing logic.
Re: Proposed new feature for bash: unbuffered pipes
On April 22, 2020 6:32:07 PM wor...@alum.mit.edu (Dale R. Worley) wrote: The crux of the problem, IMHO, is to look at it from the right angle: Occasionally, the user desires that I/O through certain pipes should be unbuffered, that is, the stdio stream(s) that write into the pipe should be unbuffered, rather than the default block-buffered. These are situations where the user can tell that it is desirable to sacrifice efficiency to gain low latency, whereas the writer of the program that the user is running could not predict the needs of this particular invocation. (This is where Ulrich Drepper was incorrect; the writer of the program doesn't know when this is desirable.) This facility is best activated by a feature in bash, as the need arises from the relationship between two processes. The ideal way to implement this would be for the kernel to provide two flavors of pipe, one designated buffered and one designated unbuffered, and according to the user's instructions, bash would allocate an unbuffered pipe when it was needed. The kernel itself would treat the two types of pipe in the same way, but stdio would create buffered streams for fd's that were opened on buffered pipes and it would create unbuffered streams for fd's that were opened on unbuffered pipes. However, getting a coordinated change into the kernel seems like it would be quite difficult. So an alternative implementation is to have a way for bash to notify processes it creates that certain pipes (identified by their dev/ino numbers) should have streams that are unbuffered. Pretty much the only way to do this is to have a conventional environment variable for communicating this information. Of course, either of these solutions requires changes to glibc, but then, if you're going to modify buffering behavior of streams, you are going to have to modify glibc. Given the current political realities in the relevant FOSS ecosystem, it might be easier to add a new pipe flavor or attribute to the kernel and then get libc implementations to support it as a fait accompli than to do something purely in libc. Also, an environment variable is semantically wrong: its scope is too broad, well beyond the specific pipe you care about. Imagine the variable leaking into a daemon that lives forever.
Re: Proposed new feature for bash: unbuffered pipes
On 4/23/20 4:39 PM, Dale R. Worley wrote: Andreas Schwab writes: See stdbuf(1). The limitation(s) of stdbuf are: It can only be applied to the standard I/O streams. It doesn't affect statically-linked executables. It only applies to a single executable, so if the command is a shell function or script, or creates subprocesses, it doesn't affect them. If you want to define an environment variable for affecting stdout buffering, you can. (Good luck getting any libc to implement the support you're imagining: libc authors are *very* conservative about everything.) But whether or not you have this environment variable, you don't need special bash syntax to set it: you can just prefix the command you want with an environment variable assignment. I don't think the need you're discussing is widespread enough to warrant further complicating shell syntax. A much simpler option might be just convincing libc people to make line-buffering the default whether isatty or not. Machines are very fast these days, and any program that _knows_ it's emitting non-line-oriented data can opt into full buffering.
Re: execve E2BIG (Argument list too long)
On September 30, 2020 8:24:01 AM Ilkka Virta wrote: On Wed, Sep 30, 2020 at 5:53 PM Michael Green wrote: The included short script when run with the following command results in execve "E2BIG (Argument list too long) errors". * The number of arguments can be tuned down to "seq 1 23694" and it still occurs, but any lower and it disappears. That sounds a lot like the 128 kB hard limit Linux puts on the size of a single argument to exec. (I know it counts for command line arguments, I expect it also counts for env variables. They're passed in pretty much the same way anyway.) It might be worth asking lkml to lift this restriction seq 1 23694 | wc gives 131058, just a bit less than 131072. Add the variable name and it goes over. Workaround: use another OS, or pass big data like that in files.
Re: execve E2BIG (Argument list too long)
On September 30, 2020 8:44:40 AM Andreas Schwab wrote: On Sep 30 2020, Daniel Colascione wrote: It might be worth asking lkml to lift this restriction You will have bad luck with that. The limit has been introduced for security reasons. What "security reasons"? You'd still be subject to the stack ulimit, which you can set to whatever you want.
Re: Possible race condition in bash
On 11/21/20 1:15 PM, Chet Ramey wrote: On 11/21/20 2:32 PM, Andreas Schwab wrote: On Nov 21 2020, Chet Ramey wrote: but since the shell always ignores SIGTERM, Even a non-interactive shell? No, you're right, it's SIGQUIT the shell always ignores. It catches SIGTERM if there is an EXIT trap so it can run the trap on EXIT before exiting. I'd also try it with one of the bash-5.1 testing releases, since I did some reworking of how the shell handles SIGTERM back in April. 5.1-rc3 has the same issue. OK, I instrumented bash a little bit, and discovered that the second child doesn't start running, or at least doesn't get to the point in the subshell initialization where it resets the signal handlers, until after the parent sends SIGTERM. That means the trap handler is still set to catch SIGTERM by the time the signal arrives. However, the child is not allowed to run the trap handler; it's supposed to reset the dispositions to the default. This is the race condition. It's a dilemma. I could block SIGTERM (all trapped signals, really) until the child resets the signal dispositions, but that seems like a long time to keep signals blocked. I'll look at it some more after bash-5.1 is released. Plenty of other programs keep signals blocked until reset. I don't see the problem with the delay: if the SIGTERM is ignored, the delay between SIGTERM and kill is infinite. :-) Since the delay between process-kill and actual process death can be arbitrarily long anyway (that's the contract with the kernel), I don't see a problem with the blocking.
Re: Feature Request: scanf-like parsing
On 1/25/21 11:59 AM, Greg Wooledge wrote:
On Mon, Jan 25, 2021 at 06:47:36PM +0200, Oğuz wrote:
25 Ocak 2021 Pazartesi tarihinde Chet Ramey yazdı:
declare -A copy
eval copy=( "${assoc[@]@K}" )
So many reputable people contributed to the demonization of `eval' that I
don't think I can convince anyone that there's nothing wrong with it
anymore.
It's a tricky thing to deal with. Eli referenced my wiki, which has a
page dedicated to it, with contributions from many different authors.
The resulting quasi-consensus is complex and perhaps even a little
bit self-contradictory as a result.
You'll want to use eval only when it's absolutely necessary, and only when
it's safe. If bash's @K feature is designed to be fed to eval, then we
can assume it's safe. It becomes one of the very small number of
green-lighted cases where eval is OK.
The problem with eval is that for every OK usage, there are a thousand
incorrect and dangerous uses. Avoid those, by being absolutely sure
you know what you're doing, and why you're doing it.
And it's also worth systematically creating alternatives for all the
safe and legitimate uses of "eval" so that eventually the whole
mechanism can be discouraged without having to rely on the nuance you've
just described.
Re: Feature Request: scanf-like parsing
On 1/22/21 9:54 AM, Saint Michael wrote: I vote for this new feature. Personally, I've found that scanf underpowered for parsing modern data formats. Bash's existing regular expression support seems perfectly adequate to me, and it can handle everything that scanf can. I'd only suggest extending the regular expression syntax with support for named subgroups.
