Re: Remaining memory corruption bugs in readline
On Fri, Jun 02, 2017 at 12:07:34AM -0500, dualbus wrote: [...] > #1 _rl_get_char_len / update_line [...] > ==5781==ERROR: AddressSanitizer: heap-buffer-overflow on address > 0x6190cc80 at pc 0x7f400d00b063 bp 0x7ffcbce72250 sp 0x7ffcbce71a00 > READ of size 851 at 0x6190cc80 thread T0 > #0 0x7f400d00b062 (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062) > #1 0x559b50a04821 in _rl_get_char_len > ../../../bash/lib/readline/mbutil.c:223 > #2 0x559b50a048e0 in _rl_compare_chars > ../../../bash/lib/readline/mbutil.c:252 > #3 0x559b509db526 in update_line > ../../../bash/lib/readline/display.c:1664 [...] I have been looking at this specific example for some time now. The problem is that _rl_get_char_len assumes it's being called with a \0-terminated string, but under some cases (that I haven't been able to figure out), there's no \0 at the end, so the strlen reads more than it should. -- Eduardo Bustamante https://dualbus.me/
Re: [PATCH] Memory leak in locale.c set_default_locale
On Thu, Jun 08, 2017 at 09:59:39AM -0400, Chet Ramey wrote: [...] > Even though glibc allocates the memory for the current locale, the man page > warns not to assume that: > > "A successful call to setlocale() returns an opaque string that corre- > sponds to the locale set. This string may be allocated in static storage." Yes. I saw the warning in the manual page. After a closer reading, I think the Address Sanitizer is complaining about bash's local copy (the one created with `savestring`) not being released. It's not a real issue, but it makes running the tests with ASAN a bit less useful. -- Eduardo Bustamante https://dualbus.me/
[PATCH] Memory leak in locale.c set_default_locale
Found by running the test suite under ASAN.
=
==3298==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 12 byte(s) in 1 object(s) allocated from:
#0 0x7f2b94db1d28 in malloc
(/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28)
#1 0x558589eb06d6 in xmalloc
(/home/dualbus/src/gnu/bash-build/bash+0x14f6d6)
#2 0x558589ea2c62 in set_default_locale
(/home/dualbus/src/gnu/bash-build/bash+0x141c62)
#3 0x558589de17f0 in main
(/home/dualbus/src/gnu/bash-build/bash+0x807f0)
#4 0x7f2b945442b0 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
SUMMARY: AddressSanitizer: 12 byte(s) leaked in 1 allocation(s).
*** /tmp/R6GbnO_locale.c2017-06-07 20:40:25.575118629 -0500
--- locale.c2017-06-07 20:39:59.054419575 -0500
***
*** 85,91
textdomain (PACKAGE);
locale_mb_cur_max = MB_CUR_MAX;
! locale_utf8locale = locale_isutf8 (default_locale);
locale_shiftstates = mblen ((char *)NULL, 0);
}
--- 85,98
textdomain (PACKAGE);
locale_mb_cur_max = MB_CUR_MAX;
! locale_utf8locale = 0;
! #if defined (HAVE_SETLOCALE)
! if (default_locale)
! {
! locale_utf8locale = locale_isutf8 (default_locale);
! free (default_locale);
! }
! #endif /* HAVE_SETLOCALE */
locale_shiftstates = mblen ((char *)NULL, 0);
}
--
Eduardo Bustamante
https://dualbus.me/
Re: Patch for unicode in varnames...
On Tue, Jun 06, 2017 at 10:20:03AM -0400, Greg Wooledge wrote: [...] > (OK, in reality, I am not taking any of this seriously. This entire > proposal and discussion are like some bizarre fantasy land to me. Bash > is a SHELL, for god's sake. Not a serious programming language. Even > serious programming languages are not ready for this; see the Python > proposal that was mentioned up-thread.) To be fair, that Python Enhancement Proposal (PEP 3131) was accepted around 10 years ago. It seems to have landed in the Python 3.x series. I brought it up for other reasons, specifically, to point out the complications that arise from implementing non-ASCII identifiers (to support my argument that there's a high cost in implementing this feature). -- Eduardo Bustamante https://dualbus.me/
Re: Patch for unicode in varnames...
On Mon, Jun 05, 2017 at 04:52:19AM -0400, George wrote:
[...]
> To hazard a guess: Each call to legal_identifier() and assignment() in
> the patched code requires copying the parameter and translating it to
> a wide-character string (with no provision for skipping the added work
> as a build option). It appears the memory allocated for these copies
> leaks (I didn't see any added calls to xfree() to go with those new
> xmallocs()), and the character type for the character conversion is
> derived from the user's locale (which means there's not a reliable
> mechanism in place to run a script in a locale whose character
> encoding doesn't match that of the script.) And he did mention "issues
> with compound assignments" as well. Those issues would need to be
> resolved.
Correct. There's also mixed use of wide-character strings and normal
strings, because that was easier to hack quickly.
By the way, ksh93 and zsh already support Unicode identifiers:
dualbus@debian:~$ for sh in bash mksh ksh93 zsh; do LC_CTYPE=en_US.utf8 $sh
-c 'φ=phi; echo $φ'; done
bash: φ=phi: command not found
$φ
mksh: φ=phi: not found
$φ
phi
phi
And all of these four support Unicode function names:
dualbus@debian:~$ for sh in bash mksh ksh93 zsh; do LC_CTYPE=en_US.utf8
$sh -c 'φ() { echo hi; }; φ'; done
hi
hi
hi
hi
--
Eduardo Bustamante
https://dualbus.me/
Re: RFE: Please allow unicode ID chars in identifiers
On Sun, Jun 04, 2017 at 01:46:23AM +0700, PePa wrote:
[...]
> But the fact that unicode functions are already supported does seem to
> pave the way for allowing variable names in unicode. For consistency, it
[...]
I know I said I wasn't going to reply, but this changed my mind :-)
I hadn't realized that bash already supports Unicode in function names!
FWIW:
bash-4.4$
Lēv=?
Φ=0.618033988749894848
ɸ=1.61803398874989485
π=3.14159265358979324
declare -p Lēv Φ ɸ π
declare -- Lēv="?"
declare -- Φ="0.618033988749894848"
declare -- ɸ="1.61803398874989485"
declare -- π="3.14159265358979324"
With this terrible patch:
dualbus@debian:~/src/gnu/bash$ PAGER= git diff
diff --git a/general.c b/general.c
index 584e7859..40db7b1d 100644
--- a/general.c
+++ b/general.c
@@ -61,6 +61,9 @@ extern int errno;
# include
#endif
+#define wlegal_variable_starter(c) (iswalpha(c) || (L'_' == c))
+#define wlegal_variable_char(c) (iswalnum(c) || (L'_' == c))
+
static char *bash_special_tilde_expansions __P((char *));
static int unquoted_tilde_word __P((const char *));
static void initialize_group_array __P((void));
@@ -214,15 +217,25 @@ int
legal_identifier (name)
const char *name;
{
- register const char *s;
- unsigned char c;
+ wchar_t *s, *wstring;
+ wchar_t c;
+ size_t n;
+
+ if (!name || *name == '\0')
+return (0);
+
+ n = mbstowcs(NULL, name, 0);
+ if((size_t) -1 == n) return 0;
+ wstring = xmalloc(sizeof(wchar_t) * (n+1));
+ n = mbstowcs(wstring, name, n);
+ if((size_t) -1 == n) return 0;
- if (!name || !(c = *name) || (legal_variable_starter (c) == 0))
+ if (wlegal_variable_starter (*wstring) == 0)
return (0);
- for (s = name + 1; (c = *s) != 0; s++)
+ for (s = wstring + 1; (c = *s) != 0; s++)
{
- if (legal_variable_char (c) == 0)
+ if (wlegal_variable_char (c) == 0)
return (0);
}
return (1);
@@ -357,27 +370,31 @@ assignment (string, flags)
const char *string;
int flags;
{
- register unsigned char c;
+ wchar_t c;
register int newi, indx;
+ wchar_t *wstring;
+ int n;
+ size_t len;
- c = string[indx = 0];
-
+ len = strlen(string);
+ if ((n=mbtowc(, [indx = 0], len)) < 1) return (0);
+ indx += n; len -= n;
#if defined (ARRAY_VARS)
- if ((legal_variable_starter (c) == 0) && ((flags&1) == 0 || c != '[')) /* ]
*/
+ if ((wlegal_variable_starter (c) == 0) && ((flags&1) == 0 || c != L'[')) /*
] */
#else
- if (legal_variable_starter (c) == 0)
+ if (wlegal_variable_starter (c) == 0)
#endif
return (0);
- while (c = string[indx])
+ while ((n=mbtowc(, [indx], len)) > 0)
{
/* The following is safe. Note that '=' at the start of a word
is not an assignment statement. */
- if (c == '=')
+ if (c == L'=')
return (indx);
#if defined (ARRAY_VARS)
- if (c == '[')
+ if (c == L'[')
{
newi = skipsubscript (string, indx, (flags & 2) ? 1 : 0);
if (string[newi++] != ']')
@@ -389,15 +406,15 @@ assignment (string, flags)
#endif /* ARRAY_VARS */
/* Check for `+=' */
- if (c == '+' && string[indx+1] == '=')
+ if (c == L'+' && string[indx+1] == '=')
return (indx + 1);
/* Variable names in assignment statements may contain only letters,
digits, and `_'. */
- if (legal_variable_char (c) == 0)
+ if (wlegal_variable_char (c) == 0)
return (0);
- indx++;
+ indx += n; len -= n;
}
return (0);
}
It seems to have issues with compound assignments though.
--
Eduardo Bustamante
https://dualbus.me/
Re: Builtin read with -n0 or -N0 (nchars == 0) behaves as a read with no -n/-N argument
On Sun, Jun 04, 2017 at 01:45:42AM +0530, Pranav Deshpande wrote: [...] > My solution is to change *line 294* of builtins/read.def. > > Change > if (code == 0 || *intval < 0* || intval != (int)intval) > > to > > if (code == 0 || i*ntval <= 0* || intval != (int)intval) [...] > Is this solution ok? Yes. That works. Chet went with the other option though: dualbus@debian:~/src/gnu/bash-build$ ./bash -c 'read -n0; echo $?; declare -p REPLY' 0 declare -- REPLY="" You can see the change by navigating the `devel' branch of the git repository in Savannah (commit 1110e30870a8782425067a060d89cc411b014418): http://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel=1110e30870a8782425067a060d89cc411b014418 Although there's a problem with the solution: dualbus@debian:~$ for sh in bash ~/src/gnu/bash-build/bash ksh93 mksh; do $sh -c ': | read -n 0; echo $?'; done 1 0 1 1 Since the read(2) system call doesn't take place, `read -n 0' doesn't detect the broken pipe. IMO, it should. -- Eduardo Bustamante https://dualbus.me/
Re: RFE: Please allow unicode ID chars in identifiers
On Thu, Jun 01, 2017 at 10:16:30PM -0700, L A Walsh wrote: > > Should UTF-8 be assumed? > You realize bash already allows UTF-8 input? Of course. Both Bash and Readline are able to process multibyte character input. That's not the same as parsing multibyte sequences in *code*. See Python's Enhancement Proposal on the matter to get a glimpse of some of the challenges of implementing Unicode identifiers: https://www.python.org/dev/peps/pep-3131/ [...] > I don't suppose we wanted something more expressive or symbolic? > > Couldn't we have gotten by with the original Bourne shell? Why develop > bash? What was the actual need? Because the Bourne shell was not free software. And this has nothing to do at all with your RFE. > How do you emphasize a var, say in italic or bold? I don't. It's source code. I don't write source code in Spanish, nor do I don't underline, emphasize, strike, bold, italic, ... > Anyway, bash already has some unicode parsing in it because > it accepts UTF-8. So it wouldn't have to be the complete > rewrite you make it. Then it shouldn't be hard for you to craft a small patch and send it to the list so that we can review it. Don't put words on my mouth. I said that it will increase the complexity of the parser, and will most likely introduce a whole new class of parsing bugs. If you want to give it a try, be my guest. But don't ask for stuff without considering the cost of what you're requesting, or if you're not willing to make part of the contribution yourself. Anyways. Unless I see an actual patch, this will be my last response to this thread. -- Eduardo Bustamante https://dualbus.me/
Remaining memory corruption bugs in readline
I'm using the latest `devel' commit as a reference: dualbus@debian:~/src/gnu/bash$ git show -q HEAD commit 1110e30870a8782425067a060d89cc411b014418 Author: Chet Ramey <chet.ra...@case.edu> Date: Wed May 31 15:53:02 2017 -0400 commit bash-snap-20170531 snapshot Since there are still many memory corruption issues, and I'm not smart enough to even try and see what's going on here, I'm just enumerate the different cases I've seen so far (unique stack traces). All of these were obtained by running: ./bash -c 'read -e' < $input With isatty check disabled in the `read' builtin. #1 _rl_get_char_len / update_line dualbus@debian:~/asan/3f3e$ tail -n +1 crash.5781 input.5781 ==> crash.5781 <== = ==5781==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6190cc80 at pc 0x7f400d00b063 bp 0x7ffcbce72250 sp 0x7ffcbce71a00 READ of size 851 at 0x6190cc80 thread T0 #0 0x7f400d00b062 (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062) #1 0x559b50a04821 in _rl_get_char_len ../../../bash/lib/readline/mbutil.c:223 #2 0x559b50a048e0 in _rl_compare_chars ../../../bash/lib/readline/mbutil.c:252 #3 0x559b509db526 in update_line ../../../bash/lib/readline/display.c:1664 #4 0x559b509d935b in rl_redisplay ../../../bash/lib/readline/display.c:1150 #5 0x559b509a20be in _rl_internal_char_cleanup ../../../bash/lib/readline/readline.c:514 #6 0x559b509a2494 in readline_internal_char ../../../bash/lib/readline/readline.c:638 #7 0x559b509a24b1 in readline_internal_charloop ../../../bash/lib/readline/readline.c:656 #8 0x559b509a24d5 in readline_internal ../../../bash/lib/readline/readline.c:670 #9 0x559b509a1b8b in readline ../../../bash/lib/readline/readline.c:374 #10 0x559b5095cf60 in edit_line ../../bash/builtins/../../bash/builtins/read.def:1090 #11 0x559b5095a8d1 in read_builtin ../../bash/builtins/../../bash/builtins/read.def:554 #12 0x559b50870c19 in execute_builtin ../bash/execute_cmd.c:4609 #13 0x559b5087282f in execute_builtin_or_function ../bash/execute_cmd.c:5107 #14 0x559b508700af in execute_simple_command ../bash/execute_cmd.c:4395 #15 0x559b5085ded2 in execute_command_internal ../bash/execute_cmd.c:811 #16 0x559b508667be in execute_connection ../bash/execute_cmd.c:2639 #17 0x559b5085eca7 in execute_command_internal ../bash/execute_cmd.c:980 #18 0x559b50947f55 in parse_and_execute ../../bash/builtins/evalstring.c:430 #19 0x559b50829391 in run_one_command ../bash/shell.c:1405 #20 0x559b5082786a in main ../bash/shell.c:718 #21 0x7f400c8232b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0) #22 0x559b508266d9 in _start (/home/dualbus/src/gnu/bash-build/bash+0x7f6d9) 0x6190cc80 is located 0 bytes to the right of 1024-byte region [0x6190c880,0x6190cc80) allocated by thread T0 here: #0 0x7f400d090d28 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1d28) #1 0x559b50936bf6 in xmalloc ../bash/xmalloc.c:112 #2 0x559b509d40f9 in init_line_structures ../../../bash/lib/readline/display.c:608 #3 0x559b509d492c in rl_redisplay ../../../bash/lib/readline/display.c:677 #4 0x559b509a1d88 in readline_internal_setup ../../../bash/lib/readline/readline.c:444 #5 0x559b509a24d0 in readline_internal ../../../bash/lib/readline/readline.c:669 #6 0x559b509a1b8b in readline ../../../bash/lib/readline/readline.c:374 #7 0x559b5095cf60 in edit_line ../../bash/builtins/../../bash/builtins/read.def:1090 #8 0x559b5095a8d1 in read_builtin ../../bash/builtins/../../bash/builtins/read.def:554 #9 0x559b50870c19 in execute_builtin ../bash/execute_cmd.c:4609 #10 0x559b5087282f in execute_builtin_or_function ../bash/execute_cmd.c:5107 #11 0x559b508700af in execute_simple_command ../bash/execute_cmd.c:4395 #12 0x559b5085ded2 in execute_command_internal ../bash/execute_cmd.c:811 #13 0x559b508667be in execute_connection ../bash/execute_cmd.c:2639 #14 0x559b5085eca7 in execute_command_internal ../bash/execute_cmd.c:980 #15 0x559b50947f55 in parse_and_execute ../../bash/builtins/evalstring.c:430 #16 0x559b50829391 in run_one_command ../bash/shell.c:1405 #17 0x559b5082786a in main ../bash/shell.c:718 #18 0x7f400c8232b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0) SUMMARY: AddressSanitizer: heap-buffer-overflow (/usr/lib/x86_64-linux-gnu/libasan.so.3+0x3c062) Shadow bytes around the buggy address: 0x0c327fff9940: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c327fff9950: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c327fff9960: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c327fff9970: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0x0c327fff9980: 00 00 00 00 00 00 00 00 00 00 00
Re: RFE: Please allow unicode ID chars in identifiers
On Thu, Jun 01, 2017 at 09:31:24PM -0700, L A Walsh wrote: [...] > Absolutely needs? Do people absolutely need computers? They are supposed > to > be there to serve us and make our life easier. So you shouldn't be asking > a lame question that eliminates the machines and media we are using to > communicate. And don't try to use absolutes like "cannot be achieved by > " since that's what you are saying. Why do we need > ASCII or keyboards? Why not go back to ones and zeros entered via flip > switches > on a panel? Any point in time is "arbitrary" and gone by the time you think > of > it. Limiting everything to how it is now == not-living. I asked a simple question. No need to get rhetorical. No need to label it as "lame" either, it's not. Please provide *actual* real world use cases for Unicode identifiers. Please remember that there's always a *cost* associated with new features: - Someone has to do the work of extending the current lexer / parser to be able to ingest multibyte character sequences. It helps a bunch if you do that work, and submit it for review. - People then have to test the new implementation, to ensure that there are no regressions, and no new bugs introduced. I'm happy to volunteer once there's a working implementation. - There are some questions that must be answered first: * How do you how to decode multibyte character sequences into Unicode? Should UTF-8 be assumed? * Will the parsing of a script depend upon the user locale? * Should this special parsing code be disabled if POSIX mode is enabled? * Right now `name' or `identifier' is defined as: name: A word consisting only of alphanumeric characters and underscores, and beginning with an alphabetic character or an underscore. Also referred to as an identifier. How will the definition look like with Unicode identifiers? > Variable names like: > > Lēv -- (3 letter word pronounced like Leave), (most recent try...) Use `Lev'. > string constants: > $Φ="0.618033988749894848" > $ɸ="1.61803398874989485" > $π="3.14159265358979324" > $␉=$'\x09' > $Ⅼ=50 $Ⅽ=100 $Ⅾ=500 $Ⅿ=1000 > $Ⅰ=1$Ⅴ=5 $Ⅹ=10 > $㎏="kilogram" > $㎆=1024*$㎅, > etc... I'm going to assume the leading `$' in the variable assignment is a typo. What prevents you from using? phi='...' pi='...' ht='...' kg='...' I'm still not convinced there's an actual need here. -- Eduardo Bustamante https://dualbus.me/
Re: read -e allows execution of commands (edit-and-execute-command) as the shell's process user
On Mon, May 29, 2017 at 11:40:54PM -0400, George wrote: [...] > You misunderstand. Being able to use Readline in "read" is great! And > "edit-and-execute-command" may have its uses when invoked from an > interactive > shell session. But why is "edit-and-execute-command" useful or in any > way desirable in "read"? > If you were using "read -e" in a script, and someone wanted to run > some commands, they could suspend the script with job control, or open > another > terminal window to run some commands. The feature is unnecessary, and > has no business being a part of "read". If that's how you feel, then by all means send a patch with your proposed changes (i.e. disable "unsafe" Readline functions under `read'). I'm OK with the current workaround: INPUTRC= VISUAL=: read -e ... -- Eduardo Bustamante https://dualbus.me/
Re: PWD not made canonical on shell start
On Mon, May 29, 2017 at 06:25:06PM -0400, Chet Ramey wrote:
[...]
> If PWD appears in the environment, and it is an absolute pathname of the
> CWD, set PWD to the canonicalized version of the environment value. The
> canonicalized version removes . and .., makes sure that the length is
> less than PATH_MAX, and validates that at each step, removing . and ..
> results in a valid pathname. If canonicalization fails, PWD gets the value
> that would be printed by pwd -P if PWD were not set.
That's not quite true. In variables.c `set_pwd', there's the following:
843 temp_var = find_variable ("PWD");
844 /* Follow posix rules for importing PWD */
845 if (temp_var && imported_p (temp_var) &&
846 (temp_string = value_cell (temp_var)) &&
847 temp_string[0] == '/' &&
848 same_file (temp_string, ".", (struct stat *)NULL, (struct stat
*)NULL))
849 {
850 current_dir = sh_canonpath (temp_string,
PATH_CHECKDOTDOT|PATH_CHECKEXISTS);
851 if (current_dir == 0)
852 current_dir = get_working_directory ("shell_init");
853 else
854 set_working_directory (current_dir);
855 free (current_dir);
856 }
`current_dir' is a copy of `temp_string' which holds the canonicalized version
of the environment value. That's true. *But* PWD is not re-set to the value of
`current_dir'. Instead, it has the same value as passed through the
environment (i.e. `temp_string').
For completeness, in builtins/common.c `set_working_directory' just updates a
global variable, but doesn't touch the value of the PWD variable.
589 /* Make NAME our internal idea of the current working directory. */
590 void
591 set_working_directory (name)
592 char *name;
593 {
594 FREE (the_current_working_directory);
595 the_current_working_directory = savestring (name);
596 }
Hence, my initial patch:
diff --git a/variables.c b/variables.c
index 944de86e..62f9f229 100644
--- a/variables.c
+++ b/variables.c
@@ -852,6 +852,8 @@ set_pwd ()
current_dir = get_working_directory ("shell_init");
else
set_working_directory (current_dir);
+ temp_var = bind_variable ("PWD", current_dir);
+ set_auto_export (temp_var);
free (current_dir);
}
else if (home_string && interactive_shell && login_shell &&
Re: Builtin history -r does not work with named pipes (i.e. GNU readline's histfile.c read_history_range)
On Mon, May 29, 2017 at 04:17:16PM -0400, Chet Ramey wrote: [...] > So the bug is that readline doesn't print an error message if the history > file isn't a regular file? Correct. Another problem is that the history builtin doesn't propagate back a meaningful return code indicating that there was a problem. A simple example is that you're trying to seed your history by appending the output of a command using `history -r'. So you might try: | $ history -cr <(echo a complex command); echo $?; history | 0 But for some reason that doesn't work and there is no apparent problem with it. Whereas the following does work: | $ history -cr /dev/stdin <<<'a complex command'; echo $?; history | 0 | 1 a complex command Or, which indicates that something went wrong: | $ history -cr /tmp; echo $?; history | 1 In my opinion it should at least return an error code. And if possible an error message. The other option is to implement support for reading from non-regular files, but I'm not sure if it's worth it. -- Eduardo Bustamante https://dualbus.me/
Re: read -e allows execution of commands (edit-and-execute-command) as the shell's process user
On Mon, May 29, 2017 at 12:29:16AM -0400, George Caswell wrote: [...] > Bash's builtin function "read" has one simple job: read data, return > it to the caller. There shouldn't be anything in there about executing > commands. > > Why does read even need a function like this? Is it something that was > useful in the days before job control? ##SELECTION_END## The -e flag causes read to use GNU Readline if the input comes from a terminal. This is *very* useful, since Readline allows you to perform text manipulation functions, completion, advanced cursor movement, etc. Also, the likelyhood of this being a real security issue is very small. -- Eduardo Bustamante https://dualbus.me/
