Re: Crash on jobs 2^32-2

[isabella parakiss]

but... 4278190079 != 2^32-2...
anything above 2^31 will do

On 7/12/18, Chet Ramey  wrote:
> On 7/11/18 9:41 AM, Simon Wörner wrote:
>> Dear all,
>> The following crash was found by a modified
>> version of the kAFL fuzzer (https://github.com/RUB-SysSec/kAFL).
>>
>> The crash can be reproduced by running:
>> $ ls
>> $ jobs 4278190079 # 2^32-2
>
> Thanks, this is another integer overflow issue.
>
>
> --
> ``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: [annoyance/non-feature] On OS X, every process is "occupying" CWD, making disk ejects impossible after cd'ing into them.

[isabella parakiss]

hack the kernel and fix the bug in osx where it's supposed to be fixed

On 1/16/18, Danyel Bayraktar  wrote:
> I asked on StackExchange prior to this:
> https://apple.stackexchange.com/questions/310965/stop-iterm2-from-using-disk-disk-cannot-be-ejected
> 
>
> Initially I thought it was specific to the terminal emulator, but it is
> actually due to the design of OS X. My problem is that when cd’ing into the
> external drive to run an `ls`, I’m not really “using” it and should be able
> to eject it. The eject should only be impossible for the time span a process
> is actually running.
>
> So my proposal would be to get rid of this annoyance:
>
> Bash should idle in (e.g.) /tmp or /var/folders/xyz, i.e. occupy that file
> as ‘CWD’ towards the OS, but obviously not expose this to depending code, so
> still spawn every child process/builtin/keyword inside the (memory-stored)
> cwd which will be updated with `cd` and used throughout.
>
> The drawbacks of this are apparent: `lsof` would show a random irrelevant
> folder as `cwd` for bash and as such, would be backward incompatible. This
> could be mitigated by 1) only enabling this in OS X (I do remember disks can
> be ejected even if bash is occupying them), or (ill-performing), 2) only for
> external drives. Ill-performing because this will require checks after
> almost every CWD modification.
>
> 3) Honestly, the most obvious and backward-compatible solution would be to
> put this behind a shopt option, e.g. ‘shopt -s cwdspoof’. I don’t see any
> reason why this wouldn’t be feasible…
>
> This is my first e-mail here — I would love to help implement this if you
> give me some pointers and a contribution guide.
>
> Best regards,
> Danyel.

this makes sense

[isabella parakiss]

IFS=_ foo_bar=well; set foo bar; echo "i'm a ${!@} designed language"

Re: ``read -N n -t timeout'' saves partial input only when EOF is seen?

[isabella parakiss]

On 11/24/16, Chet Ramey  wrote:
> On 11/24/16 2:57 AM, Clark Wang wrote:
>> See following example:
>>
>> # echo $BASH_VERSION
>> 4.4.5(2)-release
>> # ( printf 12345 ) | ( read -t 1 -N 10 v; echo "<$v>" )
>> <12345>
>> # ( printf 12345; sleep 2 ) | ( read -t 1 -N 10 v; echo "<$v>" )
>> <>
>> #
>>
>> The second "read" did not save "12345" to "v". Is this a bug?
>
> No, it's a race condition.  It depends on when the kernel schedules
> each process in the pipeline: if the read gets scheduled and times out
> before the subshell that runs the printf/sleep combination runs and
> writes something to the pipe, you won't get any output.  On Mac OS X,
> for example, you get <12345>.
>
> Chet
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>``Ars longa, vita brevis'' - Hippocrates
> Chet Ramey, UTech, CWRUc...@case.edu
> http://cnswww.cns.cwru.edu/~chet/
>
>

that's not true https://gist.github.com/fa4efd90376ff2714901e4429fdee734
read successfully reads the data, but then it's discarded by bash
i don't know how/why it works on your mac, but it sure looks like a bug

---
xoxo iza

add ifdef for readline in shopt.def

[isabella parakiss]

enable_hostname_completion is not declared without readline

---
xoxo iza
From 38e94c427a1b87680b54c3820777ed55c662f90e Mon Sep 17 00:00:00 2001
From: izabera 
Date: Sat, 19 Nov 2016 20:15:47 +0100
Subject: [PATCH] add ifdef for readline in shopt.def

---
 builtins/shopt.def | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/builtins/shopt.def b/builtins/shopt.def
index 2febb7e..240ad41 100644
--- a/builtins/shopt.def
+++ b/builtins/shopt.def
@@ -121,7 +121,6 @@ extern int debugging_mode;
 static void shopt_error __P((char *));
 
 static int set_shellopts_after_change __P((char *, int));
-static int shopt_enable_hostname_completion __P((char *, int));
 static int set_compatibility_level __P((char *, int));
 
 #if defined (RESTRICTED_SHELL)
@@ -130,6 +129,7 @@ static int set_restricted_shell __P((char *, int));
 
 #if defined (READLINE)
 static int shopt_set_complete_direxpand __P((char *, int));
+static int shopt_enable_hostname_completion __P((char *, int));
 #endif
 
 static int shopt_set_debug_mode __P((char *, int));
@@ -576,6 +576,7 @@ shopt_set_debug_mode (option_name, mode)
   return (0);
 }
 
+#if defined (READLINE)
 static int
 shopt_enable_hostname_completion (option_name, mode)
  char *option_name;
@@ -583,6 +584,7 @@ shopt_enable_hostname_completion (option_name, mode)
 {
   return (enable_hostname_completion (mode));
 }
+#endif
 
 static int
 set_compatibility_level (option_name, mode)
-- 
2.10.2

TIMEFORMAT in time ( )

[isabella parakiss]

$ cat myscript
TIMEFORMAT=foo var=x

time ( TIMEFORMAT=bar var=y )
echo "<$TIMEFORMAT> <$var>"

f() { TIMEFORMAT=f; time :; }
time ( f )
echo "<$TIMEFORMAT>"


$ bash myscript
bar
 
f
f




setting TIMEFORMAT in ( ) affects time out of the subshell
this cannot be right

---
xoxo iza

wait and procsubs

[isabella parakiss]

wait doesn't wait for procsubs unless it's passed the pid as an argument

$ time { : <(sleep 1); wait; }
real: 0m0.002s, user: 0m0.000s, sys: 0m0.003s
$ time { : <(sleep 1); wait $!; }
real: 0m1.011s, user: 0m0.003s, sys: 0m0.007s

is this intended or is it a bug?

this also means it's impossible to wait for both y and z in x <(y) <(z)

---
xoxo iza

Re: Magnitude of Order "For Loop" performance deltas based on syntax change

[isabella parakiss]

On 9/26/16, Dan Douglas  wrote:
> Would an array of pointers to structs of key-value pairs be better
> here? It should be faster in the common cases even though it may mean
> some wasted space and reallocs depending on how you decide to grow the
> array. A linear search through an array for an index should be faster
> than linked-list traversal. https://youtu.be/YQs6IC-vgmo (why every
> std::vector implementation uses arrays, really it's true of analogues
> in most non-functional langs).
>
> Also bash itself makes it hard to use sparse arrays efficiently regardless
> of the implementation. In the case of lists, one usually wants to address
> elements by ordinal position, but both the index in `arr[index]` and the
> offset in `${arr[@]:offset:length}` don't allow it, which means random
> insertion requires a linear search despite being linked-lists. That also
> makes the "length" inconsistent with everything else that looks at the
> value of the index, though at least length does what I really wish
> offset did.
>

friendly reminder that trees exist


---
xoxo iza

Re: [BUG] false positive: [ ! -o optname ]

[isabella parakiss]

On 9/25/16, Martijn Dekker  wrote:
> The '!' operator in the legacy test/[ builtin does not invert the result
> of the -o operator. Consequently the command
>
>   [ ! -o noclobber ]
>
> amounts to a no-op, always returning exit status 0.
>
> Proof:
>
> $ set -o noclobber && [ -o noclobber ] && [ ! -o noclobber ] && echo bug
> bug
>
> Interestingly, mksh has this bug as well, though not the original pdksh.
>
> Thanks,
>
> - M.
>
>

[ ! -o noclobber ] means
is '!' a non empty string?  if not, is 'noclobber' a non empty string?


---
xoxo iza

[PATCH] fix printf %b without an argument

[isabella parakiss]

here's a patch that fixes this problem

$ printf "<%3s><%3b>"
<   ><>


---
xoxo iza
From c5ffd55ffa9224dd7919a4d09b27a11308d2152e Mon Sep 17 00:00:00 2001
From: izabera 
Date: Sat, 24 Sep 2016 02:01:16 +0200
Subject: [PATCH] fix printf %b without an argument

old behavior:
$ printf "<%3s><%3b>"
<   ><>

removed bogus check on xp returned by bexpand
printstr must not return immediately if the string is null
---
 builtins/printf.def | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/builtins/printf.def b/builtins/printf.def
index d39a6d3..1037b5c 100644
--- a/builtins/printf.def
+++ b/builtins/printf.def
@@ -543,22 +543,19 @@ printf_builtin (list)
 		ch = rlen = r = 0;
 		xp = bexpand (p, strlen (p), , );
 
-		if (xp)
+		/* Have to use printstr because of possible NUL bytes
+		   in XP -- printf does not handle that well. */
+		r = printstr (start, xp, rlen, fieldwidth, precision);
+		if (r < 0)
 		  {
-		/* Have to use printstr because of possible NUL bytes
-		   in XP -- printf does not handle that well. */
-		r = printstr (start, xp, rlen, fieldwidth, precision);
-		if (r < 0)
+		if (ferror (stdout) == 0)
 		  {
-			if (ferror (stdout) == 0)
-			  {
-		sh_wrerror ();
-			clearerr (stdout);
-			  }
-		retval = EXECUTION_FAILURE;
+			sh_wrerror ();
+			clearerr (stdout);
 		  }
-		free (xp);
+		retval = EXECUTION_FAILURE;
 		  }
+		free (xp);
 
 		if (ch || r < 0)
 		  PRETURN (retval);
@@ -711,8 +708,7 @@ printstr (fmt, string, len, fieldwidth, precision)
   int fw, pr;			/* fieldwidth and precision */
   intmax_t mfw, mpr;
 
-  if (string == 0 || len == 0)
-return 0;
+  if (string == 0) string = "";
 
 #if 0
   s = fmt;
-- 
2.10.0

[no subject]

[isabella parakiss]

From 6732f0277455ff8d8c6a09261490377890dc986d Mon Sep 17 00:00:00 2001
From: izabera 
Date: Wed, 22 Jun 2016 22:43:53 +0200
Subject: [PATCH] fix a couple of bugs in print_cmd.c

1. print all heredoc headers before printing their contents
2. don't print all the heredocs after any other redir

sample code:
f(){ : <&- &- < file2 <&- < file2
foo
x
bar
y

}
---
 print_cmd.c | 43 ++-
 1 file changed, 26 insertions(+), 17 deletions(-)

diff --git a/print_cmd.c b/print_cmd.c
index 617501e..0ba972c 100644
--- a/print_cmd.c
+++ b/print_cmd.c
@@ -1024,21 +1024,7 @@ print_redirection_list (redirects)
   was_heredoc = 0;
   while (redirects)
 {
-  /* Defer printing the here documents until we've printed the
-rest of the redirections. */
-  if (redirects->instruction == r_reading_until || redirects->instruction 
== r_deblank_reading_until)
-   {
- newredir = copy_redirect (redirects);
- newredir->next = (REDIRECT *)NULL;
- if (heredocs)
-   {
- hdtail->next = newredir;
- hdtail = newredir;
-   }
- else
-   hdtail = heredocs = newredir;
-   }
-  else if (redirects->instruction == r_duplicating_output_word && 
(redirects->flags & REDIR_VARASSIGN) == 0 && redirects->redirector.dest == 1)
+  if (redirects->instruction == r_duplicating_output_word && 
(redirects->flags & REDIR_VARASSIGN) == 0 && redirects->redirector.dest == 1)
{
  /* Temporarily translate it as the execution code does. */
  rw = redirects->redirectee.filename->word;
@@ -1048,7 +1034,25 @@ print_redirection_list (redirects)
  redirects->instruction = r_duplicating_output_word;
}
   else
-   print_redirection (redirects);
+   {
+   /* Defer printing the here documents' bodies until we've printed the
+  rest of the redirections. */
+ if (redirects->instruction == r_reading_until || 
redirects->instruction == r_deblank_reading_until)
+   {
+ newredir = copy_redirect (redirects);
+ print_heredoc_header (newredir);
+ newredir->next = (REDIRECT *)NULL;
+ if (heredocs)
+   {
+ hdtail->next = newredir;
+ hdtail = newredir;
+   }
+ else
+   hdtail = heredocs = newredir;
+   }
+ else
+   print_redirection (redirects);
+   }
 
   redirects = redirects->next;
   if (redirects)
@@ -1061,7 +1065,12 @@ print_redirection_list (redirects)
 deferred_heredocs = heredocs;
   else if (heredocs)
 {
-  print_heredocs (heredocs);
+  cprintf("\n");
+  for (; heredocs; heredocs = heredocs->next)
+   {
+ print_heredoc_body (heredocs);
+ cprintf ("\n");
+   }
   dispose_redirects (heredocs);
 }
 }
-- 
2.9.0


---
xoxo iza

extglob problems

[Isabella Parakiss]

Just wanted to report a couple of problems in 4.3.42 and the latest
devel version:

*?(/) followed by something makes it ignore the rest:
$ [[ a = a*?(/)b ]] && echo match
match

@(*|extglob) matches everything(?) but not always:
$ touch a b c .x .y .z
$ echo .!(|.) # correct
.x .y .z
$ echo *  # correct
a b c
$ echo @(*|.!(|.))# wrong, adds . and ..
. .. a b c .x .y .z
$ echo @(*|@(f))  # ??
. .. a b c .x .y .z
$ echo @(*|@(ff)) # ???
a b c

I wouldn't know where to start to fix them though...
-- 
xoxo iza

Re: why does time (cmd) 2> file redirect time's output?

[Isabella Parakiss]

On Fri, Jan 29, 2016 at 12:08:38PM -0500, Chet Ramey wrote:
> On 1/27/16 5:59 AM, Stephane Chazelas wrote:
> > Hello,
> > 
> > (tested with bash-4.3 and bash-2.05b)
> > 
> > "time" is meant to time a pipeline. That generally includes
> > redirections of the last command in the pipeline, but in the
> > case of a subshell alone, the redirection is not timed(*) and
> > seems to affect the output of "time" itself.
> 
> It's the way the bash implementation was from the start.  If the command
> to be timed is run in a subshell and not part of a pipeline, the shell
> forks early and runs the command in a subshell.  In this case, that
> subshell performs redirections before doing much of anything else.
> 
> As you note below, some people have relied on it.
> 
> 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/
> 

This seems to be a related problem:
$ time (exec true)  # doesn't print anything
$ time ( (exec true) )  # doesn't print anything
$ time ( ( (exec true) ) )  # doesn't print anything
$ time { (exec true); }
real: 0m0.001s, user: 0m0.000s, sys: 0m0.000s

---
xoxo iza

Re: GLOBIGNORE documentation

[Isabella Parakiss]

On Sun, Mar 06, 2016 at 10:16:58PM +, Stephane Chazelas wrote:
> Today, I realised that GLOBIGNORE doesn't work at all like ksh's
> FIGNORE.
> 
> With
> 
> GLOBIGNORE=x*
> 
> we're not filtering out files whose *name* starts with "x" from
> globs but those whose *path* starts with "x".
> 
> In
> 
> echo *
> 
> files whose name starts with "x" will be excluded, but not in
> 
> echo ./*
> 

OTOH this is arguably more useful than its ksh equivalent:
GLOBIGNORE=-*; some-cmd *; some-cmd ./*


---
xoxo iza

add ifdefs for BASH_HISTORY

[isabella parakiss]

This is needed to configure with --disable-bash-history

--
xoxo iza



diff --git a/bashhist.c b/bashhist.c
index dc26d30..6a16bdf 100644
--- a/bashhist.c
+++ b/bashhist.c
@@ -229,6 +229,7 @@ bash_history_inhibit_expansion (string, i)
 return (1);
 #endif
 
+#if defined (BANG_HISTORY)
   /* Make sure the history expansion should not be skipped by quoting or
  command/process substitution. */
   else if ((t = skip_to_histexp (string, 0, hx, SD_NOJMP|SD_HISTEXP)) > 0)
@@ -243,6 +244,7 @@ bash_history_inhibit_expansion (string, i)
}
   return (t > i);
 }
+#endif
   else
 return (0);
 }

---
xoxo iza

Re: feature request: store lines before history expansion

[isabella parakiss]

On 12/10/15, Hans Ginzel  wrote:
> Hello!
>
> I would appreciate if bash could optionally
> (some option – on by default when histexpand is set)
> store the command line *before* history expansion
> additionally to expanded line.
>
> Regards,
> Hans
>
Just curious, why?

---
xoxo iza

\177 at the end of a variable

[isabella parakiss]

$ str=abcd; [[ $'a\177' = a"${str:4:1}" ]]; echo $?
0


This happens in every version since 3.1, including the devel branch.

---
xoxo iza

Re: Proposed Prompt Escapes

[isabella parakiss]

On 11/19/15, Ángel González  wrote:
> Dennis Williamson wrote:
>> Do you mean something like:
>>
>> PS1='$SECONDS '
>
> Not exactly. $SECONDS is the number of seconds since the shell was
> started. I am interested in the seconds elapsed by the last command.
>
> It is a hacky solution, but it could be done with:
>> PS1=''; PROMPT_COMMAND='printf "%s " $SECONDS; SECONDS=0'
>
>

You need to reset it right before the command is executed, PROMPT_COMMAND
is evaluated when the prompt is drawn, before you type your command.
A debug trap is better suited, but you have to make sure that it's only
executed once in a complex line.

Something along these lines should work:

PROMPT_COMMAND=debug_trap=0
trap '((!debug_trap++))&=0' debug
PS1='$SECONDS \$ '


---
xoxo iza

Re: bash-4.3: casemod word expansions broken with UTF-8

[isabella parakiss]

On 11/15/15, Ulrich Mueller  wrote:
> Description:
>   In an UTF-8 locale like en_US.UTF-8, the case-modifying
>   parameter expansions sometimes return invalid UTF-8 encodings.
>
>   This seems to happen when the UTF-8 byte sequences that are
>   encoding upper and lower case have different lengths.
>
> Repeat-By:
>   $ LC_ALL=en_US.UTF-8
>   $ x=$'\xc4\xb1' # LATIN SMALL LETTER DOTLESS I
>   $ echo -n "${x^}" | od -t x1
>   000 49 b1
>   002
>
>   This should have output "49" for "I" only. The "b1" is illegal
>   as the first byte of an UTF-8 sequence.
>
>   $ x=$'\xe1\xba\x9e' # LATIN CAPITAL LETTER SHARP S
>   $ echo -n "${x,}" | od -t x1
>   000 c3 9f 9e
>   003
>
>   This should have output "c3 9f" (for "sharp s") only.
>

Both examples should work as expected in 4.4-beta.


---
xoxo iza

unsetting from BASH_ALIASES

[isabella parakiss]

man bash claims that unsetting elements from BASH_ALIASES causes them to
be removed from the alias list.  This doesn't work and from what I can see
in variables.c there's nothing that's called when an element in a dynamic
variable is unset.

Is there any plan to support this?


---
xoxo iza

Re: problem with @A and arrays

[isabella parakiss]

On 10/18/15, Chet Ramey  wrote:
> (BTW, your patch does not result in a valid declare command with a
> correct compound assignment.)
>
Yes I'm sorry, I noticed it after sending the message...

---
xoxo iza

problem with @A and arrays

[isabella parakiss]

${array[@]@A} splits the values.

$ a=("ab" "c   d"); printf "<%s>" "${a[@]@A}"

Re: language inconsistency(wart) & RFE

[isabella parakiss]

On 10/17/15, Linda Walsh  wrote:
> Ok, thinking this from a different way.
>
> shopt -s implicit_vars_local
> or
> shopt -s localize_func_implicit_vars whatever...
>
> Right now, in a function, you *can* use local in a function
> to make a local var.  Thing is, both 'declare' and 'typeset' also
> make a *local* var in a function, unless the "-g" switch is used.
>
> I.e. All standard, overt ways (local declare typeset) of creating
> a var in a function all result in it being local, BUT,
> (and I think this is an ugly wart),
> any *implicit vars* without local, or the
> misleading declare or typeset, become global.
>
> examples:  In these two for statements, used in functions, 'i'
> becomes global:
>
>   for((i=0; i<10; ++i)); do : done
>   for i in {1..10}; do : done
>
> And same with 'myarray':
>   readarray myarray=$(echo "one";echo "two")
>
> and reads and assignments, and 'lets'
>   read ln < <(echo "one"; echo "two")
>   ln2="one two"
>   read ln3 <<< "one two"
>
> but if this isn't a potential for confusion:
>
>> function aa {
> read ln < <(echo "one"; echo "two")
> ln2="12"
> read ln3 <<< "one two"
> ar1=(one two)
> typeset -i ln2=34
> typeset -a ar1=(three four)
> }
>> whence aa
> aa is a function
> aa ()
> {
> read ln < <(echo "one"; echo "two");
> ln2="12";
> read ln3 <<< "one two";
> ar1=(one two);
> typeset -i ln2=34;
> typeset -a ar1=(three four)
> }
>> aa
>> declare -p ln ln2 ln3 ar1
> declare -- ln="one"
> declare -- ln2="12"
> declare -- ln3="one two"
> declare -a ar1='([0]="one" [1]="two")'
>
> !!!  -- sure looks like I was trying to set the "type" of ln2
> and ar1... boy could that be confusing...
>
> 
> So, how about a "shopt"
> to declare that **what's implicity declared in funcs, stays in funcs**
> maybe shopt -s vegasvars ?.
>
> but seriously -- it's so odd that anything you declare explicitly
> becomes local, while implicit vars default to global --
> I know standards and compat must keep it that way... BUT
> it would have made more sense to have
> implicit vars in a function always be 'local'
> and maybe have explicit declarators be global
> (which has effectively been done with -g)...but
> originally, I also thought it strange that 'declare/typeset'
> were equivalent to 'local' inside a function.
>
> This way, you wouldn't have to change any syntax
> parsing functions and there certain isn't ANYTHING
> that would look like perl, even though perl was
> originally designed to be like shell with many shell standard
> functions built-in.
>
> ???
>
>
>

Maybe you can just use this?alias declare='declare -g'


---
xoxo iza

warnings with compgen -C and -F

[isabella parakiss]

What's the point of these two warnings in builtins/complete.def ?

  if (Farg)
builtin_error (_("warning: -F option may not work as you expect"));
  if (Carg)
builtin_error (_("warning: -C option may not work as you expect"));

Can they be removed?  It's stupid to provide a function, and warn every
time someone uses it.

It's also impossible to suppress _that_ warning without suppressing any
error from the actual command.

---
xoxo iza

Re: ! in PS1 in posix mode

[isabella parakiss]

On 10/12/15, Greg Wooledge  wrote:
> On Mon, Oct 12, 2015 at 09:28:42AM -0700, Linda Walsh wrote:
>> Chet Ramey wrote:
>> >http://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_05_03
>> >
>> >"The shell shall replace each instance of the character '!' in PS1 with
>> >the history file number of the next command to be typed."
>>
>> I've never seen that -- even when my prompt has
>> ! in it...maybe it's cause I have histexpand 'off'?
>
> Same here.
>
> imadev:~$ PS1=' ! > '
>  ! >
>
> If that's a bug, please don't "fix" it.
>
Out of posix mode, the history number is \!

---
xoxo iza

Re: ! in PS1 in posix mode

[isabella parakiss]

On 10/11/15, isabella parakiss <izaber...@gmail.com> wrote:
> In posix mode, bash replaces ! in my PS1 with the history number.
>
> $ PS1=' ! '
>  ! set -o posix
>  513 exit
>
> It doesn't happen with any other prompt escape sequence, afaict.
> This looks... intentional?  WTF?
>

Ok I've now read this page: http://tiswww.case.edu/php/chet/bash/POSIX
This is awful.

I found out this by enabling set -o posix in my interactive shell.  bash
replied with an endless loop of syntax errors because there's this in my
PS1:  ${var[a != b]}
Then bash decided to eat up as much cpu and memory it could grab, and I
had to kill-9 it.

I understand that changing the standard in unfeasible but a syntax error
in PS1 shouldn't destroy the shell.


---
xoxo iza

Re: trap DEBUG and $_

[isabella parakiss]

On 10/11/15, Dan Stromberg  wrote:
> Is there a way of outputting a datestamp to shell stderr at the _beginning_
> of the execution of a command, that won't wipe out $_?
>
> I use $_ quite a bit for the last argument to the previous command,
> interactively.  And I'd like to datestamp all my commands. Datestamping
> after with $PS1 is easy, but datestamping before is a little harder.
>
> I've tried using:
>
>function preexec { if tty -s; then echo "$(tput smso)cmd started $(date
> +%Y\ %a\ %b\ %d\ %r)$(tput rmso)"; fi; }
>trap preexec DEBUG
>
> ...but as you might suspect, I'm finding that $_ is always "preexec" with
> this enabled.
>
> Any suggestions?
>
> Thanks!
>
trap '__=$_; preexec; : "$__"' DEBUG

---
xoxo iza

! in PS1 in posix mode

[isabella parakiss]

In posix mode, bash replaces ! in my PS1 with the history number.

$ PS1=' ! '
 ! set -o posix
 513 exit

It doesn't happen with any other prompt escape sequence, afaict.
This looks... intentional?  WTF?


---
xoxo iza

read and env variables

[isabella parakiss]

$ a= read a <<< x   # this creates a variable in the current shell
$ declare -p a
declare -- a="x"

$ b= mapfile b <<< x# this doesn't
$ declare -p b
bash: declare: b: not found


Other shells don't seem to agree on what should happen in this case, but
it'd be nice to have a more consistent behavior.

---
xoxo iza

check if DEBUG is defined in trap.c

[isabella parakiss]

diff --git a/trap.c b/trap.c
index bf911ac..0a47f19 100644
--- a/trap.c
+++ b/trap.c
@@ -320,7 +320,9 @@ run_pending_traps ()
 while (pending_traps[sig]--) instead of the if statement. */
   if (pending_traps[sig])
{
+#if defined (DEBUG)
 itrace("run_pending_traps: %d: %d", sig, pending_traps[sig]);
+#endif
  if (running_trap == sig+1)
/*continue*/;
 
@@ -404,7 +406,9 @@ itrace("run_pending_traps: %d: %d", sig, 
pending_traps[sig]);
  /* XXX - set pending_traps[sig] = 0 here? */
  pending_traps[sig] = 0;
  evalstring (savestring (trap_list[sig]), "trap", 
SEVAL_NONINT|SEVAL_NOHIST|SEVAL_RESETLINE);
+#if defined (DEBUG)
 itrace("run_pending_traps: evalstring returns");
+#endif
 #if defined (JOB_CONTROL)
  restore_pipeline (1);
 #endif

---
xoxo iza

Problem with @Q

[isabella parakiss]

In the devel branch, setting IFS=\' seems to break @Q:

$ arr=(a b c)
$ echo  ${arr[@]@Q}  | sed -n l
'a' 'b' 'c'$  - correct
$ echo ${arr[@]@Q} | sed -n l
'a' 'b' 'c'$  - correct

$ IFS=\'
$ echo  ${arr[@]@Q}  | sed -n l
 a   b   c$   - wrong(?)
$ echo ${arr[@]@Q} | sed -n l
bash: INFORM: dequote_string: string with bare CTLESC
bash: INFORM: dequote_string: string with bare CTLESC
bash: INFORM: dequote_string: string with bare CTLESC
\001 a  \001 b  \001 c$   - definitely wrong


---
xoxo iza

Re: coredump with wait -n

[isabella parakiss]

On 8/22/15, Chris F.A. Johnson ch...@cfajohnson.com wrote:
 On Sat, 22 Aug 2015, isabella parakiss wrote:

 Hi, after running wait -n there's something wrong, ^C doesn't work
 properly anymore: it displays ^C in the readline buffer, but the current
 line stays there until I press enter.  Running any command fixes it.


 It can also dump core if you try with multiple jobs.

 $ bash --norc
 bash-4.3$ sleep 1  sleep 2  wait -n
 [1] 8368
 [2] 8369
 [1]-  Donesleep 1
 bash-4.3$ ^C*** stack smashing detected ***: bash terminated

 I have no problem running that line, and ^C still works.


I can provide additional infos if you tell me what to do.
I tried to reproduce it in gdb without much success, but anyway others
confirmed that bash crashes...


---
xoxo iza

coredump with wait -n

[isabella parakiss]

Hi, after running wait -n there's something wrong, ^C doesn't work
properly anymore: it displays ^C in the readline buffer, but the current
line stays there until I press enter.  Running any command fixes it.


It can also dump core if you try with multiple jobs.

$ bash --norc
bash-4.3$ sleep 1  sleep 2  wait -n
[1] 8368
[2] 8369
[1]-  Donesleep 1
bash-4.3$ ^C*** stack smashing detected ***: bash terminated
=== Backtrace: =
/usr/lib/libc.so.6(+0x72055)[0x7f9902ce8055]
/usr/lib/libc.so.6(__fortify_fail+0x37)[0x7f9902d6f5c7]
/usr/lib/libc.so.6(__fortify_fail+0x0)[0x7f9902d6f590]
bash[0x47be0a]
[0xa94630]
=== Memory map: 
0040-004bd000 r-xp  08:02 305608
  /usr/bin/bash
006bc000-006bd000 r--p 000bc000 08:02 305608
  /usr/bin/bash
006bd000-006c1000 rw-p 000bd000 08:02 305608
  /usr/bin/bash
006c1000-006cb000 rw-p  00:00 0
00a3d000-00aa rw-p  00:00 0  [heap]
7f990284e000-7f9902864000 r-xp  08:02 265670
  /usr/lib/libgcc_s.so.1
7f9902864000-7f9902a63000 ---p 00016000 08:02 265670
  /usr/lib/libgcc_s.so.1
7f9902a63000-7f9902a64000 rw-p 00015000 08:02 265670
  /usr/lib/libgcc_s.so.1
7f9902a64000-7f9902a6f000 r-xp  08:02 264875
  /usr/lib/libnss_files-2.22.so
7f9902a6f000-7f9902c6e000 ---p b000 08:02 264875
  /usr/lib/libnss_files-2.22.so
7f9902c6e000-7f9902c6f000 r--p a000 08:02 264875
  /usr/lib/libnss_files-2.22.so
7f9902c6f000-7f9902c7 rw-p b000 08:02 264875
  /usr/lib/libnss_files-2.22.so
7f9902c7-7f9902c76000 rw-p  00:00 0
7f9902c76000-7f9902e11000 r-xp  08:02 264868
  /usr/lib/libc-2.22.so
7f9902e11000-7f990301 ---p 0019b000 08:02 264868
  /usr/lib/libc-2.22.so
7f990301-7f9903014000 r--p 0019a000 08:02 264868
  /usr/lib/libc-2.22.so
7f9903014000-7f9903016000 rw-p 0019e000 08:02 264868
  /usr/lib/libc-2.22.so
7f9903016000-7f990301a000 rw-p  00:00 0
7f990301a000-7f990301d000 r-xp  08:02 264838
  /usr/lib/libdl-2.22.so
7f990301d000-7f990321c000 ---p 3000 08:02 264838
  /usr/lib/libdl-2.22.so
7f990321c000-7f990321d000 r--p 2000 08:02 264838
  /usr/lib/libdl-2.22.so
7f990321d000-7f990321e000 rw-p 3000 08:02 264838
  /usr/lib/libdl-2.22.so
7f990321e000-7f990327d000 r-xp  08:02 265713
  /usr/lib/libncursesw.so.5.9
7f990327d000-7f990347d000 ---p 0005f000 08:02 265713
  /usr/lib/libncursesw.so.5.9
7f990347d000-7f9903481000 r--p 0005f000 08:02 265713
  /usr/lib/libncursesw.so.5.9
7f9903481000-7f9903483000 rw-p 00063000 08:02 265713
  /usr/lib/libncursesw.so.5.9
7f9903483000-7f99034c4000 r-xp  08:02 268292
  /usr/lib/libreadline.so.6.3
7f99034c4000-7f99036c4000 ---p 00041000 08:02 268292
  /usr/lib/libreadline.so.6.3
7f99036c4000-7f99036c6000 r--p 00041000 08:02 268292
  /usr/lib/libreadline.so.6.3
7f99036c6000-7f99036cd000 rw-p 00043000 08:02 268292
  /usr/lib/libreadline.so.6.3
7f99036cd000-7f99036ce000 rw-p  00:00 0
7f99036ce000-7f99036f r-xp  08:02 264835
  /usr/lib/ld-2.22.so
7f9903727000-7f99038b6000 r--p  08:02 315939
  /usr/lib/locale/locale-archive
7f99038b6000-7f99038bb000 rw-p  00:00 0
7f99038ed000-7f99038ef000 rw-p  00:00 0
7f99038ef000-7f99038f r--p 00021000 08:02 264835
  /usr/lib/ld-2.22.so
7f99038f-7f99038f1000 rw-p 00022000 08:02 264835
  /usr/lib/ld-2.22.so
7f99038f1000-7f99038f2000 rw-p  00:00 0
7ffd88e1f000-7ffd88e4 rw-p  00:00 0  [stack]
7ffd88f63000-7ffd88f65000 r--p  00:00 0  [vvar]
7ffd88f65000-7ffd88f67000 r-xp  00:00 0  [vdso]
ff60-ff601000 r-xp  00:00 0
  [vsyscall]
Aborted (core dumped)


I can reproduce in both 4.3 and 4.4-alpha, compiled on linux with gcc:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS:  -DPROGRAM='bash' -DCONF_HOSTTYPE='x86_64'
-DCONF_OSTYPE='linux-gnu' -DCONF_MACHTYPE='x86_64-unknown-linux-gnu'
-DCONF_VENDOR='unknown' -DLOCALEDIR='/usr/share/locale'
-DPACKAGE='bash' -DSHELL -DHAVE_CONFIG_H   -I.  -I. -I./include
-I./lib  -D_FORTIFY_SOURCE=2 -march=x86-64 -mtune=generic -O2 -pipe
-fstack-protector-strong --param=ssp-buffer-size=4
-DDEFAULT_PATH_VALUE='/usr/local/sbin:/usr/local/bin:/usr/bin'
-DSTANDARD_UTILS_PATH='/usr/bin' -DSYS_BASHRC='/etc/bash.bashrc'
-DSYS_BASH_LOGOUT='/etc/bash.bash_logout'
uname output: Linux notebook 4.1.5-1-ARCH #1 SMP PREEMPT Tue Aug 11
15:41:14 CEST 2015 x86_64 GNU/Linux
Machine Type: x86_64-unknown-linux-gnu


Other people in #bash can also reproduce it.


---
xoxo iza

Re: quoted compound array assignment deprecated

[isabella parakiss]

On 8/18/15, Chet Ramey chet.ra...@case.edu wrote:
 On 8/17/15 4:19 AM, isabella parakiss wrote:
 Quoting is necessary in a few cases:

 $ var=foo; declare -A arr$var=([x]=y)
 bash: warning: arrfoo=([x]=y): quoted compound array assignment
 deprecated
 $ var=foo; declare -A arr$var=([x]=y)
 bash: syntax error near unexpected token `('
 $ var=foo; declare -A arr$var=([x]=y)
 bash: syntax error near unexpected token `('

 I don't think this should be the default behaiour...

 This is exactly the case for which the warning is intended.  If you want
 to construct variable names on the fly, use `eval' or don't mix
 declarations of constructed variable names with compound assignment.

 You can read the extensive discussion starting at
 http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00028.html.

 http://lists.gnu.org/archive/html/bug-bash/2014-12/msg00115.html is the
 newest proposal.

 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/


Sorry for being both pedantic and late for that discussion but what's the
point of this warning?  From my understanding, the code is still valid, so
it doesn't stop a possible attacker and it only annoys regular users.

Using eval requires an extra level of escaping on everything else, I'd
rather use declare 2/dev/null to suppress the warning than eval...

Idea: display the warnings in -n mode, like ksh.
This way bash wouldn't produce unexpected results on existing scripts, it
wouldn't even require a new compatibility level and shopt.
What do you think about it?


---
xoxo iza

quoted compound array assignment deprecated

[isabella parakiss]

Quoting is necessary in a few cases:

$ var=foo; declare -A arr$var=([x]=y)
bash: warning: arrfoo=([x]=y): quoted compound array assignment deprecated
$ var=foo; declare -A arr$var=([x]=y)
bash: syntax error near unexpected token `('
$ var=foo; declare -A arr$var=([x]=y)
bash: syntax error near unexpected token `('

I don't think this should be the default behaiour...


---
xoxo iza

declare -f produces non eval'able output

[isabella parakiss]

declare -f doesn't know that most keywords are valid function names:

$ function time () { :; }
$ declare -f time
time () 
{ 
:
}

It should probably check if the name is if/for/time... before printing it.


---
xoxo iza

problems with traps

[isabella parakiss]

This segfaults when it receives a SIGUSR1:

#!/bin/bash
trap ': $(:)  (:)' USR1
while :; do sleep 1; done


I also received a bunch of scary errors like these:
*** Error in `/bin/bash': munmap_chunk(): invalid pointer:
0x02680f80 ***
*** Error in `/bin/bash': corrupted double-linked list: 0x01e54200 ***
*** Error in `/bin/bash': free(): invalid size: 0x0115ff80 ***
*** Error in `/bin/bash': double free or corruption (out):
0x00e7af60 ***
https://gist.github.com/anonymous/9b24b3ca0a6ce2203fc8
and bash used 100% of a cpu, but they appeared inconsistently while
trying to debug a script that trapped the SIGWINCH signal.
I'll post more details if needed (and if I can reproduce them).


From gdb it looks like the problems are in jobs.c
This is the backtrace for the segfault, but it doesn't explain the rest:

Program received signal SIGSEGV, Segmentation fault.
0x0044d2e5 in find_pipeline (pid=19266, alive_only=1,
jobp=0x7fffdff8) at jobs.c:1357
1357  if (p-pid == pid  ((alive_only == 0  PRECYCLED(p) == 0)
|| PALIVE(p)))
(gdb) bt
#0  0x0044d2e5 in find_pipeline (pid=19266, alive_only=1,
jobp=0x7fffdff8) at jobs.c:1357
#1  0x0044d419 in find_process (pid=19266, alive_only=1,
jobp=0x7fffdff8) at jobs.c:1396
#2  0x00450e0a in waitchld (wpid=-1, block=0) at jobs.c:3393
#3  0x00450b7c in sigchld_handler (sig=17) at jobs.c:3280
#4  signal handler called
#5  0x0048e0c8 in builtin_address_internal (name=0x7645d0 :,
disabled_okay=0) at common.c:829
#6  0x0048e251 in find_shell_builtin (name=0x7645d0 :) at common.c:866
#7  0x0043c6bf in execute_simple_command
(simple_command=0x763e50, pipe_in=-1, pipe_out=-1, async=0,
fds_to_close=0x738220) at execute_cmd.c:4200
#8  0x004367f1 in execute_command_internal (command=0x763da0,
asynchronous=0, pipe_in=-1,
pipe_out=-1, fds_to_close=0x738220) at execute_cmd.c:813
#9  0x00435dd3 in execute_command (command=0x763da0) at
execute_cmd.c:416
#10 0x0043ae49 in execute_while_or_until
(while_command=0x764130, type=0) at execute_cmd.c:3432
#11 0x0043adb4 in execute_while_command
(while_command=0x764130) at execute_cmd.c:3400
#12 0x00436a55 in execute_command_internal (command=0x764240,
asynchronous=0, pipe_in=-1,
pipe_out=-1, fds_to_close=0x764050) at execute_cmd.c:920
#13 0x00435dd3 in execute_command (command=0x764240) at
execute_cmd.c:416
#14 0x00421a04 in reader_loop () at eval.c:163
#15 0x0041f856 in main (argc=2, argv=0x7fffe9b8,
env=0x7fffe9d0) at shell.c:760


Hope this helps...


---
xoxo iza

Re: -e does not take effects in subshell

[isabella parakiss]

On 8/13/15, Eric Blake ebl...@redhat.com wrote:
 Like it or not, it is the historical behavior standardized by POSIX. It
 is NOT intuitive, and our advice is DON'T USE set -e - IT WON'T DO WHAT
 YOU WANT.  We can't change the behavior, because it would break scripts
 that rely on the POSIX-specified behavior.

POSIX didn't say anything about shopt set-e-that-actually-makes-sense.


---
xoxo iza

segfault when indirectly expanding negative numbers

[isabella parakiss]

Bash segfaults when trying to do this: x=-3; echo ${!x}
Here's the backtrace from gdb: https://gist.github.com/306f16a358527b267a1e
It looks like the problem is the savestring macro when ind is negative.


---
xoxo iza

nocaseglob and =~

[isabella parakiss]

nocaseglob affects regex matching in [[ but according to the man page only
nocasematch should:

nocaseglob
  If set, bash matches filenames in a case-insensitive fashion when
  performing pathname expansion (see Pathname Expansion above).
nocasematch
  If set, bash matches patterns in a case-insensitive fashion when
  performing matching while executing case or [[ conditional commands.


I don't know if it'd make sense to have case-insensitive glob matches and
case-sensitive regexes at the same time...  It may not be that useful and
even counterintuitive.
Anyway, it's probably better to either remove glob_ignore_case from line
67 in lib/sh/shmatch.c or document the actual behaviour, if intended.


---
xoxo iza

Re: cannot declare local variables if they're readonly

[isabella parakiss]

On 7/23/15, Chet Ramey chet.ra...@case.edu wrote:
 This is an excellent time to point out that it's to everyone's advantage
 to be as complete as possible when describing a problem on the list,
 rather than revealing additional details one at a time.

 There's no way anyone would have guessed that you were encountering this
 with BASH_REMATCH; the most likely possibility was that you were trying to
 override a variable you had declared readonly.

 Yes, BASH_REMATCH is special.  It's not present by default, and it is
 destroyed and reconstituted fresh every time you use the =~ operator to
 [[, since it's only supposed to exist if something matched.  I suppose
 there's no real reason to make it readonly other than that there's no real
 reason to write to it, and =~ is the only thing that can modify it.
 Removing the restriction on local copies of readonly variables wouldn't do
 a thing to change the BASH_REMATCH semantics, though it would allow scripts
 to unset it.  We would need a different discussion about how you'd like
 BASH_REMATCH to work.


No.  Don't minimize this, it's not only about BASH_REMATCH.

The fact that a certain special variable is readonly for no real reason
doesn't change this absurd nonsense about any other global variable.


In one thread you linked in your previous answer, you explained that it
could be a security hole if an admin sets a readonly global variable for
some package, then a new function comes in, changes that value, and then
invokes that package with the new environment.

Consider this stupid example:
fib () {
  local first=$1 second=$2 sum
  sum=$(( first + second ))
  if (( first  123456 )); then
fib $second $sum
echo $first
  fi
}

It seems to work just fine:
$ fib 1 1
121393
75025


But it suddenly breaks if first is a readonly global variable.
$ readonly first
$ fib 1 1
bash: local: first: readonly variable
bash: local: first: readonly variable


What's the solution for this?  Naming conventions such as fib_local_first?
(Of course that example doesn't even need to declare variables and could
just use $1 and $2 but that's not the point, real scripts do need them)


Is this *not* a security hole?


---
xoxo iza

Re: cannot declare local variables if they're readonly

[isabella parakiss]

On 7/23/15, Greg Wooledge wool...@eeg.ccf.org wrote:
 People who use readonly are generally doing so in the context of a
 restricted shell (yes, commence laughter) or other situation where
 that specific variable is the key to unlocking something that the
 administrator does not want the user to unlock.  The entity who used
 readonly is presumed to want that variable to remain unchanged, forever.

On 7/23/15, Stephane Chazelas stephane.chaze...@gmail.com wrote:
 2015-07-23 01:12:01 +0200, isabella parakiss:
 What that means is that with this kind of dynamic scoping,
 readonly is not very helpful. I don't remember ever using it.

You guys are assuming that I am the one who uses readonly.
I'm not, *bash* is.

The fact is, I found out this by using BASH_REMATCH, trying to use it in
different functions without interfering with each other.
And it did work, sometimes.  I couldn't even reproduce it in a new shell.

It turns out that bash-completion uses it.  And why wouldn't they?
So my functions stopped working because I tried to... tab complete strace?
WOW.  This makes so much sense.

I imagine that people want to be able to use something like this:


extract_package () {
  local BASH_REMATCH
  if [[ $1 =~ (.*)-([0-9]+\.[0-9]+)\.tar.gz ]]; then
tar xf $1
if install_package; then
  echo ${BASH_REMATCH[1]} ${BASH_REMATCH[2]} successfully installed
else
  echo Couldn't install ${BASH_REMATCH[1]} ${BASH_REMATCH[2]}
fi
  fi
}

install_package () {
  local BASH_REMATCH
  some legit use of [[ =~ ]]
}


Anyway for some reason that I don't fully understand, the above won't even
work when BASH_REMATCH is not defined, as shown below.


$ declare -p BASH_REMATCH
bash: declare: BASH_REMATCH: not found
$ f () { local BASH_REMATCH; [[ abc =~ .(.*). ]]; g; declare -p BASH_REMATCH; }
$ g () { local BASH_REMATCH; [[ xyz =~ .(.*). ]]; }
$ f
bash: declare: BASH_REMATCH: not found
$ f
bash: local: BASH_REMATCH: readonly variable
bash: local: BASH_REMATCH: readonly variable
declare -ar BASH_REMATCH='([0]=xyz)'
$


To sum it up: for some reason that you can't control, local variables may
or may not be assigned correctly.  Also don't use local BASH_REMATCH
because it doesn't work.
Bash is a very usable language and this is totally not a problem.


---
xoxo iza

cannot declare local variables if they're readonly

[isabella parakiss]

From variables.c

   The test against old_var's context
 level is to disallow local copies of readonly global variables (since I
 believe that this could be a security hole).

Can you please explain how that can be a security hole?


$ readonly wtf; fn () { local wtf; }; fn
bash: local: wtf: readonly variable

You can't even be sure that you can set *local* variables in a function.
This is a problem.


Most of the shells that support local variables (ksh93, mksh, zsh, dash...)
allow this.  The only one I could find that doesn't is busybox.


---
xoxo iza

extra \1 in declare -p

[isabella parakiss]

Hi, about this bug:
http://lists.gnu.org/archive/html/bug-bash/2003-03/msg00093.html

The fix was to add this in lib/sh/shquote.c
  else if (c == CTLESC || c == CTLNUL)
*r++ = CTLESC;

I think the fix it was applied twice, it should only check this in the
prompt string, right?


Now declare -p produces output that can't be eval'ed.

$ var=$'x\1y\177z'; declare -p var | sed -n l
declare -- var=x\001\001y\001\177z$


Removing lines 151-152 (from the 4.4 alpha branch) seems to fix this.
The duplicate code keeps checking the prompt in lines 297-298.
(${var@P} is expanded by that part so it should be fine...)
I hope it won't cause other problems.


---
xoxo iza

problem with HISTCONTROL

[isabella parakiss]

When the value of HISTCONTROL is ignoredups or ignoreboth, if you enter
a command and then open the editor and add lines to it without changing
the first line, only the first line will be stored in the history.

I'm terrible at explaining, but I recorded what happens:
https://asciinema.org/a/23275
Hopefully it's clear enough, I'm pressing up arrow to get that line.

I tested a few versions and I can reproduce it in 3.1 and above.


---
xoxo iza

problem with local -

[isabella parakiss]

Using local - calls set_ignoreeof() when unwinding function_calling.
As a result, you have to press ^D 10 times to exit the shell.
Anyway, $IGNOREEOF is not changed and shopt -o ignoreeof reports off.

I'm attaching the relevant part of a backtrace from gdb.


---
xoxo iza


gdb-trace
Description: Binary data

?:

[isabella parakiss]

In lib/readline/input.c line 108
  return (_isatty (fd) ? long) (HANDLE) _get_osfhandle (fd))  3)
== 3) ? 0);
I think you mean return x ? y : z;
Unfortunately I don't have a windows machine to test it...


---
xoxo iza

Re: Consequences of shell errors

[isabella parakiss]

On 6/18/15, Nick Stoughton nstough...@aether.com wrote:


 set -e
 export X=$(false)
 # should not reach here
 echo did not exit

 But every shell I tested behaves the same way (sh, bash, dash, ksh, mksh,
 yash and zsh), so I feel I must be missing something. Can someone explain
 why the first 2 examples do not exit on the error in the expansion?


The exit code of export X=$(false) is export's.


---
xoxo iza

vi-insertion-mode is never bound according to bind -p

[isabella parakiss]

$ bind -p -m vi | grep vi-insertion
# vi-insertion-mode (not bound)

This was introduced in bash 4.0 and conflicts with the readline docs.

Small patch below...


---
xoxo iza



 lib/readline/funmap.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/readline/funmap.c b/lib/readline/funmap.c
index 64b0e41..62535bf 100644
--- a/lib/readline/funmap.c
+++ b/lib/readline/funmap.c
@@ -178,7 +178,7 @@ static const FUNMAP default_funmap[] = {
   { vi-fword, rl_vi_fword },
   { vi-goto-mark, rl_vi_goto_mark },
   { vi-insert-beg, rl_vi_insert_beg },
-  { vi-insertion-mode, rl_vi_insertion_mode },
+  { vi-insertion-mode, rl_vi_insert_mode },
   { vi-match, rl_vi_match },
   { vi-movement-mode, rl_vi_movement_mode },
   { vi-next-word, rl_vi_next_word },

Check linux 4

[isabella parakiss]

This is from configure.ac

linux*) LOCAL_LDFLAGS=-rdynamic  # allow dynamic loading
case `uname -r` in
2.[[456789]]*|3*)   AC_DEFINE(PGRP_PIPE) ;;
esac ;;

It doesn't check for linux 4.


---
xoxo iza

fc and the verbose mode

[isabella parakiss]

fc activates the verbose mode to print the commands as they're read by
the parser and uses unwind_protect_int to restore it.

This is a good idea but there are a few problems with it:
1. it prints the DEBUG trap, which I didn't expect
2. it's impossible to use fc to turn on/off the verbose mode
   ( well, you can, but it's lost as soon as the command ends )

Is it possible to print the commands without activating that mode?


---
xoxo iza

[PATCH] check empty callback in mapfile

[isabella parakiss]

In builtins/mapfile.def there's this line:
snprintf (execstr, execlen, %s %d %s, callback, curindex, qline);

If the callback is empty, bash runs 'spacenumberspaceline'
This smells a lot like code injection.

$ echo 'echo hello from $0'  ~/bin/0
$ chmod +x ~/bin/0
$ cp ~/bin/{0,1}
$ echo -e 'x\ny' | mapfile -c1 -C ''
hello from /home/izabera/0
hello from /home/izabera/1

^^^ That's not at all the result I expected.



This is a simple patch:

 builtins/mapfile.def | 5 +
 1 file changed, 5 insertions(+)

diff --git a/builtins/mapfile.def b/builtins/mapfile.def
index 03f0b48..f91e432 100644
--- a/builtins/mapfile.def
+++ b/builtins/mapfile.def
@@ -178,6 +178,11 @@ mapfile (fd, line_count_goal, origin, nskip,
callback_quantum, callback, array_n
   builtin_error (_(%s: not an indexed array), array_name);
   return (EXECUTION_FAILURE);
 }
+  else if (callback  *callback == 0)
+{
+  builtin_error (_(%s: empty callback));
+  return (EXECUTION_FAILURE);
+}
   else if (invisible_p (entry))
 VUNSETATTR (entry, att_invisible); /* no longer invisible */



---
xoxo iza

[PATCH] replace patterns in empty strings

[isabella parakiss]

I think this is wrong:  var= ; echo ${var/*/x}
It should print x but it prints nothing.

The attached patch fixes this, I hope it's ok.

I don't know what's the correct behaviour in case $var is unset, but it's
probably worth to look at, since bash prints nothing in that case too.


---
xoxo iza


0001-replace-patterns-in-empty-strings.patch
Description: Binary data

Re: [PATCH] replace patterns in empty strings

[isabella parakiss]

Sorry, the previous patch was wrong, it enters an endless loop when
replacing all the occurrencies in ${var//pat/rep}

Attached the correct one (I think).

Tests:
$ ./bash -c 'var=; echo ${var/#/x}'
x
$ ./bash -c 'var=; echo ${var/*/x}'
x
$ ./bash -c 'var=; echo ${var//*/x}'
x
$ ./bash -c 'var=abc; echo ${var/#/x}'
xabc
$ ./bash -c 'var=abc; echo ${var/*/x}'
x
$ ./bash -c 'var=abc; echo ${var//*/x}'
x

This behaviour is consistent with ksh.

Sorry for the trouble...


---
xoxo iza


corrected-0001-replace-patterns-in-empty-strings.patch
Description: Binary data

[PATCH] added -- in autocd

[isabella parakiss]

---
 execute_cmd.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/execute_cmd.c b/execute_cmd.c
index e3aa37f..51c29c6 100644
--- a/execute_cmd.c
+++ b/execute_cmd.c
@@ -4283,6 +4283,7 @@ run_builtin:

   if (autocd  interactive  words-word  is_dirname (words-word-word))
 {
+  words = make_word_list (make_word (--), words);
   words = make_word_list (make_word (cd), words);
   xtrace_print_word_list (words, 0);
   goto run_builtin;
-- 
2.3.6


This was reported in #bash: http://p.pomf.se/7215


---
xoxo iza

Re: [PATCH] added -- in autocd

[isabella parakiss]

On 4/28/15, Eric Blake ebl...@redhat.com wrote:
 On 04/28/2015 12:44 PM, isabella parakiss wrote:
 ---

 Might have been nice to leave a comment why you propose this change.  It
 looks like it is needed for the case when autocd mode is on and you type
 the name of a directory that starts with '-', where the cd command needs
 to interpret the argument as a directory name rather than an option.

  execute_cmd.c | 1 +
  1 file changed, 1 insertion(+)

 diff --git a/execute_cmd.c b/execute_cmd.c
 index e3aa37f..51c29c6 100644
 --- a/execute_cmd.c
 +++ b/execute_cmd.c
 @@ -4283,6 +4283,7 @@ run_builtin:

if (autocd  interactive  words-word  is_dirname
 (words-word-word))
  {
 +  words = make_word_list (make_word (--), words);
words = make_word_list (make_word (cd), words);
xtrace_print_word_list (words, 0);
goto run_builtin;


 --
 Eric Blake   eblake redhat com+1-919-301-3266
 Libvirt virtualization library http://libvirt.org



I'm sorry, I added a link to a pastebin in my previous message but it's
not available anymore.
Anyway, this was the content (posted by Score_Under in #bash):

score@kirisame ~/downloads $ mkdir -- --
score@kirisame ~/downloads $ shopt -s autocd
score@kirisame ~/downloads $ --
cd --
score@kirisame ~ $ cd downloads/
score@kirisame ~/downloads $ rmdir -- --
score@kirisame ~/downloads $ --
bash: --: command not found
score@kirisame ~/downloads $


I think -- should enter said directory.
I hope it's ok...


---
xoxo iza

Re: declare -p doesn't show the global attribute

[isabella parakiss]

On 4/27/15, Chet Ramey chet.ra...@case.edu wrote:
 On 4/26/15 5:26 PM, isabella parakiss wrote:
 $ fn () { declare -g var=x; declare -p var; } ; fn
 declare -- var=x

 I think the correct output should be declare -g var=x
 Is this intended or is it a bug?

 There is no such thing as `the global attribute'.  The -g option simply
 causes declare to create variables at the global scope instead of in a
 function-local scope.  The output you see is no different than what
 would have been displayed had `var' been declared and given a value at
 the global scope outside the function.


Ok I understand, but would it be possible to add it?

My use case may not be the best possible example, but I am sourcing a
library to set various parts of my interactive shells.  In this library
there's a function that sets the color variables from the output of tput.
Trying to avoid to call tput when it's not needed, I decided to save them
to an external file and source it if it exists.  My problem is that if I
source that file from the function, I'm setting local variables.  This is
the part that sets those variables:
https://gist.githubusercontent.com/izabera/d8f0f63fa3dc168af7b9/raw/581753078d33acea3d28b005722edb42c717fa96/gistfile1.sh

It seems to me that if declare -p showed the -g, I could just set them as
global and readonly before I save them, and I wouldn't need to set them
after I source them, in line 6.

Instead of declare -p, one could use something like printf %s=%q but it's
kinda hard to save arrays that way...


It's not a big deal, I just think it would make more sense.


---
xoxo iza

declare -p doesn't show the global attribute

[isabella parakiss]

$ fn () { declare -g var=x; declare -p var; } ; fn
declare -- var=x

I think the correct output should be declare -g var=x
Is this intended or is it a bug?


---
xoxo iza

Problem with bind -x

[isabella parakiss]

I noticed a problem with bind -x: readline re-prints the line if the
function is called when the cursor is not in the first line.

To reproduce it (and to understand what I mean, if it's not clear):

prompt$ myfunc () { :; }
prompt$ bind -x '\C-a:myfunc'


Now write a line that's long enough to wrap, then press C-a

prompt$ a
aaa


Results in this:

prompt$ a
prompt$ a
aaa


Similar results also happen with heredocs and any command that spans
multiple lines when it's recalled with previous-history



It appears that removing these two lines from display.c fixes it:

--- a/lib/readline/display.c
+++ b/lib/readline/display.c
@@ -1936,8 +1936,8 @@ rl_on_new_line ()
   if (visible_line)
 visible_line[0] = '\0';

-  _rl_last_c_pos = _rl_last_v_pos = 0;
-  _rl_vis_botlin = last_lmargin = 0;
+  /*_rl_last_c_pos = _rl_last_v_pos = 0;*/
+  /*_rl_vis_botlin = last_lmargin = 0;*/
   if (vis_lbreaks)
 vis_lbreaks[0] = vis_lbreaks[1] = 0;
   visible_wrap_offset = 0;


I don't know if it breaks something else...


Hope this helps.



---
xoxo iza

Re: associative arrays and [[ -v

[isabella parakiss]

On 4/20/15, Chet Ramey chet.ra...@case.edu wrote:
 On 4/17/15 6:45 PM, isabella parakiss wrote:

 This seems the way to go, but I'm not sure I understand why:

 $ declare -A arr=([a]=b)
 $ [[ -v arr['$var'] ]]; echo $?
 1
 $ declare -A arr=(['*']=x)
 $ [[ -v arr['$var'] ]]; echo $?
 0


 What's happening?

 Well, as I said before, `*' is special: it expands to all elements of the
 array, in the same way as $*.  So you have to protect it through all
 word expansions.

 First, each word in the conditional expression is expanded as described in
 the manual page

 tilde expansion, parameter and
 variable expansion, arithmetic expansion, command  substitution,
 process  substitution,  and quote removal are performed.

 That leaves the word as 'arr[$var]' (without the quotes, of course).  The
 subscript in an associative array reference also undergoes expansions, the
 same ones as the rhs of an assignment statement (pretty much the same as
 above).  That expands the $var, leaving arr[*].  Since the check for `*' or
 `@' as a subscript happens before expansion, the shell looks for the `*'
 as an element of the array.

 In the first case, it doesn't find it; in the second, it does.

 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/


Thanks a lot for the explanation, that was tricky.


---
xoxo iza

associative arrays and [[ -v

[isabella parakiss]

I need to check if an element in an associative array is set.  What's the
correct way to test it?


$ declare -A arr=([x]=y); var=*
$ [[ -v arr[$var] ]]; echo $?
0
$ [[ ${arr[$var]} ]]; echo $?
1


The former seems wrong, the glob is expanded even if $var is quoted.
The latter works but it doesn't distinguish between unset and empty.


Is there a way to test it with ''[[ -v'' ?




Also this one seems wrong, found by geirha:

$ declare -A a=([x]=y); [[ -v a ]]; echo $?
1
$ declare -A a=([0]=y); [[ -v a ]]; echo $?
0




---
xoxo iza

Re: associative arrays and [[ -v

[isabella parakiss]

On 4/17/15, Eduardo A. Bustamante López dual...@gmail.com wrote:
 On Fri, Apr 17, 2015 at 11:12:50AM +0200, isabella parakiss wrote:
 I need to check if an element in an associative array is set.  What's the
 correct way to test it?

 dualbus@yaqui ~ % export key; for key in \* x y; do bash -c 'declare -A
 a=([x]=y [y]=); echo $key ${a[$key]+inarray}; declare -p a'; done
 *
 declare -A a='([x]=y [y]= )'
 x inarray
 declare -A a='([x]=y [y]= )'
 y inarray
 declare -A a='([x]=y [y]= )'

 --
 Eduardo Bustamante
 https://dualbus.me/


Ok that kind of makes test -v useless, doesn't it?

Re: associative arrays and [[ -v

[isabella parakiss]

On 4/17/15, Chet Ramey chet.ra...@case.edu wrote:
 On 4/17/15 5:12 AM, isabella parakiss wrote:
 I need to check if an element in an associative array is set.  What's the
 correct way to test it?

 If *any* element is set, or if a particular element is set?



 $ declare -A arr=([x]=y); var=*
 $ [[ -v arr[$var] ]]; echo $?
 0
 $ [[ ${arr[$var]} ]]; echo $?
 1


 The former seems wrong, the glob is expanded even if $var is quoted.

 It's not a glob.  The array subscripts `@' and `*' are special and expand
 to all elements of an array.

 The latter works but it doesn't distinguish between unset and empty.

 The distinction is murky.  A variable is not set unless it has been
 assigned a value.  Has an array variable that has no elements been
 assigned a value?  Is the concept of a=() meaningful and useful?

 Is there a way to test it with ''[[ -v'' ?

 Are you interested in whether or not an array has been declared or whether
 it has any elements?

 Also this one seems wrong, found by geirha:

 $ declare -A a=([x]=y); [[ -v a ]]; echo $?
 1
 $ declare -A a=([0]=y); [[ -v a ]]; echo $?
 0

 Referencing an array without a subscript is equivalent to referencing
 element 0.

 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/


I'm interested to test if the element '*' is set.


This seems the way to go, but I'm not sure I understand why:

$ declare -A arr=([a]=b)
$ [[ -v arr['$var'] ]]; echo $?
1
$ declare -A arr=(['*']=x)
$ [[ -v arr['$var'] ]]; echo $?
0


What's happening?



---
xoxo iza

Re: associative arrays and [[ -v

[isabella parakiss]

(Sorry the previous message lacked the declaration of var, it was an
asterisk obviously)

$ var=*
$ declare -A arr=([a]=b)
$ [[ -v arr['$var'] ]]; echo $?
1
$ declare -A arr=(['*']=x)
$ [[ -v arr['$var'] ]]; echo $?
0



---
xoxo iza

On 4/18/15, isabella parakiss izaber...@gmail.com wrote:
 On 4/17/15, Chet Ramey chet.ra...@case.edu wrote:
 On 4/17/15 5:12 AM, isabella parakiss wrote:
 I need to check if an element in an associative array is set.  What's
 the
 correct way to test it?

 If *any* element is set, or if a particular element is set?



 $ declare -A arr=([x]=y); var=*
 $ [[ -v arr[$var] ]]; echo $?
 0
 $ [[ ${arr[$var]} ]]; echo $?
 1


 The former seems wrong, the glob is expanded even if $var is quoted.

 It's not a glob.  The array subscripts `@' and `*' are special and expand
 to all elements of an array.

 The latter works but it doesn't distinguish between unset and empty.

 The distinction is murky.  A variable is not set unless it has been
 assigned a value.  Has an array variable that has no elements been
 assigned a value?  Is the concept of a=() meaningful and useful?

 Is there a way to test it with ''[[ -v'' ?

 Are you interested in whether or not an array has been declared or
 whether
 it has any elements?

 Also this one seems wrong, found by geirha:

 $ declare -A a=([x]=y); [[ -v a ]]; echo $?
 1
 $ declare -A a=([0]=y); [[ -v a ]]; echo $?
 0

 Referencing an array without a subscript is equivalent to referencing
 element 0.

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


 I'm interested to test if the element '*' is set.


 This seems the way to go, but I'm not sure I understand why:

 $ declare -A arr=([a]=b)
 $ [[ -v arr['$var'] ]]; echo $?
 1
 $ declare -A arr=(['*']=x)
 $ [[ -v arr['$var'] ]]; echo $?
 0


 What's happening?



 ---
 xoxo iza

Re: read -e deletes extra characters

[isabella parakiss]

On 3/24/15, Chet Ramey chet.ra...@case.edu wrote:
 There are a number of unjustified expectations here.  The biggest is that
 readline can know about characters printed to the screen by another
 program.  Readline expects to be able to use the entire line and that it
 begins with the cursor in column 0.

This cannot be right.

The other program's prompt is never deleted when i use read -p ' ', I
can only erase until the point where readline printed that space.
This means that readline _does_ know where to stop, right?

This is what I consider the correct behaviour.  Is there any way to
achieve this without printing additional characters to the screen?


  The second is that you're going to
 be able to drive an arbitrary program via a pipe -- the key to rlwrap's
 working is that it allocates and uses a pty.

I don't want to write a pty in bash, I just want readline to stop where
it printed the 'empty prompt' when I use read -e -p '' (which would be
good enough for most cli programs).



To summarize:

Please explain why using read -e -p ' ' the other program's prompt won't
be deleted, but it will if i use read -e -p ''


---
xoxo iza

read -e deletes extra characters

[isabella parakiss]

rlwrap is a nice utility that enables readline's features in utilities
that don't provide them.  I tried to rewrite something similar in bash
so here's a sketch of the code:

while read -re; do
  history -p -- $REPLY
  history -s -- $REPLY
done | ...


The problem is when I pipe that to a program that prints a prompt.
On a first impression, it seems to work fine, since pressing backspace
doesn't delete the printed prompt, but actually it will delete it if I
type some other character, then backspace.

In the examples, the prompt will be a $ and it will be printed by the
second program in the pipeline.

$backspacebackspacebackspace # keeps the prompt
$xbackspace  # deletes both x and the prompt


I know that read has -p to print a prompt, and this seems to work if I
set read's prompt to any printable character.

read -e -p ' '
$ xbackspace # deletes x, keeps space and $

read -e -p ''
$xbackspace  # deletes x and $


The same behaviour happens in all the versions from bash 3.

I think this is a bug, please fix it either by allowing an empty prompt
to read -p, or somehow disabling/removing the feature that deletes
extra characters that weren't typed by the user.

Thanks


---
xoxo iza

Re: [PATCH] time-fmt-escapes

[isabella parakiss]

The mail destroyed my tabs :(
Patch attached, this time...


---
xoxo iza


0001-time-fmt-escapes.patch
Description: Binary data

Re: IFS is ignored when concatenating array elements

[isabella parakiss]

On 3/14/15, Le Manh Cuong manhcuon...@hotmail.com wrote:
 In bash, you need to quote in second arr assignment:
 $ arr=(a b c); IFS=+; arr=${arr[*]/a/x}; echo $arrx+b+c
 A note that the result from those shells are different. After second
 assignment to arr:
 - In bash and ksh, arr still be an array, contain 3 elements x b c, b,
 c
 ==bash== $ typeset | grep arr arr=([0]=x+b+c [1]=b [2]=c)
 ==ksh==$ typeset | grep arrindexed array
 - In zsh and yash, arr now is a string:
 ==zsh==$ typeset | grep arrarr=x+b+c
 ==yash==
 $ typeset | grep arrtypeset arr='x+b+c'
 -- Mr. LE Manh CuongMobile: +84 1216 181090Skype: manhcuongle Date: Fri, 13
 Mar 2015 23:15:43 +0100
 Subject: IFS is ignored when concatenating array elements
 From: izaber...@gmail.com
 To: bug-bash@gnu.org

 This works as I would expect:

 $ arr=(a b c); IFS=+; echo ${arr[*]/a/x}
 x+b+c


 But for some reason, this ignores IFS:

 $ arr=(a b c); IFS=+; arr=${arr[*]/a/x}; echo $arr
 x b c




 Here is the behaviour of other shells that allow that kind of syntax:

input: arr=(a b c); IFS=+; echo ${arr[*]/a/x}
 ===
 bash: x+b+c
  ksh: x+b+c
 yash: x+b+c
  zsh: x+b+c

input: arr=(a b c); IFS=+; arr=${arr[*]/a/x}; echo $arr
 ===
 bash: x b c
  ksh: x+b+c
 yash: x+b+c
  zsh: x+b+c

   

(I'm sending your message to the mailing list too)

Well, I just find it weird that quotes aren't needed in this case:
$ arr=(a b c); IFS=+; arr=${arr[*]}; echo $arr
a+b+c

but they are in this case:
$ arr=(a b c); IFS=+; arr=${arr[*]/a/x}; echo $arr
x b c

But apparently that's a recent addition, since 4.2 and below still
ignore IFS:

4.2$ arr=(a b c); IFS=+; arr=${arr[*]}; echo $arr
a b c

I just thought it would be nice to have a consistent behaviour.


---
xoxo, iza

IFS is ignored when concatenating array elements

[isabella parakiss]

This works as I would expect:

$ arr=(a b c); IFS=+; echo ${arr[*]/a/x}
x+b+c


But for some reason, this ignores IFS:

$ arr=(a b c); IFS=+; arr=${arr[*]/a/x}; echo $arr
x b c




Here is the behaviour of other shells that allow that kind of syntax:

   input: arr=(a b c); IFS=+; echo ${arr[*]/a/x}
===
bash: x+b+c
 ksh: x+b+c
yash: x+b+c
 zsh: x+b+c

   input: arr=(a b c); IFS=+; arr=${arr[*]/a/x}; echo $arr
===
bash: x b c
 ksh: x+b+c
yash: x+b+c
 zsh: x+b+c

Re: Unsetting all elements of an associative array

[isabella parakiss]

On 2/4/15, konsolebox konsole...@gmail.com wrote:
 Logically that should only unset the elements of an array and not the
 array variable
 itself since '*' or '@' is more of a wildcard that represents the
 indices.  However, bash
 does otherwise:

   #define ALL_ELEMENT_SUB(c)((c) == '@' || (c) == '*')

 ...

   if (ALL_ELEMENT_SUB (sub[0])  sub[1] == 0)  // If substring is
 just '@' or '*'
 {
   unbind_variable (var-name);  // It just removes it.
   return (0);
 }

 Bash version is 4.3.33.


So, this is completely intended.
May I ask what's the rationale behind this design choice?
I find it very counterintuitive.

Unsetting all elements of an associative array

[isabella parakiss]

I'm trying to use unset array[@] to empty an associative array, but something
goes wrong.

This behaves as expected:
$ declare -A array; array[path/directory]=value

This produces an error:
$ declare -A array; unset array[@]; array[path/directory]=value
bash: path/directory: division by 0 (error token is directory)

After unsetting all its elements, the array is not associative anymore?

Using array=() empties the array correctly.

read -t

[isabella parakiss]

I'm trying to use read -t in an interactive shell

read -t 3   *press random keys*

Everything i press is now part of the next command in the prompt.
It only happens when the delimiter is a \n.
Is this intended? What's the point?

Re: read -t

[isabella parakiss]

Ok, that makes sense, but why doesn't it work if I change the delimiter?

read -t 3 -d q   *press random keys without pressing q*

I think the same should happen here, I'm asking bash to read as much input as
it can until it reads a q.  Since I don't press q, whatever I typed should be
used as typeahead.  But that's not the case, and I don't understand why.

2015-01-04 17:21 GMT+01:00, Chet Ramey chet.ra...@case.edu:
 On 1/4/15 12:45 AM, isabella parakiss wrote:
 I'm trying to use read -t in an interactive shell

 read -t 3   *press random keys*

 Everything i press is now part of the next command in the prompt.
 It only happens when the delimiter is a \n.
 Is this intended? What's the point?

 It's difficult for me to tell what the question is here.  You've asked
 for bash to read as much input as it can until it reads a newline, with
 the read aborted if you don't press a newline within three seconds.  Since
 you don't press newline, read(2) doesn't return anything and whatever
 you've typed is left in the input buffer as typeahead for readline.  When
 readline is called, it is able to read all of the typeahead and use it as
 part of the next input line.

 --
 ``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/